R
hellihjb schrieb:
Welchen Vorteil siehst Du denn zu bestehenden Formaten?
exporter schreiben eigentlich nie in ein effizientes finales format, exporter generieren metadaten, diese sollten leicht verstaendlich, unmodifiziert (also ohne optimierungen und komplression) und langlebig sein.
erst ein resource compiler (oder auch die engine wenn's sein muss), konvertieren diese daten in ein gewuenschtest format.
es gibt viele vorteile, deshalb macht es jede halbwegs organisierte spielefirma so.
1. bei formatwechseln, muss man nicht alles neu exportieren. (und das ist selbst automatisiert aufwendiger als ein resourcecompiler, falls die automatisierung nach allen wuenschen klappt).
2. keine (bzw kaum) versions (kompatibilitaets) probleme, es muessen nicht alle auf einmal umstellen, jeder kann sich code und daten seperat besorgen, weil anhand der metadaten jede version die gewuenschten daten erzeugen koennen. das erlaubt auch sanfteres einfuehren und testen von neuen dingen, weil kaum jemand alles lokal testen kann sobald projekten/firmen etwas groesser werden.
3. flexibles arbeiten, weil optimierungen simpel gemacht werden koennen, da die metadaten noch alle informationen haben.
4. es gibt kein endianess wirrwarr, es ist klar lesbarer text, und pro attribute zu sagen dass es x y z ist, ebenfalls nuetzlich, fuer den fall das es eben nicht xyz, weil man die daten aus verschiedenen programmen exportiert die das 'offensichtliche' anders sehen.
5. ein resourcecompiler erlaubt es die daten pro plattform zu uebersetzen, es waere irgendwie seltsam das pro plattform einmal zu exportieren. es ist sicher gleich langsam, wenn man es von einem anderen plattformformat zu dem eigenen konvertieren muss (oder es reicht auch ne 'alte version'). metadaten haben das problem nicht unmengen an cross-convert-code zu halten.
6. man kann metadaten einfuegen die nichts mit den daten an sich zu tun haben, z.b. hints fuer qualitaet, streaming, autor, rechner, compression, etc.
und dann kann man auch sehen, dass es eigentlich kein argument gegen ein xml format fuer metadaten gibt.
1. groesse? es sind metadaten fuer die produktion, es jukt wohl kaum jemanden wie gross die sind. die werden nicht in versionskontrollen eingecheckt (man kann sie ja schliesslich mit den eingecheckten exportern und quelldaten immer wieder erzeugen).
2.geschwindigkeit? es dauert nicht wirklich laenger die zu laden (weil sich hoffentlich jeder coder mal std::map<filename,crc32> als cache basteln kann fuer sein system) und man fuer sein workingset sicher nur einen bruchteil konviertiert.
fuer den fall der faelle dass man alles braucht, hat der nightly build hoffentlich die ganzen convertierten daten bereithaellt.
3.eigentlich sollte das ziel in der entwicklung sein, dass man moeglichst jederzeit arbeiten kann (also nicht dass man sich GB an neuen daten ziehen muss, weil jemand etwas an formaten aendert) und man sollte sehr flexibel bleiben (also nicht bei jedem formatwechsel die erdkugel kurz anhalten weil es so einen riesen impact hat und man das entsprechend selten macht).
fuer finale daten sollte man das natuerlich nicht mehr nutzen. esseiden es macht einem wirklich nichts aus z.b. weil man ein sharewar spiel macht, das klein ist und trotz xml meshes gezippt 5MB hat oder so.
btw. (falls jemand bis hierher ueberhaupt gelesen hat:P) man muss das rad nicht neu erfinden, collada ist schon so ein xml format (auf das immer mehr firmen aufspringen). es sollte fuer so ziemlich jeden 3dmodeller einen exporter geben.