Assimp-Dev: Monster-Todo

[Aramis]

So, ich denke alle Assimp-Beteiligten sind jetzt im neuen Zuhause angekommen :-) Um unsere Arbeit etwas zu ordnen haben Thomas und Ich heute in ICQ überlegt hier eine transparente und öffentliche Todo-Liste anzulegen, die sowohl den aktuellen Stand des Projektes als auch alle bekannten Bugs bzw. Limitierungen enthalten soll.

Wenn ihr damit einverstanden seit, so würde ich morgen Abend damit beginnen eine entsprechende Auflistung zu erstellen, die kann dann mal als Basis dienen in die jeder seine bislang noch verschwiegenen Bugs und potentiellen Problemstellen einfügen kann :D

Alex

[Alexander Kornrumpf]

Es wäre schön wenn ihr das Projekteforum mit einer Beschreibung von Assimp einweihen könntet.

[Aramis]

Lässt sich durchaus einrichten, würde ich sagen. Müsste halt vorher geklärt werden wie Projektvorstellungen auszusehen haben, denn der erste Eintrag dürfte layoutmäßig das Vorbild für alle Nachfolgenden sein.

Grob hätte ich jetzt gesagt: Zuerst Kurzbeschreibung, dann Projekteckdaten (Mitglieder, Entwicklungszeit, Homepage...), dann ausführlichere Beschreibung (evtl. mit Screenshots).

Alex

[Aramis]

So, das ist mal der aktuelle Status aller Importformate, inklusive aller mir bekannten Bugs. Ich schlage vor dass alle grünnamigen Teammember direkt diese Liste editieren, der Rest kann mir ja eine PM schreiben dann übernehme ich Änderungen.

Legende:

FIXME - Nur ein Bugfix erforderlich
TODO - Noch gar nicht implementiert
FEATURE - Größere Sache, die eventuell Änderungen am AssInterface mit sich bringen würde. Hier besteht Diskussionsbedarf.

Code: Alles auswählen

B3D
  Maintainer: Mark Sibly (blitzbasic.com)
  - Status: Scheint zu funktionieren, kein Animsupport,
    einige Modelle enthalten wohl keine Meshes?

X
   - Status: ausgereift
   - *** FIXED **** RGBA-Vertexfarben (kwxport_test_cubewithvcolors.x)
   - car2.x lädt nicht (dx sdk). Evtl. Problem mti Dekompression oder tats. Loaderbug?
  
AC
  - Status: ausgereift
  - FEATURE: Subdivision wird häufig benutzt, aber ist nicht 
    implementiert. Algo ist wenig überaschend Catmull-Clarke.

LWO
   - Status: Halbwegs ausgereift
   - FIXME: Hierarchie einzelner Ebenen wird nicht korrekt nachgebildet
   - FIXME: Transparenz wird nicht immer berücksichtigt
   - FIXME: In seltenen Fällen werden UV-Maps nicht korrekt zugewiesen
   - *** FIXED **** Koordinatensystem
   - *** FIXED **** Automatisch generierte Texturkoordinaten -> Basisachse
     und Windungsrichtung ist noch nicht ganz abgestimmt ->
    hängt mit Koordinatensystem zusammen.
   - *** FIXED **** Einige Modelle leiden unter extremen z-fighting an allen
     Flächen. Schreibt LightWave alle Flächen doppelt? Sind auch beim
     Export von LW nach DAE noch da, Importfehler also ausgeschlossen.
   - FEATURE: Subdivision-Patches werden nicht unterstützt. Siehe AC 
   - FIXME: UV coords, Skalierungen korrekt übernehmen

LXO

   - Unterformat von LWO, Luxology Modo 301
   - TODO: Reverse Engineering des Materialformats 

LWS
   - Status: Noch nicht praxistauglich
   - TODO: Animationssystem fertig implementieren. Momentan bloß
     (defaultmäßig deaktivierte) WIP-Implementierung,   
   - TODO: Korrekte Hierarchie für LWS2/LWS1-Modelle
   - *** FIXED **** Koordinatensystem

3DS
   - Status: Ausgereift
   - *** FIXED **** Animationen fertig machen. 
   - TODO: Kameranimationen in unser Form konvertieren

ASE
   - Status: Ausgereift
   - *** FIXED **** Einzelne Testfiles crashen, in wenigen Fällen wird
     der Nodegraph nicht korrekt erstellt. Exporte aus aktuellem
     Max gehen aber durchweg.
   - FIXME: Kameraanimationen sind nicht *absolut* korrekt.
     Siehe 3DS. TargetAnimation.cpp übernimmt die Konversion, ist
     aber noch WIP.

HMP
  - Status: Verwendbar (soweit als funktionierend bekannt)
  - FEATURE: Unterstützung für's Carrara HMP-Format?

MDL5
  - Status: Verwendbar (soweit als funktionierend bekannt)
  - Materialien erscheinen hin und wieder komplett schwarz


MDL7
  - TODO: Bone-support? Viel Code im Repos, aber weder getestet noch fertig
  - FIXME: Texturen werden nicht korrekt zugewiesen bei mehr als 2 UV-Kanälen

DXF
  - Status: Format nur teilweise implementiert. Komplexere Szenen
    mit Animationen werden zerupft. 
   
  - Funktioniert hervorragend mit Blender, Ac3D, Milkshape, ...
  - TODO: Für Max/AutoCAD/Maja/... ist das Format zu unzureichend
    implementiert. 

IRRMESH
  - Status: Ausgereift
  - Mehr oder weniger heiteres Rumraten wie Irrlichts krude
    Standardmaterialien am besten mit unserem Materialsystem
    wiedergegeben werden können

IRR
  - Status: noch nicht praxistauglich
  - TODO: Animationen werden nicht korrekt generiert
  - *** FIXED **** Animierte Meshes in der Szene sind um 90 Grad verdreht
  - FIXME: Unbekannte Nodes (zb Billboards) verursachen crashes

MD3
  - Status: Ausgereift
  - Multipart-Spielermodelle werden automatisch zusammengesetzt
  - .skin und .shader-files werden, sofern auffindbar, 
    gelesen und weitestmöglich auf unser Materialsystem
    übertragen
  - FEATURE: Vertexanimationen. Relativ wichtig. Es macht keinen Sinn
    Quake3-Spielermodelle perfekt laden zu können wenn sie sich dann
    nicht bewegen :-)

RAW
  - Status: Ausgereift

OFF
  - Status: Ausgereift

PLY
  - Status: Verwendbar
  - FIXME: Endlosschleife bei einigen Modellen aus dem Stanford-Repos.
  - TODO: Performance aund Speicherverbrauch sind KATASTROPHAL (und es
    gibt wirklich keine bessere beschreibung). Kurz und schmerzlos:
    ein 64 Bit System mit 8 GB RAM fängt bei extrem großen Modellen (
    > 20mio Dreiecke) an sich aus der Auslagerungsdatei zu bedienen.
  
Q3D
  - Status: Ausgereift
  - FIXME: Bei Szenen wird die Kamera nicht korrekt plaziert

TER
  - Status: Ausgereift

STL
  - Status: Ausgereift

OBJ
  - Status: Ausgereift
  - FIXME: Hin und wieder erscheint die Glanzkraft zu hoch,
    bzw. Modelle die nicht glänzen sollten glänzen.
 - TODO: Unterstützung für Bezierpatches notwendig?

COLLADA
  - Status: Verwendbar
  - TODO: Animationssupport
  - FIXME: object.dae
  - *** FIXED **** Maja-texturenbug
  - FIXME: AA.dae? 
  - FEATURE: Unterstützung für Collada 1.3?
  - TODO: Transparenz wird nicht unterstützt
  
MD5
  - Status: Verwendbar
  - *** DONE **** MD5Camera implementieren

SMD
  - Status: Noch nicht praxistauglich
  - TODO: Animationen funktionieren nicht
  - FEATURE: .qc-files und binäres MDL-Format implementieren?

BVH
  - Status: ausgereift

MD2
  - Status: ausgereift
  - FIXME: Nachprüfen ob man den Texturnamen nicht doch bei allen Files
    irgendwie erraten kann. Momentan wird wenn nicht erratbar $texture.png
    als dummy zurückgegeben.
  - FEATURE: Vertexanimationen. Siehe MD3.


NFF
  - Status: ausgereift

MDL
  - Status: ausgereift
  - FEATURE: Vertexanimationen. Siehe MD3.

Dann die Liste der sonstigen bekannten Bugs:

Code: Alles auswählen

- TransformUVCoords-Step verhaspelt sich manchmal und transformiert UV channels die er gar nicht transformieren soll.
- Externe Files werden hin und wieder mal nicht gefunden aufgrund falsch zusammengesetzter Pfade 
- Angebliche Crashes mit dodecahedron.nff auf irgendeiner GCC-Buildkonfig. Keine Ahnung welche ...
- *** DONE **** Koordinatensystem -> Änderung intern auf Y-up-RH.
- *** DONE **** Face-Order. Stimmt nun größtenteils, Probleme mit einzelnen Modellen.

Dann die allgemeine Todo- bzw Wunschliste. Auch alle Vorschläge und Featurerequests die während der letzten Monate eintrudelten sowie aller spontaner Schwachsinn der mal aufkam. Hauptsächlich damit sie nichts verloren gehen. Einiges ist zweifelsohne utopisch und wenig nützlich, anderes imho aber durchaus einen Blick wert

Code: Alles auswählen

 - OptimizeMeshes-Step
   Legt Meshes zusammen, wenn möglich. Nahezu *mush have*, einige AC, OBJ und Collada
   files bestehen am Ende der Pipeline momentan immer noch aus 2000-10000 Meshes.
 - OptimizeNodes-Step
   Durchaus sinnvoll, gleichzeitig muss eine Konfigurationsmöglichkeit bestehen um den Step
   davon abzuhalten spezielle Tagnodes rauszunehmen
 - OptimizeAnims-Step
   Ebenso wie FindInstances ein Luxusproblem, aber einen Blick wert
 - MS3D-Loader (Thomas)
 - Ogre-MESH-Loader 
 - FSRad OCT-Loader
 - Cartography Shop 4 
   (beide nicht so irre verbreitet, aber durchaus nützlich. Kaum Aufwand da man von irrlicht abtippen kann)
 - VRML (Entsetzlich aufwändig und ohne YACC wohl kaum zu bewältigen), X3D
 - FBX ------- Eventuell Binding an's FBX-SDK?
 - AN8 (Anim8or) - sollte kein problem darstellen.
 - BLEND - zuerst mal herausfinden ob eine Implementierung überhaupt möglich ist oder ob
   man gegen den gesamten Blenkernel linken müsste ...
 - XSI - sollte machbar sein
 - CSM (Mocap). Eine Testversion läuft bei mir, Hierarchie stimmt aber noch nicht
 - COB (Truespace). Seitdem TS auch noch kostenlos ist, durchaus eine Implementierung wert. Aufwand moderat.
 - Trainsimulator (MSTS?). PuMI wollte in die Richtung was machen, aktueller Status mir unbekannt
 - Multithreading? Gerade die Normalen und Tangentenberechnung braucht trotz O(nlogn) bei ganz großen
   Modellen extrem viel Zeit. Wenn man es geschickt anlegt dürften sie nahezu linear mit mehreren Threads
   skalieren. Ganz mal davon abgesehen dass man bei mehreren Meshes natürlich mehrere gleichzeitig
   bearbeiten kann.
 - Postprocessing-Pipeline -> Abhängigkeitsgraph erstellen lassen und Reihenfolge automatisiert ermitteln
 - aiMesh einen Member geben um den maximalen Winkel für das Normalensmoothing abzulegen. Mehrere
   Formate liefern diese Information, aufgrund der zentralen Normalenberechnung wird sie verworfen.
 - Regressionstestsuite (@Kimmi: assimp_cmd ist seit grade eben eingecheckt, Minidumps vergleichen geht noch nicht,
   die technische Möglichkeit welche zu erzeugen ist aber gegeben. Doku hat's auch.)
 - STL-Konfiguration für MSVC in Configheader schieben (AssimpPCH.h oder aiDefines.h). 
   Siehe http://sourceforge.net/forum/forum.php?thread_id=3000137&forum_id=817653

Die Liste der nicht den Assimp-Kern betreffenden Sachen/Projekte:

Code: Alles auswählen

- Viewer mit GL und wxwidgets/qt neu auflegen
- C#-Port. Maintainer: Matthias (rave3d)
- Java-Port. Maintainer: *ich*, noch nicht einsatzfähig
- Python-Port. Maintainer: Sebastian (EyDu). Aktueller Status?
- Blitzmax-Assimp. Externes projekt von Peter Scheutz (http://code.google.com/p/blitzmax-assimp/)

Alex

[Gelöschter Benutzer]

Train Simulator Shape-Format: Bin am ausklamusern wie das binäre Dateiformat vom MSTS nun aufgebaut ist. Es schaut nach 16Bit-floats aus :| oder ?-Format. Derzeit bastle ich an einer Konsi-Anwendung die alles extrahiert, damit der Dateiaufbau nun bekannt wird. Kontakt mit Paul Gausden vom MSTS/TRS Shape Viewer ist im Aufbau. Vielleicht kann er helfen.

By the way: Könntet ihr die Doku aktualisieren und im Assimp-Ordner einen docu-Ordner (falls nicht existent) mit einem generiertem CHM-Doku via Doxygen erstellen lassen? Was mich auch interessiert: Sind die Matrixdaten von Assimp in row order (DirectX)?

[Aramis]

By the way: Könntet ihr die Doku aktualisieren und im Assimp-Ordner einen docu-Ordner (falls nicht existent) mit einem generiertem CHM-Doku via Doxygen erstellen lassen?

Im ./doc/AssimpDoc_Html-Verzeichnis ist ein halbwegs aktuelles CHM-Kompilat eingecheckt. Eine nahezu genauso aktuelle Version ist auch online zu finden: Link

Sind die Matrixdaten von Assimp in row order (DirectX)?

Nunja, um nichts falsches zu sagen bemühe ich mal eine eindeutige Definition:
Der Translationsteil befindet sich in a4,b4,c4. Im Speicher sind das die Offsets 3,7,11. Meines Erachtens ist das 'row major', weil die Reihe als erstes genannt wird. Demnach ist es, um auf das DX-übliche Matrixlayout zu kommen, notwendig zu transponieren.

Alex

[Aramis]

So, nach den vereinten Patchingbemühungen der letzten 2 Wochen hat sich doch eine ganze Menge getan :roll: Ich hab die Liste dementsprechend mal aktualisiert. Bitte schreien sollte ich vergessen haben etwas als gefixt zu markieren.

[Mr.DX]

Nur mal so am Rande. Wieso verwendet ihr für das organisieren der TODOs, Bugs, ... kein Trac-System. http://trac.edgewall.org/ wäre beispielsweise ein recht nettes. In SourceForge ist es seit einiger Zeit auch innerhalb von wenigen Klicks als Feature eingefügt.
Die Aufgaben und ähnliches sind über Tickets organisiert, man hat alles auf einem Blick, z.B. http://trac.edgewall.org/report/1

[Aramis]

Gute Frage. Faulheit mag eine Hauptursache sein, vielleicht auch Zeitmangel und eine gewisse Unlust eine Administrationsinfrastruktur zu schaffen, die es den Usern noch einfacher macht utopische Featurerequests anzubringen :-). Du hast aber Recht, man sollte drüber nachdenken.

Ich hab die besagten wenigen Klicks mal gemacht, mal gucken was dabei herauskommt:
http://apps.sourceforge.net/trac/assimp/

Vielleicht könnten auch die anderen Teammember mal einen Blick drauf werden und ihre Meinung dazu kundtun :-)
EDIT: Positiv fällt mir auf dass die Versionsgeschichte viel besser einsehbar ist und Commitmessages sauber und übersichtlich formatiert werden. Die Anzeige des Quellcodes oder von Diffs hingegen ist endlos lahm.

[Schrompf]

Eine Frage in die Runde: ich wurde am Freitag von einem Herrn angeschrieben, der gern Assimp in seine Python-3D-IDE einbinden würde. Er erkundigte sich bei mir nach dem Stand der Python-Bindings... weiß jemand, wie es um die steht? Laut der Projektvorstellung hier hat Sebastian Hempel (EyDu) die Bindings geschrieben... Sebastian? Liest Du hier mit? Kannst Du mir ein bisschen was über den Stand der Bindings erzählen? Sind sie benutzbar? Gegen welche Revision hast Du die geschrieben? Hast Du irgendwelche Bestrebungen, die noch zu pflegen?

Evtl. macht das auch der Herr selbst. Momentan weiß ich noch nichts genaueres. Würde mich aber interessieren, wie es darum steht :-)

Bye, Thomas

[EyDu]

An den Python-Bindings habe ich seit einigen Monaten nichts mehr gemacht, da mir leider im Moment etwas die Zeit (und auch ein wenig die Lust zu programmieren) fehlt. Das wird sich auf Grund meiner Master-Arbeit bis zum Ende des Sommers wahrscheinlich auch nicht wesentlich ändern. So, genug gejammert ^^

Wie ich das sehe, sollten die Bindings mit Revsion 147 laufen, da ich zu diesem Zeitpunkt den ersten Commit durchgeführt habe. Die zu der Zeit vorhandene Assimp-Version habe ich dann bei mir nicht weiter aktualisiert. Implementiert und benutzbar sind zumindest die wichtigsten Komponenten, wenn man/jeman weiterentwickeln möchte, kann man sich an diesen recht gut orientieren.

"Der Herr" kann ja einen Blick in den Code werfen und schauen, ob dieser für ihn brauchbar ist. Bei Fragen könnte er mich auch per Mail oder ICQ anschreiben.

Bis dann,
Sebastian