Gegenüberstellung von 3D-Fileformaten
-
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();
-
Ö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
-
Eher umgekehrt?!?
-
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.
-
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.
-
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
-
Können wir zum Topic zurück kommen?
Ich könnte mich noch Stunden über XML unterhalten,
aber nicht hier
-
wie schreibt man eigentlich so einen xml parser bzw wo gibts sowas?
-
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..
-
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.
-
eigentlich schreit das ganze nach einem metaformat.
rapso->greets();
-
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
-
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 lassenJa, ich könnte hier meinen Loader-Source posten, mach ich aber nicht.
Dafür ist er A) zu groß undist 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