[Assimp] Ogre 3D

[Jonathan]

Ich fände es echt gut, wenn Assimp Ogre3D laden könnte und würde auch mithelfen, das zu implementieren.

Prinzipiell ist es so, dass mein Spiel nunmal wirklich Animationen benötigt. Da die Grafiken mit Blender erstellt sind, und Blender ja noch nicht überall benutzt wird, gibt es mit den Exportplugins häufig Probleme.
Ich habe heute das von Ogre3D getestet und soweit ich das sagen kann, funktioniert das ganz gut (auch mit Animationen und so).
Außerdem ist Ogre ja schon recht bekannt, und das Format dürfte auch relativ gut dokumentiert sein und so. Ich denke es wäre ein wirklich guten Kandidat für Assimp.

Ok, also, wie gesagt, würde ich das (mit)machen. Die Frage ist jetzt, was die Leute vom Assimp Team davon halten, und ob jemand mitmachen will, oder mir vielleicht ein wenig helfen würde. (Ich kann mir vorstellen, dass es beim schreiben eines Importers für Assimp so manche Frage gibt, die nicht unbedingt in der Doku steht, und für die man sonst stundenlang Sourcecode lesen müsste, es würde die Sache dann enorm beschleunigen, wenn man jemandne z.B. per Instant Messeger fragen könnte).

[kimmi]

Als Ansprechpartner gerade für Fragen ist Aramis sicherlich der Richtige. Wie es um seine Zeit bestellt ist, kann ich allerdings nicht sagen.

@Aramis: Was sasgt du?

Gruß Kimmi

[Dirk Schulz]

Hi,

ist es denn sinnvoll, ein Modell-Format einer GameEngine zu unterstützen? Wenn man Ogre3D hat, dann wird man Assimp wohl kaum brauchen und andersrum, wer eine eigene Engine baut, wird wohl kaum als Modell-Format Ogre benutzen, oder? Aber da ihr Irrlicht auch unterstützt, kann man wohl Ogre auch unterstützen. :)

@Jonathan: Was ist deine Intention, Assimp zu nutzen, wenn ihr als Engine Ogre3D benutzt? Ist es nicht einfacher, von Blender direkt ins Ogre-Format zu exportieren? Falls du noch keinen Exporter gefunden hast, hier ist er:

http://wiki.blender.org/index.php/Exten ... xport/Ogre

Soll jetzt aber nicht negativ klingen, oder so!

Assimp ftw!
Aber manche Arbeit muss man sich nicht unbedingt machen, finde ich.

Dirk Schulz

[Aramis]

Wir haben bereits früher über das OGRE-Format diskutiert - dabei hat vor allem Schrompf Interesse an einem Loader angedeutet. Auch in diversen anderen Foren habe ich schon den Wunsch nach entsprechender Funktionalität in Assimp gesehen. Das Projekt wurde aber bislang nicht verwirklicht, insofern wäre Hilfe sehr willkommen und definitiv von allgemeinem Nutzen :-)

Ich kann gerne mithelfen - zu zweit an einem Loader zu schreiben ist vermutlich nicht so effektiv, aber grade bei Fragen zu Assimp's Datenstrukturen und Interna stehe ich gerne zur Verfügung. Bzgl. Animationen in Assimp ist Thomas vermutlich der bessere Ansprechpartner.

Via ICQ sind wir alle erreichbar, ich hab dir meine ICQ-Nummer per PM geschickt. Alternativ gäbe es auch noch #assimp auf freenode, ein Channel den ein begeisterter IRC-Fan mal eingeführt hat.

Bezüglich Subversion: du brauchst einen SourceForge-Account, dann geb ich dir Schreibzugriff. Im aktuellen Entwicklungsstand kann jederzeit WIP-Code in's Repos committed werden, vorausgesetzt er kompiliert auf gängigen Compilern und alle neuen Dateien sind in den vc-Solutions und dem CMAKE-File eingetragen.

Aber da ihr Irrlicht auch unterstützt, kann man wohl Ogre auch unterstützen.

Hehe, genau dazu hat sich mal der Herr der Ogre-Engine persönlich geäußert (http://www.ogre3d.org/forums/viewtopic. ... 33#p329241) :-) Besagter Thread geht übrigens das genaue Gegenteil: Assimp nach OgreMesh. Ist aber, glaube ich, im Sand verlaufen.

I'm slightly offended that Open Asset Import supports Irrlicht meshes but not our mesh format, which has been around much longer and is a lot more flexible. Oh well

:D

ist es denn sinnvoll, ein Modell-Format einer GameEngine zu unterstützen?

Generell nicht, abeer OgreMesh ist keine Insellösung sondern weit verbreitet und besitzt - angeblich - hervorragende Exporter mit Animationssupport aus den meisten 3D-Paketen heraus. Etwas, das weder Collada noch X noch MD5 gelingt.

- Alex

[Jonathan]

@Jonathan: Was ist deine Intention, Assimp zu nutzen, wenn ihr als Engine Ogre3D benutzt? Ist es nicht einfacher, von Blender direkt ins Ogre-Format zu exportieren?

Meine Intention ist es, animierte Modelle aus Blender zu exportieren und in meinem Spiel zu nutzen. Da ich eh schon Assimp benutze ist es denke ich nur wenig mehr Aufwand den Loader direkt für Assimp zu schreiben und dort ist er vielleicht nützlicher, als wie wenn er direkt in meinem Projekt wäre.

Natürlich könnte man sich jetzt auch überlegen, einen guten Exporter für ein bereits unterstütztes Forma zu schreiben, naja.

[Schrompf]

An einem OgreMesh-Loader hatte ich auch mal Interesse geäußert. Das war aber kein persönliches Interesse - DirectX und Collada funktionieren für uns größtenteils sehr gut. Meine Überlegung basierte eher darauf, dass a) es für das Format angeblich gut gepflegte Exporter für alle möglichen 3D-Modeller geben soll und b) dass das Format aufgrund seines Ursprungs als 3DEngine-internes Format sehr einfach auf die Assimp-Strukturen abbildbar sein müsste.

Ich kann Dir also gern per ICQ oder Skype ein bisschen Hilfe anbieten, aber ich selbst habe an dem Thema noch nichts gemacht und habe auch keine diesbezüglichen Absichten. Dazu gibt es einfach zu viele dringendere Sachen in meinem Hauptprojekt. :-)

Gleiches gilt übrigens auch für das Milkshape3D-Format, für dass ich vor langer Zeit mal leichtsinnig eine Umsetzung versprochen hatte.

[Jonathan]

Ich denke, ich werde die XML Version von Ogre benutzen. Es gibt ein Tool, das die Binärversion und die XML Version jeweils konvertieren kann.

Eine Möglichkeit für die Binärversion wäre es gewesen, Teile von Ogre für das laden zu benutzen. Dummerweise würden dadurch hässliche Abhängigkeiten entstehen, man müsste entweder die Ogrelib dazulinken, oder die benötigten Quelldateien rauskopieren, was Aufgrund von Lizenzproblemen bedeuten würde, das man einen kompletten LGPL Fork von Assimp bräuchte.
Die Binärdatei von Hand laden, tja, ich habe keine gute Dokumentation gefunden (nur den Tipp Ogre zu benutzen) und es würde auch wahrscheinlich um einiges komplexer sein. XML ist halt etwas größer und braucht demnach auch ein wenig länger zu laden, aber was solls.

Ich habe auch ein wenig mit Aramis gesprochen, aber prinzipiell können bei folgendem ja alle Assimp Entwickler helfen. Ich könnte eine grobe Vorgehensliste ganz gut gebrauchen. Und wenn dann noch Fragen auftauchen könnte man das ja gleich mit in die Liste packen, so dass Leute die später auch ein Format hinzufügen können das direkt und kompakt vor sich haben. Könnte eine menge Laberei sparen. Vielleicht gibts so eine Liste ja schon, dann wärs nett wenn die mir jemand zeigen würde.

[Aramis]

Ich könnte eine grobe Vorgehensliste ganz gut gebrauchen

Ich versuch es einfach mal grob als Liste zusammenzufassen - wer noch einen weiteren Punkt hat, möge ihn bitte in mein Posting hineineditieren.

• Header und Quellcodedatei für den neuen Loader anlegen und in den vc8/vc9 Solutions einfügen sowie in's CMAKE reinsetzen.
• Von BaseImporter ableiten - dabei am besten einen anderen Loader, z.B. Collada, als Vorlage nehmen.
• In der Importer.cpp den Loader eintragen (oben inkludieren, etwas weiter unten eine Instanz registrieren).
• BaseImporter::InternReadFile übernimmt das eigentliche Laden. Bei Fehlern eine ImportErrorException* werden.
• Sollte der Loader komplexer werden und evtl. aufwändige Konversionen benötigen: denn Parser und den Konverterteil in unterschiedliche Units/Klassen aufsplitten (wie z.B. bei Collada)
• Bitte kleine, aber aussagekräftige Testmodelle in <root>/test/models/<format> hinzufügen.
• Auch gegen die -noboost Projektkonfigs testen
• Zum Testen unbedingt Verbose-Logging und das aiProcess_ValidateDataStructure flag aktivieren

- Alex

[Schrompf]

Ja, die Liste trifft es schon sehr gut. Zu den Daten noch:

- alle Loader-Klassen sollen unikate Vertizes ausgeben. Also wirklich pro Dreieck 3 Vertizes am Stück, pro Quad 4 Vertizes, und so weiter. Einige der Post Processing Steps, die danach drübergehen, benötigen diese Struktur.

[Jonathan]

Hm, das heißt also, dass die Indexwerte einfach nur hochzählen?

[Schrompf]

Exakt. Der JoinVertices-Prozess macht daraus dann die klassischen indizierten Vertizes, aber das kommt erst am Ende. Bis dahin werden ja eventuell noch Texturen projeziert, Normalen/Tangenten/Bitangenten berechnet und sowas - die verlassen sich alle darauf, dass die Meshes "flache" Vertizes haben.

[Jonathan]

Wäre es ok, wenn ich statt irrXML ticpp benutzen würde?
Soweit ich das sehe, war das Hauptproblem, dass man den XML Parser an den IOHandler anbinden muss. Aber das sollte bei ticpp eigentlich kein Problem sein:
http://ticpp.googlecode.com/svn/docs/cl ... 47a6d58275
Man müsste nur die Textdatei mit dem IOHandler laden und zum parsen übergeben, schon sollte die Anbindung quasi perfekt sein. Als kleine Sicherheit könnte man noch die anderen Lade- und Schreibfunktionen private oder so machen.
Natürlich würde das Assimp wieder größer machen, aber der Code von ticpp hat bloß ~250kb. Assimp ist eh schon relativ groß und kompiliert ist das ja nochmal sehr viel weniger.

ticpp fände ich wesentlihc besser, da ich eh schon damit gearbeitet habe und mir dieses SAX Konzept sehr viel weniger gut gefällt, als DOM. Ich denke mit DOM kann man schneller und sicherer arbeiten, als mit SAX.

[Schrompf]

Ja, das ist ein Problem. Ich würde nicht noch eine Lib in den Code integrieren, nur um dem persönlichen Geschmack gerecht zu werden.

[kimmi]

Warum nicht die bereits vorhandenen Tools benutzen und damit den Wartungsaufwand minimal halten? Noch eine Lib für einen einzelnen Loader halte ich für keine gute Idee. Irgendwann hat jeder Loader dann 1-2 Libs, die nur er braucht und das erhöht die Konfusion. Ähnliches kenne ich schon aus der ZFXCE.
Meine Meinung in Kurzform also: Ich bin eher für IrrXml.

Gruß Kimmi

[Aramis]

Wie bereits in ICQ geäußert: kompakte Abhängigkeiten die man mit in's Repos packen kann sind im Prinzip kein Problem. Aber 2 XML-Parser in einem Projekt, das sich nur abschnittsweise mit XML-Verarbeitung beschäftigt - da sehe ich keine Rechtfertigung für.

Natürlich kann man auch über IrrXML eine Art Mini-DOM packen - den Output des SAX-APIs in eine hierchische Objektstruktur umkopieren und ein paar generische Hilfsmethoden drumrum basteln.

Nebenbei ist ein großer Vorteil von SAX-Parsern auch deren hohe Geschwindigkeit gepaart mit einem Speicheroverhead nahe 0. Grade, weil du dir Sorgen um die Geschwindigkeit machst ist das definitiv ein Argument zugunsten IrrXML bzw. unserer, an allen Ecken und Enden gefixten Variante davon :-)

[Jonathan]

WIP:




Materialien und Animationen kommen dann nächste Woche^^

[Aramis]

Gratulation! Sieht definitiv so aus, als würde es funktionieren :-)
Willst du schon was committen? Dann bräuchte ich deinen SF.net-Usernamen ...

[Jonathan]

Der wäre dann quasi: jonathanklein
Allerdings denke ich, dass ich den Importer erst quasi fertig schreiben werde, weil im Moment lohnt sich ein Commit ja noch nicht so wirklich.

[Aramis]

Done :-)

[Schrompf]

Irrtum: Betrachte das Repository als eine Art Backup. Jedesmal, wenn Du eine nennenswerte Änderung geschafft hast, solltest Du das hochladen. Wär doch schade drum, wenn Deine Wohnung abbrennt und die ganze Arbeit verloren wäre. Das Sourceforge-Repos dagegen ist geduldig und niemand wird Dich anzählen, wenn WIP-Code noch nicht alle Funktionalität erfüllt, die er am Ende mal erfüllen soll.

Also: check ein! Besser heute als morgen :-)

[Jonathan]

Naja, aber wenn man jetzt eine aktuelle Version haben will und die auscheckt und da geht noch fast gar nix, oder im Gegenteil, einige Dinge sind gerade im Umbau und funktionieren nicht, ist das doch ärgerlich. Ich glaube, dafür bietet SVN eine Lösung, aber so doll hab ich mich damit noch nicht beschäftigt.
Egal, ich habe ein anderes Problem: Offensichtlich ist das mit den Materialien nicht so genau definiert. Mal steht in der Datei nur der Materialname, aber nicht in welcher Materialdatei sich das ganze befinden soll, mal steht da was wie "Materials/Fish", wo es dann eine "Materials.materials" gibt, in der ein Material Namens "Fish" vorkommt.
Ich könnte nach einer Handvoll default namen suchen oder aber alle .materials Dateien im selben Ordner auflisten. Beides finde ich nicht so supi.

Mit den geteilten Materialdateien gibt es auch noch ein Problem:
Lade ich 100 Objekte, parse ich 100 mal die selbe Datei. Selbst wenn ich nur bis zum benötigten material gehe, parse ich halt 100 mal die halbe Datei (durchschnittlich). Vielleicht will ich aber auch nur ein paar Extramaterialien im OgreFormat speichern, dann würde ich eine aiScene mit allen Materialien und keinen meshs wollen (wird so etwas überhaupt unterstützt??).
Optimal wäre halt eine Art Ressourcenmanager, aber ein solcher Assimp intern wäre vielleicht nicht das geschickteste (außerdem gibt es den schlicht nicht), ein externer könnte aber kaum genutzt werden, denn dann müsste der schon sehr stark an den Importer angebunden sein.

Gut, beim modellieren kann man darauf achten, dass man am Ende nicht eine riesige Materialdatei hat, sondern für jedes Modell eine. Ich könnte immer nur das benötigte Material laden, es sei denn, es wird nicht das Mesh, sondern die Materialdatei direkt geladen, dann würde ich kein Mesh erstellen, aber dafür sämtliche Materialien laden.
Aber für das "Materialdatei finden" Problem weiß ich noch keine annehmbare Lösung...

[Aramis]

Hoi -

wie versprochen, die Dokumentation enthält nun eine eigene Seite, die den Workflow für Importerschreiberlinge enthält. Zudem sind die Docs für einige interne APIs (z.B. BaseImporter) nun defaultmäßig mit dabei.

[Jonathan]

Ja, das sieht doch schon recht fein aus.
Was noch rein sollte, wäre, dass die Vertexe alle eindeutig sein müssen, eben das, was Schrompf angesprochen hat.
"No advance to the" soll glaub ich "Now ..." heißen, sonst macht es weniger Sinn.

Und es wäre ganz gut, wenn das Material erstellen noch ein Tick ausführlicher wäre, ich weiß grade nicht genau, was ein MaterialHelper ist und wie man damit ein Material in die Szene bekommt, wenn das Codebeispiel noch eine handvoll Zeilen mehr hätte, wäre das glaub ich sehr gut.

Ahja, ich glaube es fehlt auch, dass die Szene mindestens ein RootNode enthalten muss und so.

[Jonathan]

Ich glaube, bei Materialien mach ich es jetzt so:
Ich suche Standardmäßig, ob eine Materialdatei existiert, die so heißt, wie die MeshDatei. Tut sie das nicht, suche ich eine Sammeldatei, deren Namen man über einen globale Variable angeben kann (Assimp::Ogre::DefaulMaterialName oder so). Das ist denke ich ein guter Kompromiss, den es scheint wirklich kein definiertes Vorgehen zum finden des Materials zu geben.
Klar, globale Variablen sind böse, man könnte einen Fall konstruieren, wo das gehörig schief geht (2 parallele Ladethreads oder so), aber es gibt ja imo keine Format spezifischen Ladeoptionen und so ist es auch ein minimaler Eingriff in den Assimp Ladevorgang.
Ich meine, falls jemand eine bessere Idee hat, immer her damit.

[Aramis]

Hoi - globale Variablen braucht es nicht, dafür gibt es Importer::SetPropertyXXX. Du legst in der aiConfig.h dem bisherigen Schema folgend eine neue Konstante samt Dokumentation an, überschreibst dann zusätzlich noch die BaseImporter::SetupProperties, und fragst darin die Eigenschaft ab, womit diese pro Importauftrag und somit threadsicher setzbar wäre.

Lade ich 100 Objekte, parse ich 100 mal die selbe Datei. Selbst wenn ich nur bis zum benötigten material gehe, parse ich halt 100 mal die halbe Datei (durchschnittlich). Vielleicht will ich aber auch nur ein paar Extramaterialien im OgreFormat speichern, dann würde ich eine aiScene mit allen Materialien und keinen meshs wollen (wird so etwas überhaupt unterstützt??).

Ich würde wie folgt vorgehen (etwas aufwändigerer, aber löst das Problem für die, die es lösen wollen):

Assimp ist durchaus in der Lage Szenen zu importieren, die nur Materialien oder Animationen enthalten. Dazu gibt es ein Flag für aiScene::mFlags, das hauptsächlich dazu führt dass der Validator solche Szenen nahezu ungeprüft durchlässt. Du müsstest also den Importer auch auf die Dateikennung der Ogre-Materialfiles registrieren, und in dem Fall einfach alle Materialien lesen und in die Szene packen. Dazu käme dann eine weitere Importoption für den Ogre-Loader -> diese würde ihn dazu veranlassen einfach gar keine Materialdatei zu lesen, sondern Dummy-Materials, die nur einen Namen tragen, in der Szene zu platzieren.

Für normale Zwecke ändert sich gar nichts. Wer will, kann dann aber die Materialfiles und Meshes separat lesen und später manuell zusammenführen.

- Alex

[Jonathan]

Ahja, für sowas wäre eine Sektion mit Format spezifischen Dokumentationen enorm hilfreich. Auch damit der Benutzer weiß, was in welchem Format unterstützt wird und was nicht.

[Thoran]

Ich glaube, bei Materialien mach ich es jetzt so:
Ich suche Standardmäßig, ob eine Materialdatei existiert, die so heißt, wie die MeshDatei. Tut sie das nicht, suche ich eine Sammeldatei, deren Namen man über einen globale Variable angeben kann (Assimp::Ogre::DefaulMaterialName oder so). Das ist denke ich ein guter Kompromiss, den es scheint wirklich kein definiertes Vorgehen zum finden des Materials zu geben.
Klar, globale Variablen sind böse, man könnte einen Fall konstruieren, wo das gehörig schief geht (2 parallele Ladethreads oder so), aber es gibt ja imo keine Format spezifischen Ladeoptionen und so ist es auch ein minimaler Eingriff in den Assimp Ladevorgang.
Ich meine, falls jemand eine bessere Idee hat, immer her damit.

Das Material in einer Mesh-Datei bezeichnet einen Materialnamen. In Ogre ist dieser normalerweise in einem *.material-Skript definiert. Diese Skripte werden bei Ogre durch den ResourceManager beim Programmstart aus Verzeichnissen geladen, die über Konfigurationsdateien oder im Quellcode angegeben werden. D.h. die Mesh-Datei selbst referenziert keine *.material Dateien, sondern nur den Namen des Materials. Exporter wie in Blender erzeugen soweit ich weiß meistens ein Material-Skript im Stil von: <Meshdateiname>.material. Wenn dieses Material in der Meshdatei referenziert werden soll, muss dazu der Materialname in Blender entsprechend gesetzt werden.

Ich hoffe das hilft dir weiter.

Thoran

[Jonathan]

Materialien werden jetzt auch gelesen.

[Schrompf]

Es entwickelt sich! Sehr schön :-)

[kimmi]

Feines Modell :-), da bekommt man Lust auf mehr ( vom Ogre-Importer ).

Gruß Kimmi