Questo è il primo di una serie di Tutorials su Ottimizzazione di livelli e mappe per Videogames che usano una delle versioni del motore Q4. I tutorials sono dunque utili per Doom 3, Quake 4 e PREY, con diferenze che saranno evidenziate di volta in volta.

In questo primo tutorial ci occupiamo della VIS (Visibility) e quindi del corretto uso dei Visportals, che sono quegli strumenti usati, appunto, per ottimizzare la VIS nei giochi basati sul Q4: vedremo in primo luogo come funzionano e come costruirli, poi discuteremo le condizioni di lavoro ottimali dei visportals, i loro limiti e le interazioni con altri elementi dei livelli. Infine ci occuperemo dell'uso di alcuni Cvars utili per la visualizzazione dei tris e dei portals. Il tutorials sono di livello avanzato, per cui si parte dall'assunto che conosci già le basi dell'editing e sai come usare uno degli editor per i giochi richiamati sopra.

Affiderò la prima parte della spiegazione a un'animazione. Siccome si tratta di una semplice GIF, che a questo punto dovrebe essere già partita, per vederla fin dall'inizio ti suggerisco di ricaricare la pagina. In ogni caso, ti segnalo qui accanto il primo frame, peraltro in una imagine un po' sgranata ma riconoscibile ;)

     

Ora che sai come funzionano i Visportals e sei in grado di costruirli correttamente, vediamo di approfondire un po'. Intanto va detto che l'animazione, per esigenze di brevità, semplifica un po' le cose, per cui sarà il caso di fare alcune puntualizzazioni per completare il quadro e mostrarlo in tutta la sua complessità. Lo faremo alla fine del tutorial, al momento di mostrare gli strumenti di ispezione dei livelli. Ora invece soffermiamoci su alcune questioni di primaria importanza: vediamo per prima cosa quali sono le condizioni di lavoro ottimali dei Visportals e i limiti di questa tecnica. Vediamo anche in che modo l'inserimento di visportals possa interagire con gli altri elementi del livello.


2.1 Condizioni di funzionamento

Come avrai potuto vedere, i Visportals sono strumenti di ottimizzazione indispensabili, senza i quali non potremmo ottenere né livelli Singleplayer né mappe Multiplayer giocabili in modo fluido e con buone performances. Tecnicamente, il lavoro compiuto dai Visportal è noto come overdraw reduction.

Ora, affinché i visportals facciano questo loro lavoro di riduzione della geometria processabile alle sole aree visibili, i nostri livelli devono essere fatti a regola d'arte o, almeno, devono essere privi di:

    - Leaks esterni;
    - Leaks interni.

Inutile soffermarsi sui Leaks esterni. Di solito si sta bene attenti a evitarli, e quando ci sono vengono segnalati in console e bloccano la compilazione; inoltre, per scovareli c'è il pointfile. Si fa invece meno attenzione a quelli interni, più subdoli e difficili da rintracciare e risanare. Ebbene, se non stai alla larga anche dai leaks interni, il lavoro di ottimizzazione perderà di efficacia.

Il Leaks interni sono contatti (diciamo fori) tra una stanza, area, settore e l'altro contiguo. Se la geometria di un settore è bucata, il visportal che divide le due aree, settori, stanze non funzionerà a dovere, perché gli ambienti comunicheranno attraverso il leak ignorando il visportal. Oltre a ciò, poiché per la delimitazione delle locations il motore usa i visportals, la presenza di leaks interni renderà impossibile la denominazione diversificata delle aree, perché il motore non riuscirà ad identificarne i confini.


2.1 Limiti di questa tecnica

Altre condizioni di lavoro ottimale dipendono dalla quantità e dal posizionamento dei Visportals. Per quanto riguarda la quantità, bisogna considerare il fatto che l'inserimento di visportals segmenta la geometria che viene intersecata, aumentando così il numero di poligoni. Questo è il limite più vistoso di questa tecnica; ma se i visportals non vengono usati in modo improprio, questo limite non avrà un'incidenza determinante nell'economia complessiva del livello. In altre parole, i visportals vanno usati con parsimonia, soprattutto in presenza di ambienti geometricamente complessi, fatti di un elevato numero di poligoni, e il loro posizionamento dev'essere estremamemte preciso, vale a dire che le loro dimensioni devono coincidere esattamente con le dimensioni dell'apertura che si intende otturare, sia sull'asse verticale che orizzontale.

Ma il fatto determinante quanto al pisozionamento resta la loro distribuzione e orientamento nel livello. Come si vede nell'animazione, la geometria solida non blocca la visibilità. Il ruolo di quest'ultima è semplicemente quello di limitare i movimenti del player e quindi le prospettive da cui uno o più visportals possono entrare nel cono di visibilità della camera/player. Poiché è importante limitare il più possibile la quantità di portals visibili attraverso un visportal, l'architettura del livello dovrebbe essere fatta in modo tale da guidare il player lungo un percorso che non presenti mai una successione di visportals disposti in linea retta.

     

Vediamo come interagiscono i visportals con altri elementi del livello.


  3.1 Visportals e porte

I visportals vanno a nozze con le porte automatiche :)
Posizionato all'interno di una porta, il visportal si aprirà all'apertura della porta e si richiuderà automaticamente quando la porta viene richiusa. Il motore eseguirà il rendering della geometria visibile dopo l'apertura, e con essa il calcolo dell'incidenza della luce che passa da una stanza all'altra e colpisce le textures prima illuminate dalle sole luci presenti nel settore. Questo è uno dei migliori risultati a livello estetico, oltre che funzionale, di questa nuova tecnica e al tempo stesso la migliore dimostrazione di come la VIS lavori dinamicamente indipendentemente dalla BSP.


  3.2 Visportals e modelli

Il motore tratta i modelli come singole unità in base al box che li contiene e non poligono per poligono come invece avviene per la normale geometria. Questo significa che se un modello di grosse dimensioni (diciamo una caverna) viene intersecato da un visportal, la porzione del modello al di là del visportal verrà processata comunque, e con essa anche le luci e parte della geometria che lo circonda. In questi casi è inutile e controproducente usare i visportals.


  3.3 Visportals e luci

Come i modelli, così anche le luci vengono trattate dal motore in base al box esterno che ne delimita la portata, e non in base al centro. Questo significa che se anche un angolo del box è visibile attraverso un visportal l'entità verrà renderizzata. (Sull'ottimizzazione dell'illuminazione v. il tutorial dedicato [soon]).


  3.4 Visportals e textures riflettenti

Com'è noto, il Q4 è così "intelligente" da capire da solo che non deve prendere in considerazione i lati dei poligoni che si affacciano all'esterno del worldspan. Questo ci consente di fare a meno dal caulk su quelle superfici. Tuttavia ciò non vale per tutte le textures. Nel caso delle reflective textures, come l'acqua e gli specchi, se solo una piccola parte di esse è a contatto con il vuoto, il lavoro di ottimizzazione con i visportals non avrà effetto e l'intero livello verrà processato come una singola gande area.


  3.5 Visportals e func_portals

Il func_portal è un'entità che può essere applicata al brush texturato con (nodraw+)visportal e collegato a un trigger, al fine di ottenere un portal che si aprirà solo quando il player entrerà a contatto con il trigger. Un esempio del suo uso lo si trova nella stock map mc_underground, applicato all'airlock door.

     

Come anticipato in apertura, nella prima parte del tutorial abbiamo un po' semplificato per guadagnare in immediatezza. Ora è arrivato il momento di dirla tutta ;)
I visportals non lavorano da soli, ma in combinazione con le scissors.
Cosa sono, innanzitutto, le scissors? Nelle applicazioni OpenGL le scissors (forbici) sono rettangoli applicati a schermo che decidono quali pixels verranno scartati senza mai arrivare sullo schermo: qualcosa come uno stencil di forma rettangolare, che ha funzioni analoghe allo Zbuffer.

Il loro funzionamento è sostanzialmente il seguente: quando la camera/player inquadra un visportal, questo si apre in modo da permettere il rendering della scena contenuta all'interno del settore. Prima però di procedere al rendering, il motore applica una scissor intorno al visportal, creando una cornice che nasconde la visione di tutto ciò che non rientra nello specchio del visportal, al fine di evitare che i pixels fuori portata vengano attivati su schermo. Attenzione però: che l'area tagliata via dalle forbici non sia visibile su schermo non significa che non venga processata e renderizzata.

Infatti, questa tecnica ha un grosso limite. L'applicazione delle scissors non impedisce il rendering dell'area schermata dalla cornice: la CPU deve comunque processare i triangoli, raccoglierli in batches, caricare le textures e inviarle alla scheda grafica, la quale deve ancora effettuare il vertex shader e rasterizzare tutti i triangoli. Fatto questo, la scheda scarterà tutta l'area schermata, ottimizzando così il fill rate. E' dunque soltanto la sequenza terminale del processo di calcolo che viene alleggerita: per il resto, il sistema lavora a pieno ritmo.

Questa precisazione è molto importante al momento di usare gli strumenti di ispezione, come vedremo al punto seguente.

     

Per vedere cosa effettivamente sta combinando il motore grafico, possiamo servirci degli strumenti di ispezione, attivabili dalla console. Qui vedremo solo quelli utili a controllare la visibilità, che sono:

r_showportals 1 (rende visibili i portals disegnandovi un rettangolo intorno, di colore rosso se sono chiusi e verde se sono aperti).

r_showtris 1 (mostra i lati dei poligoni visibili dal player data la sua attuale posizione) Questo Cvar NON è molto utile per l'ottimizzazione, dal momento che si limita a restituire esattamente la visione del player, che non coincide con quella del motore, come possiamo notare nelle immagini successive.

r_showtris 2 (mostra i lati dei poligoni che il motore è in grado di "vedere", al di là della visione del player)

r_showtris 3 (mostra i lati dei poligoni che il motore è in grado di "vedere" e, in aggiunta, anche le facce retrostanti, non visibili al player) NB In questo caso la differenza non è percettibile perché tutte le facce nascoste sono state ricoperte con caulk. In ogni caso, è questo il Cvar da utilizzare nella ispezione della geometria visibile dei livelli

A questo punto, usando r_showtris 3 potremmo presumere che ciò che si vede su schermo sia la totalità della geometria che il motore invia alla CPU e questa a sua volta alla GPU.

E invece non è così. Gli screenshots di sopra sono stati ripresi con la scissor attivata e non rispecchiano la totalità della geometria processata dal nostro sistema. Si nota infatti chiaramente che la geometria intorno al portal (schermata dalla scissor) è stata scartata, cosa che vediamo con maggiore chiarezza nello screenshot di sotto a sinistra, dove muovendoci a sinistra abbiamo sovrapposto due visportals. Scartata, vale la pena ripeterlo, non significa che non sia stata processata. Infatti, se lo confrontiamo con lo screenshot di destra, in cui la scissor è stata disattivata inserendo il Cvar r_useScissor 0 in console, ci rendiamo conto che la maggior parte dei poligoni del secondo settore, anche se non possono essere visti dal player, sta ancora impegnando il nostro sistema.

va da sé in una piccola stanza spoglia ciò non ha la minima importanza, ma prova a pensare a un grande stanzone pieno di geometria, modelli, effetti e luci :P


Riassumendo, per testare la visibilità della geometria ai fini di ottimizzare le performance, la prima cosa da fare è disattivare la Scissor. In secondo luogo, visualizzare i portals e i tris, usando rispettivamente, i seguenti Cvars:

 r_useScissor 0
 r_showportals 1
 r_showtris 3


Con questi tre strumenti puoi girare in lungo e in largo il tuo livello a caccia di sprechi. Ma ricorda, se vuoi avere un livello performante, fluido e giocabile, l'unico modo è partire sin dall'inizio con in mente un layout concepito espressamente per l'ottimizzazione della Visiblità.