E' buono. E' quello che mi aspetto da un framework.
Ma.
Il materiale "normal mapping" chi gliel'ha assegnato alla lucertola? E i multimaterial? Ovviamente gestiti dal loop sui materiali. Chi viene prima? Come si chiamano? Come setto le trasformazioni ad ognuno? Lo posso fare?
Si leggiti i manuali, lo puoi fare. Solo che, purtroppo, essendo qualcosa di totalmente nuovo parti completamente svantaggiato, ci sono passato pure io, che, tra parentesi, ho sempre preferito le API DX in C a quelle in C++.
Tutto l'assegnamento è fatto in quel codice inguardabile presente nell'altro progetto? Così sembra. Chi lo chiama? Esiste da qualche parte un binding? Perchè è tutto nascosto?
Lo chiama Visual Studio quando compili (leggiti il manuale). Quando lanci il build, XNA prende i content sviluppati dai grafici e tramite il collante degli importer e dei processor crea il suo formato proprietario intermedio, ottimizzato a seconda della piattaforma, a partire a formati brutti e vecchi perché spesso sono quelli che la gente sa usare. Per esempio, alcuni processor sono parametrizzabili.
Tu dirai perché? Perché così è possibile cambiare il texture format che utilizzi senza dover toccare minimanente il codice, oppure sostituire il modo in cui la geometria o i lod sono creati senza dover rifare i modelli o mettere mano al codice di rendering.
Una cosa che mi hai fatto notare tu è proprio quella delle texture, un flag per lasciare al codice la gestione delle texture non sarebbe stato male.
Quella lucertola da dove arriva? Da max? Da Maya? chi ha fatto quell'fbx? Che materiale gli ha assegnato?
E' fatto così perché a chi scrive il codice non deve interessare da dove arriva la lucertola o di come sono stati gestiti i materiali sull'editor 3D.
Non potevano fare un exporter per il loro formato? Con dentro le mesh, le texture fuori ed i materiali fuori? Perchè usare formati vecchi e brutti per poi farli convertire da visual studio in qualcosa di ignoto?
E' quello che stavi criticando tu! E' il formato proprietario che però non lo devi integrare DENTRO i tool di grafica ma solo dentro la pipeline di build management del gioco. Così non hai bisogno di skill specialistiche.
Ad esempio nel mio caso i punti da cui i modelli sparano sono dei quad con una normale, messi nell'editor, con dei nomi appositi.
Piuttosto che farmi un plugin per Blender (non lo so fare) mi sono fatto un importer che mi tira fuori quei quad dalle geometrie (che arrivano pulite al processor) e mi genera un piccolo XML con le serializzazioni delle istanza dei BulletGenerator che mi servivano per quel modello comprensive di tutte le matrici di trasformazione necessarie.
L'XML è incompleto: perché tranne le informazioni geometriche, mancano i parametri sul tipo di sparo, che posso mettere io a mano, visto che il rognoso è parametrizzare le matrici di trasformazione rispetto al centro del modello e tutto il resto è tuning di game design.
L'XML gerato non c'è nemmeno bisogno che lo processo con un Processor, posso deserializzarlo passando direttamente dal ContentManager di XNA. Una volta sicuro, potrò rendere tutto serializzato in binario, così anche l'overhead del parsing non ci sarà, a costo zero, switchando un parametrino.
