Game Engine Programming -- Piccola Verifica Istruzioni: ad ogni domanda, salvo dove diversamente indicato, una sola delle alternative è giusta (o perlomeno più sensata delle altre): sottolineala. Tempo necessario stimato per completare la prova: 16-18 secondi ;-) Soluzioni sbagliate in testo semplice. Soluzioni corrette in grassetto. Commenti in verde. Correzioni al testo originale in azzurro. Ad un nodo di uno scenegraph si associa: un reference frame / una gerarchia / una camera Cioè un sistema di riferimento (origine e tre assi), che costituisce lo spazio oggetto dell oggetto in questione Ad un arco di uno scenegraph si associa: un fattore di scala / una trasformazione / un oggetto Ovviamente una trasformazione può anche contenere un fattore di scala. I vertici di una mesh hanno una posizione definita in: spazio mondo / spazio oggetto / spazio vista Le XYZ di un vertice sono coordianate espresse nel sistema di riferimento privato di quella mesh. Mesh di un gatto: coordinate espresse nel sist di riferimento gatto (lo spazio oggetto dell oggetto gatto ). Sarà poi la trasformazione di modellazione a tradurre queste coordinate nel sistema di riferimento comune al tutta scena ( spazio mondo ), e poi quella di vista a tradurre queste nel sistema di riferimento relativo alla camera virtuale ( spazio vista ). Le normali di una mesh sono attributi definiti: per faccia / per vertice / per edge come tutti gli altri attributi (almeno, nei games). Per quanto in altri contesti a volte gli attributi siano memorizzati (per es) per faccia, nelle strutture dati usate nei games sono invariabilmente memorizzati per vertice. D altronde, se le normali fossero memorizzate per faccia, il rendering engine potrebbe offrire solo flat shading che non si usa praticamente mai (casomai, si simula con hard edges). Il rendering con shading smooth richiede invece normali per vertice (shading a volte detto phong / goreaud, a seconda di se si interpola la normale o il lighting risultante, ma sono termine desueti). Gli attributi dentro una faccia sono: costanti / linearmente interpolati / quadraticamente interpolati / dipende dall attributo L interpolazione lineare degli attributi (a prescindere da quali siano!) all interno delle facce è una di quelle features universali della CG basata su GPU e rasterizzazione (cioè TUTTA la cg dei games). Durante il rendering, tale funzionalità è implementata nel rasterizzatore, ed è completamente hard wired. Le strutture dati si limitano a rispecchiare questa scelta obbligata basata sul funzionamento delle GPU. Per mappare una tessitura su una mesh è necessario: uno skinning / un uv-mapping / le normali / la trasformazione di modellaz. Le altre risposte sono non-sense. (UV-map = assegnamento coordinate UV ad ogni vertice). Le tangent space normal maps sono utili per rendere la tessitura indipendete da: l orientamento della superfice a cui si applica / l oggetto a cui si applica / il tiling della tessitura Per quanto una Tangent Space normal map possa anche applicarsi ad oggetti diversi, ed anche in modo tiled, la proprietà più generale (da cui le altre conseguono) consiste nella capacità di applicazione indipendentemente dall orientamento delle facce texturate. Questo rende le normal map di questo tipo tanto flessibili quando, per es, le RGB maps ( si possono attaccare ovunque ). In un certo senso, questo tipo di normal map codifica, in ogni punto, non una normale da zero, ma in che modo la normale di default debba essere modificata per ottenere quella finale. Di contro, le object space normal map definiscono le normali da zero, che sostituiscono (e non: modificano) quelle di default; e quindi, per es, la texture da applicarsi alla parete nord di un castello non si puo applicare alla parete sud e viceversa. Le tangent space normal map richiedono di mandare a GPU: normali e direzioni tangenti / direzioni tangenti ma non le normali / normali e basta / nessuno di questi attributi Le dir tangenti (per vertice) servono per sapere in che dir modificare le normali per vertice. Tutte e tre sono necessarie. Le object space normal map richiedono di mandare a GPU: normali e direzioni tangenti / direzioni tangenti ma non le normali / normali e basta / nessuno di questi attributi perché le normali lette dalla tessitura sostituiscono quelle eventualmente definite sui vertici, di cui dunque non c è alcun bisogno. Gli attributi sulla superficie di una mesh, a meno di seams: variano sempre con continutà ma con derivata discontinua sugli edge / variano sempre con continuità di secondo grado / non variano ovviamente, essendo appunto una interpolazione lineare. Derivata (spaziale): costante per faccia. Fra una faccia e l altra, nel caso generale, c e una discontinuità di derivata.
La densità di tassellamento su una mesh: deve essere più costante possibile / deve variare in funzione della complessità geometrica / deve variare in funzione della frequenza dei dettagli di colore Non certo di colore! Perché nel mondo dei games praticamente tutto è texturato, e il segnale colore è controllato dalle tessiture RGB, non dal colore per vertice (che al massimo codifica il lighting baked, o altre variazioni del colore base). E non e affatto auspicabile che sia costante: le mesh devono avere risoluzione ADATTIVA: più poligoni dove c è più bisogno, meno dove la geometria è piatta (o poco importante). Ottimizzare tutto! Gli hard-edge su una mesh: sono computati dal motore di rendering durante il rendering / sono scelti dal modellatore e memorizzati nell asset / sono computati in fase di lettura dell asset E vero che, in mancanza di normali memorizzate nel modello, un game engine provvederà di solito a crearne (a partire dalla geometria). Ma nella maggior parte dei casi le normali sono controllate dall artista, sotto forma di scelta di quali edges siano hard e quali soft. In alcuni modellatori 3D, si usa la terminologia smoothing group : le facce vengono raggruppate dal modellatore in diversi smoothing groups, e gli edge di confine fra smoothing groups diversi sono considerati hard. Per ottenere un hard-edge su una struttura dati mesh: si replicano dei vertici / si assegnano due normali diverse ad un vertice / si usa uno shader apposito E un esempio di vertex seam, cioe di discontinutà del valore di un attributo (in questo caso, le normali) ottenuta duplicando dei vertici e assegnando valori di attributo diverso alle due copie (che, spazialmente, coincidono, cioè che hanno lo stesso valore di posizione x,y,z). Assegnare normali diverse ad un vertice va contro il principio di semplicità delle strutture dati (mettere una lista di lunghezza variabile ad ogni vertice? Lasciare a tutti i vertici la possibilità di definire due normali? Mannò!) Fa parte dei compiti di un game engine (selezionare *tutte* le giuste): la costruzione di UV mapping delle mesh / il computo delle trasformazioni cumulate di ogni nodo dello scene graph / il blending dei keyframe di una blend shape / il calcolo delle collisioni fra hit boxes / la semplificazione automatica delle mesh / interpretazione degli script di AI / trasferimento degli attributi da un modello a un altro / mixing degli effetti sonori / l interfacciamento col sistema operativo / rendere tileable le tessiture / il display degli elementi di HUD In pratica, tutto quello che avviene quando il gioco viene eseguito e durante la sua esecuzione. Le risposte sbagliate sono invece task degli artisti digitali, che preparano gli assets (attraverso game tools etc) durante lo sviluppo del gioco. Un UV-mapping 1:1 è necessario per (selezionare *tutte* le giuste): object space normal mapping / light baking / tessiture tileable / tangent space normal mapping / projection of detail from hi-res models / rgb textures / l applicazione di una qualsiasi tessitura / praticamente sempre / praticamente mai / effetti speciali come macchie di vernice che si accumulano dinamicamente sul modello (nota: 1:1 è per usato per semplicità: per essere più precisi: bisognerebbe dire iniettivo. Infatti un UV-map è assai raramente biettivo, perché alcune zone della tessitura sono inutilizzate gaps fra texture charts e sui bordi) Le risposte giuste sono tutti quei task che richiedono di memorizzare qualcosa di diverso in ogni punto della mesh. Così questo qualcosa può venir memorizzato nella tessitura, nel texel relativo a (solamente!) quel punto sulla mesh. Per es, se una tessirura è tiled (ripetuta tante volte sulla superficie), oppure se le simmetrie sono sfruttate (es, se una stessa parte di tessitura mappata sul lato dx e sul lato sx di un personaggio), allora come sarebbe possibile (nell ultimo task elencato) macchiare di vernice il lato dx dell oggeto, ma non quello sx? se scrivo rosso vernice su un punto della tessitura macchio entrambi i lati! Oppure macchiare un solo mattone di un muro, senza macchiarli tutti i mattoni corrispondenti. Gli altri esempi seguono questo principio. Light baking, per es Ambient Occlusion: se un mattone di un pattern ripetuto di mattoni riceve poca luce in una certa posizione, non è affatto detto che ne ricevano poca tutti gli altri mattoni uguali. Attenzione al normal mapping: quello object space, visto che la tessitura non si può applicare a punti orientati in modo diverso, richiede un mapping 1:1, ma non il tangent space normal mapping. La compressione di una tessitura in GPU: utilizza gli algoritmi di compressione delle immagini e ne eredita le caratteristiche / è più efficace di quella delle immagini generiche, ma anche più lossy / è meno efficace, pur deteriorando il segnale maggiormente / è lossless Reminder: le tessiture in GPU hanno bisogno di essere random accessible, le immagini generiche NO. Prendiamo un JPEG: prima scompatto TUTTA l immagine in un buffer, solo poi sono libero di chiedere che colore abbia il pixel a coordinate 34,51. Invece, quando la GPU quando fa un texture fetch (un accesso alla tessitura), ha bisogno di sapere al volo il valore rgb alle coordinate richieste, quindi lo schema di compressione delle tessiture deve consentire questo. Compressione di immagini e di tessiture, insomma, sono due cose completamente diverse. La memoria GPU è contesa principalmente da (selezionare tutte le giuste): trasformazioni dello scene graph* / modelli 3D / tessiture / tutti gli assets / animazioni scheletali / gli shaders* / i filmati / gli scripts / gli assets procedurali Le risposte astriscate sono solo mezzi errori, perché i dati in questione possono effettivamente essere memorizzati nella GPU, però la loro occupazione in memoria è trascurabile (la domanda chiedeva principalmente ). Asset procedurali: non sono certo dati che occupano memoria (ne in GPU ne nella main RAM)! Al max occupa il programma (ma quanto piccolo!) che li genera. Tutti gli assets: non abitano mica tutti in GPU, si pensi agli audio samples per es.
Il tiling di una tessitura è determinato da: coordiante tessitura al di fuori del quadrato canonico in un UV mapping / copie molteplici dell immagine nel buffer di texels / scalatura uniforme del modello su cui si applica Ad es, se voglio texturare un rettangolo con 3x4 copie di una tessitura tileable, dovrò assegnare ai quattro vertici le coord tessitura (0,0),(3,0),(3,4), (4,0). Infatti (0,0),(1,0),(0,1),(1,1) corripondono ai quattro angoli della tessitura, e i vertici al di fuori di questo quadrato unitario canonico sforano dall altra parte, per così dire, causando la ripetizione della tessitura. Questo meccanismo (detto texture wrapping ) è implementato a basso livello nell operazione di texture fetch eseguita dalla GPU. Queste fasi della determinazione di un uv-mapping sono tipicamente automatizzate dal algoritmi specifici (selezionare tutte le giuste): determinazione degli edge di taglio / minimizzazione dello stretch / packing dei charts Le altre risposte non sono errori gravi: infatti ci sono algoritmi (implementati in blender, maya, etc) che TENTANO di risolvere quei sottoproblemi. Ma, a differenza di quello evidenziato, i risultati di questi algoritmi sono solo un ausilio e il modellatore (addetto all UV-mapping) di solito li utilizza al più per avere una soluzione di partenza da migliorare a mano. I texture seams su una mesh sono necessari: se la tessitura è tiled / se l oggetto non è simmetrico / praticamente sempre Senza un po di tagli è impossibile aprire la mesh sul un piano tessitura. Per disporre una buccia di arancia su un tavolo piatto, o una pelle di mucca, da qualche parte la si deve pur tagliare la buccia o la pelle. L unica eccezione si ha quando il nostro modello 3D è topologicamente un disco, come per es una bandiera. Questo tipo di modelli 3D non ha bisogno di texture seams (e l uv può essere continuo su tutta la superficie). I texture seams su una mesh sono implementati: da una replicazione di alcuni vertici spazialmente coincidenti / attraverso una replicazione di alcune facce adiacenti / attraverso una coppia di shader specializzato / memorizzando gli attributi per ogni edge Anche questo caso (come per gli hard edge), si tratta del solito trucco per includere discontinuità sugli attributi. In questo caso, l attributo in questione è la posizione UV. Le normali di una mesh: vengono computate nel vertex shader / vengono computate dal motore di rendering / vengono di solito computate dal game engine in fase di caricamento / fanno di solito parte dell asset come memorizzato su disco. Vedi considerazioni sopra sugli hard edges. Sono responsabilità dell artista! Per il game engine, questo è solo un input. Di sicuro il vertex shader NON HA abbastanza informazioni per capire da solo la normale di un vertice, se non gliela passiamo noi. Infatti il vertex shader processa un vertice alla volta, senza sapere cosa ne e dei vertici vicini. Non vede le facce. a partire da: geometria + connettività / UV-mapping + connettività / nessuna delle due Come abbiamo visto, una volta determinati quali siano gli edge hard, un modo standard di determinare le normali (almeno, in prima approssimazione) e mediare sui vertici le normali geometriche computate su ogni faccia triangolare. Queste ultime dipendono dunque dalla geometria (le coord xyz dei vertici) e dalla connettività (quali facce legano quali vertici). Le direzioni tangenti di una mesh: vengono computate nel vertex shader / vengono computate dal motore di rendering / vengono di solito computate dal game engine in fase di caricamento / fanno di solito parte dell asset come memorizzato su disco. Infatti molte strutture dati mesh (quasi tutte) non prevedono neanche che si possano memorizare le direzioni tangenti (necessarie al normal mapping). Tanto queste non sono altro che i gradienti delle coordiante U e V sulla mesh. A partire dall assegnamento delle coordinate UV, si coputano i gradienti sulle facce, e si mediano sui vertici. a partire da: geometria + connettività / UV-mapping + connettività / nessuna delle due La connettività memorizzata ad half edge: è preferibile perché è più compatta / è più adatta ad operazioni di modelling che non al rendering / è obsoleta. E anzi molto piu prolissa. Ma consente di navigare sulla mesh. Di risovere al volo sotto-problemi come: quale faccia sta al di la di questo edge? Quale insieme di facce condivide questo vertice? Inoltre, consentono in modo naturale di memorizzare mesh non triangolari (di quad, miste, di poligoni ) che dal punto di vista del rendering sono inutili (la GPU conosce, cioe sa rasterizzare, solo i triangoli), ma sono utili per un modellatore. La struttura dati indexed è usata: dai comuni file formats per i modelli 3D / dalle strutture in GPU i modelli 3D / da entrambi Le strutture come vertex buffer objects sono indicizzate, come pure i formati come OBJ e altri formati comuni di mesh Un materiale è un asset che di solito comprende (barrare tutte le valide): shaders* / UV-mapping delle mesh / parametri di lighting / tessiture RGB* / peso specifico / normal maps* / hit boxes Omettere le risposte astriscate non è un errore grave, perché non tuttissimi i game engine o i software di modellazione la pensano così. Ma, in generale, per materiale si intende la descrizione di come un dato oggetto risponde alla luce ed è competenza del motore di rendering. E ortogonale al modello 3D, quindi UV-mapping non c entra. Le altre risposte sbagliate riguardano cose di competenza del motore fisico; insomma per materiale si intende di solito invece esclusivamente l aspetto ottico. Similmente, in altri contesti di CG (non games), materiale = una BRDF (vedi).
Lo skinning di una mesh assegna ad ogni vertice della mesh: un keyframe di una animazione / l indice e il peso di un alcune ossa di un rig / una posizione finale per ogni keyframe. Nota: un numero molto limitato di ossa. Max 1, max 2, o max 4, nella maggior parte dei sistemi. Se max=1, allora ovviamente non c è bisogno di memorizzare pesi: sono tutti 1. Si possono applicare le stesse animazioni a personaggi articolati simili ma non identici: solo se hanno skinning costruiti per uno stesso scheletro / solo se hanno scheletri con un numero identico di arti / solo se le animazioni sono adattate a ciascuna delle mesh Chiaramente condividere lo scheletro è una condizione molto piu forte che non condividere solo il numero di arti. Ad es, umanoidi di struttura molto diversa hanno di solito scheletri ( rigs ) diversi. Una posa di un animazione skeletale consiste in: assegnamento di una trasformazione per ogni osso / una trasformazione di modellazione per ogni mesh associata / una struttura gerarchica (ad albero) di ossa e una animazione scheletale è una sequenza di pose. Per trasformazione, sistemi diversi intendono cose diverse, per es, una rototraslazione, una matrice affine, una rototraslazione + scala Un sistema di particelle viene renderizzato rappresentando ogni particella (barrare tutte le possibili): come point splats / come impostors rettangolari texturati / come istanze di mesh / attraverso visualizzazione volumetrica A parte la risposta non-sense (l ultima), sono tutte alternative usabili e usate. Sono anche in ordine di complessità, dalla più cheap alla più demanding. I LOD associati ad un oggetto sono costruiti: sempre attraverso algoritmi di semplificazione automatica / sempre attraverso una modellazione manuale di ogni livello / dipende dalla distanza a cui vengono visualizzati / dipende da altri fattori Come abbiamo visto anche in pratica, gli algoritmi di semplificazione automatica non riescono a ottenere gli stessi risultati di un bravo modellatore manuale, soprattutto quando il budget di poligoni è molto limitato. Tutti i keyframes di una blend shapes condividono (barrare tutte le valide): connettività / posizioni dei vertici / tutti gli attributi / normali / UV-mapping / skinning Esempio di condivisione di skinning: mettiamo di avere un face-morph guance gonfie e uno guance sgonfie. Sono ottenuti ciascuno modificando una mesh facciale di base. Se nella prima mesh alcuni vertici sono collegati all osso mandibola altri all osso teschio (altri ad un misto dei due), e evidente che anche nella seconda mesh varra la stessa divisione. Idem se ho un morph corpo grasso e uno corpo magro, skinned su di uno scheletro umano. I LOD vengono alternati dal motore di rendering a seconda : della distanza dell oggetto dalla camera / della posizione dell oggetto in spazio mondo / del livello di profondità nella gerarchia dello scene graph. e se ne occupa il rendering engine. In 3D, combinando insieme due rototraslazioni si ottiene sempre una rototraslazione: SI / NO / Dipende In 2D, combinando insieme due rototraslazioni si ottiene sempre una rototraslazione: SI / NO / Dipende In altre parole, la classe delle rototraslazioni (in qualunque dimensione!) è CHIUSA rispetto alla combinazione! Cioè: qualunque sequenza di mi ruoto e mi sposto la posso fare in un colpo solo ruotandomi una volta (di un certo tot) e spostandomi una volta (di un certo tot). L applicazione di una tessitura volumetrica procedurale richiede: UV mapping / spazio tangente / nessun attributo Dato un punto di coordinate xyz sulla superficie, la tessitura volumetrica determina il suo colore solo a partire da quell xyz. E il colore che quel punto avrebbe se l oggetto fosse stato scavato da un materiale rigido non uniforme, come legno o marmo. Che bisogno c è di UV-mappng? Nota: varrebbe anche per le tessiture volumetriche standard (rasterizzate su griglia 3D, non procedurali), ma nei games sono molto rare perché occupano troppa memoria. Mesh hi-res irregolari sono l output naturale di tecniche (barrare tutte le valide): di surface subdivision / di low poly editing / di scuplting / di acquisizione automatica / di tassellamento di superfici parametriche. Low-poly editing non produce mesh hi-res, (ovviamente!), e le altre (che cmq non abbiamo neanche visto da vicino) sono regolari (cioè hanno una connettività a griglia regolare ). Mesh hi-res irregolari sono, spesso, inutilizzabili direttamente, ma utili per (barrare tutte le valide): costruzione di piramidi LOD / sintesi di tessiture per modelli low-poly corrispondenti / guidare per la modellazione low poly / sintetizzare animazioni / servire da collision objects / UV-mapping dei modelli low-poly Vedere gli esempi sui lucidi. (questa domanda e la precedente sono state considerate corrette se è stata scelta una delle due risposte corrette)
Nelle animazioni scheletali, le pose vengono interpolate: mai, non è possibile farlo / nel passaggio da un keyframe al successivo / nel passaggio smooth da una animazione all altra / in entrambi questi casi Entrambe le operazioni sono basate sulla capacità di interpolare fra due pose, che a sua volta è definito dall interpolazione 1 a 1 di tutte le trasformazioni che le definiscono. Nelle blend shapes, le pose vengono interpolate: mai, non è possibile farlo / nel passaggio da un keyframe al successivo / per effettuare dei morph fra un due shapes / per effettuare un morph fra un numero qualunque di shapes (è la risposta corretta perché è la più generale. Le due precedenti sono casi particolari.) Si sceglie gonfiare ritmicamente il petto per rendere il respiro affannato di un personaggio durante una corsa. Meglio usare: blend shapes per la respirazione, e contemporaneamente animazioni scheletali per la corsa / animazioni scheletali per entrambi gli effetti, perché non è possibile coniugare le due tecniche / blend shapes per entrambi gli effetti, perché non è possibile coniugare le due tecniche Certo che è possibile coniugare le due tecniche! La prima presuppone una replicazione della geometria (una coord XYZ per vertice diversa per ogni morph target), la seconda è un assegnamento di attributi (lo skinning) per ogni vertice, condivisi da tutti i morph targets) Un geometry proxy viene utilizzato per (scegliere tutte le giuste): computo dell illluminazione globale / detection delle collisioni nel motore fisico / calcolo delle risposte alla collisioni nel motore fisico / computo di visibilità e occlusione per l AI / computo della massa degli oggetti / computo delle rifrazioni e riflessioni ottiche La collision response (nel motore fisico) si avvale delle normali del punto di contatto, che sono determinati dal geometry proxy (bounding spheres, capsule, etc). In partica, se hai fini del motore di rendering l oggetto è modellato dalla mesh, ai fini del motore fisico (e, quando necessario, dall AI), l oggetto e modellato internamente dal suo proxy geometrico. Il painting delle tessiture deve seguire (e non precedere) la sintesi dell UV mapping: mai / sempre / non è detto A volte, la tessiura nasce per prima e l UV mapper deve rispettarla (anche se più spesso l UV map nasce prima, e la tessitura viene riempita in seguito, dal texture painter, dipingendo per es sul modello 3D) L editing dell animazione scheletale per un personaggio deve seguire (e non precedere) la sua modellazione 3D: mai / sempre / non è detto Gli animatori costruiscono le animazioni 3D dello scheletro, a prescindere dai modelli che sono (o saranno) skinned su quello scheletro. Idem per le animazioni che sono motion captured. L editing dell animazione scheletale un personaggio deve seguire (e non precedere) la scelta del suo rig: mai / sempre / non è detto L animazione scheletale è fatta sul rig (lo scheletro), non sulla mesh stessa Lo skinning un personaggio deve seguire (e non precedere) la scelta del suo rig: mai / sempre / non è detto Vedi la definizione di rigging e skinning Una normal map è inutile, rispetto ad un baked lighting: su oggetti che fanno parte di una scena statica / se l illuminazione e la sua direzione in spazio oggetto è costante / se l illuminazione è costante in spazio vista La prima non è corretta: anche se il prop è fermo (per es, un muro), reagirà dinamicamente all ambiente di illuminazione, quando è questa a variare. Circa la riposta giusta: l esempio più semplice di luce ferma in spazio oggetto è quando sia il prop sia le luci sono statici. Un esempio più fantasioso si ha quando la luce fosse fissata montata sull oggetto. Esempio dell ultimo caso: una torcia fissata sulla testa del personaggio controllato dal giocatore, in un first person shooter. Chiaramente la luce è in movimento rispetto a tutti gli oggetti della scena, che traggono appieno i vantaggi offerti dalla normal map (reilluminazione dinamica). La sintesi dei livelli di MIP-map oltre al primo: è sempre demandato al game engine / è sempre demandato all artista / dipende Anche se i livelli di MIP-map oltre al primo sono spesso semplicemente dei ricampionamenti pre-filtrati del livello zero, a volte gli artisti vogliono controllare questo processo. Infatti i formati standard delle tessiture (a differenza di quelli delle immagini) prevedono la possibilità di memorizzare tutti i livelli di MIP-mapping, che diventano così una parte integrante dell asset. L intera struttura di livelli di MIP-map occupa, in memoria RAM, rispetto alla tessitura originale: un terzo / la metà / altrettanto / una volta e mezzo / il doppio / dipende 1/4 + 1/16 + 1/64 + (somma su tutti gli i da 1 a N -- o anche infinito -- di 1/i^2). Il livello di MIP-map viene scelto dal rendering engine: per ogni mesh / per ogni faccia / per ogni vertice / per ogni frammento E una parte integrante (e hard-wired ) dell operazione di texture fetch, che avviene per frammento. Se una mesh triangolare ha X vertici, tipicamente avrà un numero di facce approssimativamente pari a: X/3, X/2, X, 2X, 3X La si può vedere come regola empirica. Spiegazione intuitiva: è facile immaginare che la risposta sarebbe X su un grigliato regolare di quadrilateri (es su un toro), caso che approssima grossomodo quello medio. Ma ogni quadrilatero si divide in DUE triangoli (per chi fosse davvero curioso: cercare formula di eulero per una stima esatta invece che quella approssimata).