4. Definizione dei materiali

5
Il tuo voto: Nessuno Media: 5 (1 vote)

Nei capitoli precedenti abbiamo potuto constatare che utilizzando più textures è possibile dare più credibilità ad una superficie incrementando il livello di dettaglio e il numero delle componenti che costituiscono un materiale. La trattazione di questo argomento tuttavia è ben lontana dall'esaurirsi per due motivi: il primo è che non abbiamo ancora visto tutte le componenti possibili che ci permetteranno di creare uno shader abbastanza flessibile da rappresentare in modo convincente un buon numero di materiali; il secondo è dato dal fatto che c'è la possibilità di vedere un file .fx come un materiale autonomo avendo la libertà di inserire tutti i parametri di cui abbiamo bisogno per gestire qualsiasi tipo di superficie in modo specifico e quindi realistico.

Ognuno di questi due metodi hanno dei pro e dei contro. Utilizzando in modo consistente il primo metodo è possibile avere un'interfaccia unica tra codice C# ed effetto e standardizzare tutti gli oggetti utilizzati secondo la definizione scelta di materiale; il contro è che, proprio per la grande flessibilità si ha un basso livello di ottimizzazione, soprattutto nel caso di materiali molto semplici che richiedono l'inizializzazione di pochi parametri rispetto a quelli gestiti dall'effetto. Utilizzando il secondo metodo, al contrario, è possibile ottimizzare al massimo ed in modo indipendente ogni materiale (e quindi ogni file .fx); il contro di questo approccio però è quello di avere un'interfaccia differente, tra codice C# ed effetto, per ogni materiale da rappresentare, con conseguente necessità di scrivere del codice specifico.

Visto da questa prospettiva sembra che il problema non possa essere risolto in modo efficiente dato che i pro ed i contro dei due metodi sono esattamente complementari; è invece possibile ottenere il massimo da entrambi. È buona pratica infatti utilizzare un'unica interfaccia per le geometrie che dobbiamo manipolare manualmente da codice incapsulando invece i materiali creati ad hoc nei formati che definiscono i modelli (files .x e .fbx) e che il  Framework XNA gestisce automaticamente in fase di rendering.

Affrontiamo ora il primo metodo isolando le componenti primare di un materiale generico ed analizzandole separatamente. È tuttavia necessario definire ora una convenzione per la denominazione di vettori che saranno utilizzati nei capitoli successivi specificandone il significato ed il modo di calcolarli:

 nome convenzionale [nel codice]  descrizione
normale locale [normal] vettore normale (perpendicolare) al punto sulla superficie indirizzato dal Pixel Shader in tangent-space
vettore illuminazione [LightVec]

per le luci omindirezionali o spot: vettore che va dal punto sulla superficie indirizzato dal Pixel Shader all'origine della sorgente luminosa in tangent-space

per le luci direzionali: vettore che indica l'inverso della direzione della sorgente luminosa
(inverso di v equivale a -v) in tangent-space

vettore vista [ViewVec] vettore che va dalla posizione della telecamera al punto sulla superficie indirizzato dal Pixel Shader in tangent-space
normale world-space [WorldNormalVec] vettore normale al punto sulla superficie indirizzato dal Pixel Shader in world-space.
vettore vista in world-space [WorldViewVec] vettore che va dalla posizione della telecamera al punto sulla superficie indirizzato dal Pixel Shader in world-space.