Gegenüberstellung von 3D-Fileformaten

DocJunioR

Mich interessiert mal, was welches 3D-Format kann und evtl. wie hoch der Aufwand im Vergleich zu anderen ist, diese zu lesen/schreiben. (evtl. mit grobem Dateiaufbau)

Kane

Alsooo, hier die Formate mit denen ich bisher gearbeitet habe:

Wavefront Objectfile:
Format: Text
Aufbau extrem simpel, einen Im/Exporter könnte man so runterschreiben.
Außer Polygonen und Verweise auf Texturen kann man allerdings auch keine
weiteren Infos unterbringen.

ASE:
Format: Text
Siehe Wavefront, vom Aufbau her komplexer, wesentlich mehr Infos kriegt
man aber auch in dieses Format net rein.

Cinema 4D XML:
Format: Text (XML)
Mein kleiner Liebling.
Dank XML wird das parsen zu einer Wohltat (libtinyxml benutzen!!)
und extra Infos wie Transformationshierachie, Animation, Bones,
andere nicht Polygon-Objecte (Lights) etc werden mit gespeichert.
Für den Importer/Exporter kann man, je nach Features die man benötigt,
ein Wochenende einplanen.

MD3 (Quake3):
Format: Binär
Jeder md3 enthält Polygon-Mesh(es) die über Keyframing animiert sein können.
Im Verbund werden mehrere (meist 2: Torse und Beine) md3-Files über Tags (aka einfache Matrizen) zu einem Mesh zusammen gefasst.

MD5: (Doom3)
Format: Text
Ähnlich wie MD3 sehr problemorieniert Ausgelegt.
Unterstützt Boning und das Abspeichern von Animationen
in getrennten Files.
Das Laden is relativ easy.
Linksky: www.nowan.net/cb/3d/

spl*t

Ich glaube da kann ich doch glatt in diesem Thread mal fragen, was andere so von meinem erdachten "Format" halten. Ich hatte nämlich keine Lust mich irgendwo einzuarbeiten und habe mir gedacht, dass ich die Infos, die ich brauche, selbst unterbringen könnte.
Das ganze ist XML und folgendermaßen aufgebaut:

<?xml version="1.0" encoding="ISO-8859-1"?>
<entity>
 <textures>
  <colormap>
   <format>
    <type>bmp</type>
   </format>
   <name>data/textures/rockwall.bmp</name>
  </colormap>
  <normalmap>
   <format>
    <type>bmp</type>
   </format>
   <name>data/textures/rockwall_normal.bmp</name>
  </normalmap>
  <heightmap>
   <format>
    <type>bmp</type>
   </format>
   <name>data/textures/rockwall_height.bmp</name>
  </heightmap>
  <glossmap>
   <format>
    <type>bmp </type>
   </format>
   <name>data/textures/rockwall_gloss.bmp</name>
  </glossmap>
 </textures>
 <vertexcount>6</vertexcount>
 <boundingbox>
  <ldf>
   <x>-1.001</x>
   <y>-1.001</y>
   <z>-0.001</z>
  </ldf>
  <rdf>
   <x>1.001</x>
   <y>-1.001</y>
   <z>-0.001</z>
  </rdf>
  <ruf>
   <x>1.001</x>
   <y>1.001</y>
   <z>-0.001</z>
  </ruf>
  <luf>
   <x>-1.001</x>
   <y>1.001</y>
   <z>-0.001</z>
  </luf>
  <ldb>
   <x>-1.001</x>
   <y>-1.001</y>
   <z>0.001</z>
  </ldb>
  <rdb>
   <x>1.001</x>
   <y>-1.001</y>
   <z>0.001</z>
  </rdb>
  <rub>
   <x>1.001</x>
   <y>1.001</y>
   <z>0.001</z>
  </rub>
  <lub>
   <x>-1.001</x>
   <y>1.001</y>
   <z>0.001</z>
  </lub>
 </boundingbox>
 <polygons>
  <point>
   <normal>
    <x>0.0</x>
    <y>0.0</y>
    <z>1.0</z>
   </normal>
   <tangent>
    <x>1.0</x>
    <y>0.0</y>
    <z>0.0</z>
   </tangent>
   <bitangent>
    <x>0.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </bitangent>
   <texcoord>
    <x>0.0</x>
    <y>0.0</y>
   </texcoord>
   <vertex>
    <x>-1.0</x>
    <y>-1.0</y>
    <z>0.0</z>
   </vertex>
  </point>
  <point>
   <normal>
    <x>0.0</x>
    <y>0.0</y>
    <z>1.0</z>
   </normal>
   <tangent>
    <x>1.0</x>
    <y>0.0</y>
    <z>0.0</z>
   </tangent>
   <bitangent>
    <x>0.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </bitangent>
   <texcoord>
    <x>1.0</x>
    <y>0.0</y>
   </texcoord>
   <vertex>
    <x>1.0</x>
    <y>-1.0</y>
    <z>0.0</z>
   </vertex>
  </point>
  <point>
   <normal>
    <x>0.0</x>
    <y>0.0</y>
    <z>1.0</z>
   </normal>
   <tangent>
    <x>1.0</x>
    <y>0.0</y>
    <z>0.0</z>
   </tangent>
   <bitangent>
    <x>0.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </bitangent>
   <texcoord>
    <x>0.0</x>
    <y>1.0</y>
   </texcoord>
   <vertex>
    <x>-1.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </vertex>
  </point>
  <point>
   <normal>
    <x>0.0</x>
    <y>0.0</y>
    <z>1.0</z>
   </normal>
   <tangent>
    <x>1.0</x>
    <y>0.0</y>
    <z>0.0</z>
   </tangent>
   <bitangent>
    <x>0.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </bitangent>
   <texcoord>
    <x>1.0</x>
    <y>0.0</y>
   </texcoord>
   <vertex>
    <x>1.0</x>
    <y>-1.0</y>
    <z>0.0</z>
   </vertex>
  </point>
  <point>
   <normal>
    <x>0.0</x>
    <y>0.0</y>
    <z>1.0</z>
   </normal>
   <tangent>
    <x>1.0</x>
    <y>0.0</y>
    <z>0.0</z>
   </tangent>
   <bitangent>
    <x>0.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </bitangent>
   <texcoord>
    <x>1.0</x>
    <y>1.0</y>
   </texcoord>
   <vertex>
    <x>1.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </vertex>
  </point>
  <point>
   <normal>
    <x>0.0</x>
    <y>0.0</y>
    <z>1.0</z>
   </normal>
   <tangent>
    <x>1.0</x>
    <y>0.0</y>
    <z>0.0</z>
   </tangent>
   <bitangent>
    <x>0.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </bitangent>
   <texcoord>
    <x>0.0</x>
    <y>1.0</y>
   </texcoord>
   <vertex>
    <x>-1.0</x>
    <y>1.0</y>
    <z>0.0</z>
   </vertex>
  </point>
 </polygons>
</entity>

Mich würde interessieren, ob das üblich ist oder irgendwas Schwachsinniges festgestellt werden konnte. (Naja, dass man mit Punkten und Indicies arbeiten könnte ist mir schon klar, aber es soll so einfach wie möglich sein, und Festplattenplatz ist mir erstmal weniger wichtig)
Was mich besonders interessiert: Sind alle diese Infos in md3 / 3ds ect. enthalten, bzw. wäre es einfach einen Converter in "mein Format" zu schreiben?
Übrigens hatte ich vor, dass dann noch zu einem Levelformat zu erweitern, wobei es dann mehrere "entities" mit jeweils einer Textur gibt, und diese wiederum zu Gruppen zusammengefasst werden (mit extra bounding box je Gruppe)

rapso

das format schaut ja nett aus, aber die daten vom mesh würde ich nicht direkt reinschreiben, sondern auf eine externe datei verweisen (genau so wie du es bei dem bild machst), sonst verlierst du die ganze übersichtlichkeit der xml datei.

"<format>
<type>"
das klingt doppeltgemoppelt, eines würde doch reichen denk ich mir.du könntest auch unnötige gliederungen vermeiden, die nützen ja eigentlich nichts.

z.b.

<textures>
  <texture="colormap" type="bmp" name="data/textures/rockwall.bmp" />
  <texture="normalmap" type="bmp" name="rockwall_normal.bmp" />
  <texture="heightmap" type="bmp" name="rockwall_height" />
</textures>

dadurch bekommst du auch ein wenig mehr flexibilität, denn eine neue art von "texture" wäre nur ein parameter und es ist sehr viel einfacher für menschen zu lesen (das ist ja der hauptgrund ein human-readable-format zu nutzen)

rapso->greets();

Kane

Öhm Splat, ich kann rapso nur zustimmen, pack die "wirklichen" Daten in eine
andere, möglichst nicht-xml, Datei.
XML hat, je nach Lib die man benutzt ein, ein File / RAM-Größenverhältnis von
1 : 8

Sgt. Nukem

Eher umgekehrt?!?

Kane

Verdammte Grundstufenmathematik ^^
Was ich sagen will, ein auf der Padde 1 MB großer XML-File
benötigt geladen im Speicher bis zu 8 MB.

de_Bert

Kane schrieb:

Verdammte Grundstufenmathematik ^^
Was ich sagen will, ein auf der Padde 1 MB großer XML-File
benötigt geladen im Speicher bis zu 8 MB.

ja liegt wohl daran das die meineste Xml-Parser den Tree im Speicher aufbauen. Also am besten darauf achten sonst platzt dir der Speicher. Alles was mit DOM anfängt ist nur für XML-Datei bist ca. hochstens 10 MB gedacht.

Am besten ist es wohl einen Parser zu verwenden der dir jeden XML-Tag einzeln gibt anstatt alles aufeinmal.

Kane

Ja so eine lib-stream-parse-xml wär schon was feines, aber net besonders performant.
XML ist ja auch net dafür gedacht unzählige floats etc. zu speichern.
Das geht immer noch am besten in einem reinen Binärfile.

Persönlich mach ich das meistens so:
Ein schlauer (und kleiner) XML-File hat alle Offsets, Größen
Bereiche und Infos die ich brauche um einen dicken Binärfile
auszulesen.
Der Binärfile ist eingentlich nur ein MemoryImage einer komplexeren
Struktur, er brauch aber keinen internen Aufbau haben, dafür ist
der XML-Teil zuständig.

Besonderer Vorteil bei Meshes:
Im XML-File kann man mal eben die Textur oder die Skalierung eines Meshes
ändern. Versuch das mal mit Binädaten

Kane

Können wir zum Topic zurück kommen?
Ich könnte mich noch Stunden über XML unterhalten,
aber nicht hier

otze

wie schreibt man eigentlich so einen xml parser bzw wo gibts sowas?

DocJunioR

die libtinyxml ist nen kleiner XML-Parser..
im Endeffekt muss man aber nur alle Worte voneinander trennen, bzw. nach < suchen. alles, was bis zum nächsten > ist name einer klasse oder so..

Aaber ich hab eigentlich nicht gefragt, wie ich mir nen Dateiformat selber baue. Das würd ich auch selber hinbekommen. Mir gehts aber darum portabel zu sein und nicht auch noch nen Modeller bauen zu müssen..

Cpp_Junky

Ich kann noch das Anim8tor-Format (.an8) empfehlen.
Es ist sehr einfach zu interpretieren und unterstützt (gefährliches Halbwissen) AFAIK auch Keyframe-Animationen. Ich habs nur für statische nicht-animierte Models genutzt, darum weiss ich es nicht genau.
Das Format ist in ASCII-Form geschrieben und ist, wie ich finde sehr sauber aufgebaut. Zu den Vertex- und TexCoord-Listen werden Index-Listen mitgespeichert. Material-Eigenschaften sind natürlich auch mit von der Partie
Der Editor dazu ("Anim8tor") ist übrigens auch nicht schlecht und vor allem Freeware.

rapso

eigentlich schreit das ganze nach einem metaformat.

rapso->greets();

cpt.oneeye

Kane schrieb:

Cinema 4D XML:
Format: Text (XML)
Mein kleiner Liebling.
Dank XML wird das parsen zu einer Wohltat (libtinyxml benutzen!!)
und extra Infos wie Transformationshierachie, Animation, Bones,
andere nicht Polygon-Objecte (Lights) etc werden mit gespeichert.
Für den Importer/Exporter kann man, je nach Features die man benötigt,
ein Wochenende einplanen.

Gibts da wo ein Tutorial oder infos dazu?

gruss
cpt.oneeye

Kane

Gibts da wo ein Tutorial oder infos dazu?

k.A. Google mal. Ich hab mir einfach einen simplen File mit einem Würfel
angeschaut und etwas probiert.

Du suchst einfach nach den obj_polygon-Tags (unter
c4d_file -> v6_basedocument -> v6_root_object -> v6_rootlist2d),
die Daten sind dann in den Subtags tag_uvw (uv's), tag_polygon (indices)
und tag_point (vertices).
Die TransformationsMatrix kannste 3 vector-Tags entnehmen unter obj_polygon -> v6_baseobject.

Mach mit Cinema einfach mal eine Würfel, konvertier ihn zu einem editierbaren
Mesh und Trianguliere ihn. Daraus kann man eigentlich alles entnehmen.

Eine Besonderheit gibts es allerdings:
Wenn du die Daten triangulierst, speichert Cinema trotzdem 4 uv-Paare pro
Triangle. Also einfach 3 laden, einen fallen lassen

Ja, ich könnte hier meinen Loader-Source posten, mach ich aber nicht.
Dafür ist er A) zu groß und ist er in meine Engine integriert, d.h.
keiner außer mir könnte ihn compilen, da ihm die Dependencies fehlen.
Außerdem macht selber denken mehr Spaß und warum sollt ihr es einfacher haben als ich :p

Edit: unterschwellige Botschaft vergessen