ZFX + Developia

Assimp wird auf Linux (CMake) derzeit nicht fehlerfrei gebaut.

Einerseits funktionieren die Unit-Tests nicht, weil erstens die cppunit-Kopie im contrib-Verzeichnis nicht in den Include Path aufgenommen wird und sich zweitens die Boost-Workarounds auf GCC 4.3.4 anscheinend nicht kompilieren lassen (eine lange Liste wüster Fehlermeldungen wie »assimp/test/unit/BoostWorkaround/../../../include/BoostWorkaround/boost/tuple/tuple.hpp:155: error: class ‘boost::tuple<T0, T1, T2, T3, T4>’ is implicitly friends with itself«).

Andererseits wird in den CMakeLists zu assimp_cmd fix zu »comctl32.lib« und »Winmm.lib« gelinkt, die auf Linux natürlich nicht existieren. Der folgende Patch behebt das Probelm, assimp_cmd scheint weiter zu funktionieren. Mangels README oder zumindest einem funktionierenden »./assimp_cmd help« kann ich das aber nicht wirklich überprüfen.

Aramis hat geschrieben:Ich setze morgen noch Infos über die Existenz eines offiziellen D-ports auf die Assimp-Seite, somit wäre ich da durchaus zuversichtlich.

Da ich einen Link zu http://assimp.sf.net auf ein paar D-Seiten gepostet habe, wäre es wohl geschickt, das so bald wie möglich zu tun…

Ich hab mal Links und Hinweis auf die HP gesetzt, ich hoffe du bist in der Form damit einverstanden. Morgen kann ich dann gerne noch Änderungen vornehmen ;)

Aramis hat geschrieben:Ich hab mal Links und Hinweis auf die HP gesetzt, ich hoffe du bist in der Form damit einverstanden. Morgen kann ich dann gerne noch Änderungen vornehmen ;)

Ich habe gerade gemerkt, dass mir der Broweser-Cache einen Streich gespielt haben dürfte – sorry, falls die D-Bindings eh schon seit längerem erwähnt worden sind. :)

Edit: Ich würde den Hinweis zu D auf der »Documentation«-Seite fast auf »There's a README in the port/dAssimp directory« abändern, damit gleich ersichtlich ist, dass dAssimp ganz normal im SVN liegt. Geschmackssache…

Danke für den Linux-Patch. Ich habe das zugegebenermaßen aufgrund der Tatsache, daß ich auf meinem Developer-PC noch keine Linux-Installation habe, noch nicht unter Linux getestet. Ich bau erst mla deinen Patch ein und werde das dann noch mal etwas genauer testen.

Gruß Kimmi

Hoi,

Ein vielleicht etwas überaschender, weil völlig ungeplanter, zugleich etwas umfangreicherer Patch:

• (Fast) alle textbasierten Loader kommen nun mit Unicode-Eingabedateien klar (UTF8, UTF16 LE/BE, UTF32 LE/BE). Alles wird nach UTF-8 konvertiert, zum Einsatz kommt die Referenzimplementierung des Unicode-Konsortiums (die ist nicht kompakt, funktioniert dafür aber äußerst zuverlässig).
• Auch IrrXML verwendet nun den Unicode-Konverter anstelle eines simplen Typcasts.
• aiString ist in der Dokumentation nun explizit als UTF-8 String markiert. aiString::length ist also nur noch die binäre Länge des Strings, wenn Multibyte-Sequenzen eingebettet sind ist die tatsächliche Länge des Strings entsprechend kürzer.

Alle diese Änderungen sind vollständig rückwärtskompatibel, wer bislang einen aiString als ASCII-Zeichenkette sah, kann dies auch in Zukunft machen, erhält für japanische Sonderzeichen dann aber naturgemäß nur Schrott :-)
Ich hab soweit es ging mit einer großen Anzahl an Modellen getestet, und konnte keine Probleme feststellen. Dennoch ist die Änderung weitgreifend und betrifft nahezu die Hälfte aller Loader ... ich bitte euch also, ebenfalls vorsorglich nochmals zu testen und auftretende Probleme zu melden bzw. einen revert durchzuführen (ich bin die nächsten Tage eventuell nur eingeschränkt am Internet)

- Alex

Ich will jetzt hoffentlich nicht für Stress sorgen, aber mir ist da etwas aufgefallen :P.

Nach Doku erhält man die Materialeigenschaft mit: Ich hab das nun einfach mal 1 zu 1 angewendet: Warum kommt das?: IDE ist VC++ 2010. Es handelt sich um den aktuellsten trunk.

Sollte nun gefixt sein. Eigentliche Ursache war eine fehlende Templatespezialisierung für aiColor3D.
Danke für den Bugreport :-)

Gern geschehen. Da ich mich gerade in die Bibliothek einarbeite werden mir bestimmt noch weitere Fehler auffallen, die ich dann einfach mal melden werde. Btw konnte ich mir mal das Materialsystem ansehen. Alles erstmal afaik ganz nett, außer diese Texturliste für verschiedene Dinge ;).

Da ich mich gerade in die Bibliothek einarbeite werden mir bestimmt noch weitere Fehler auffallen

Unmöglich! Unsere Schilde sind undurchdringlich!

Btw konnte ich mir mal das Materialsystem ansehen. Alles erstmal afaik ganz nett, außer diese Texturliste für verschiedene Dinge

Ja, vielleicht wäre eine wweitere Hierarchieebene in der Datenstruktur für Material-Texturen sinnvoll gewesen. Lässt sich nun aber nicht mehr ändern - aiMaterial::GetTexture() macht das ganze zudem völlig unsichtbar für den Anwender. Die langen Konstantenlisten existieren teils nur aus Kompatibilitätsgründen zur ersten Assimp-Beta - mit der ersten Major-Version nach diesem Release fliegen sie vermutlich raus :-)

Achja, mehrere Funktionsparameter von einem Mako übergeben zu lassen ist zugegebenermaßen auch nicht die feine Englische. Auch das war nötig um Rückwärtskompatibilität zu wahren, leider.

Ist auch akzeptiert, dann eben nicht. Aber zu den Fehlern... also Gesetzeslücken findet man ja wohl immer :lol: !

Mal ein Vorschlag, was man noch einbauen könnte:
Ein PostPro Flag, welches nicht genutze Bones bei Animationen entfernt.
Hauptsächlich fände ich das gut, um in de Lage zu sein, mehrere Animationen auf einem Objekt zu haben. Z.B. eine beliebige Lauf Animation für die Beine + eine Armanimation (damit man zum angreifen weder stehen bleiben muss, noch eine extra Laufangriff-Animation benötigt).
Ich meine, einige Exporter mögen das wohl direkt ordentlich liefern, aber eine ganze Menge bestimmt nicht. Daher fänd ich das als PostPro Schritt überaus sinnvoll.

Du meinst ein Step, der Bones, die von keiner Animation referenziert werden, entfernt?

Hauptsächlich fände ich das gut, um in de Lage zu sein, mehrere Animationen auf einem Objekt zu haben

Aber das ist doch möglich!? Die aiScene nimmt beliebig viele Animationen auf. Wenn eine Animation bestimmte Bones nicht braucht, so ist für diese meist auch kein (Dummy-)Eintrag in der aiAnimation enthalten. Oder stört dich genau dieses 'meist'?

Ja, das "meist" ströt mich. Also wie schon erwähnt, ich habe meinetwegen eine Lauf- und eine Hauanimation. Jetzt will ich ein System programmieren, welches mehrere Animationen gleichzeitig abspielen kann und zwischen diesen interpoliert. Nur, wenn bei der Schlaganimation nur Arme bewegt werden, aber trotzdem die ganzen Keys für die Beine mit drin sind, würde ja Laufanimation ja nur mit halber Gewichtung abgespielt werden, die Beine würden sich also z.B. nur halb so weit wie eigentlich bewegen.
Oft hat man diese Anforderung ja nicht unbedingt, weil ein Modell z.B. nur eine Animation zur gleichen Zeit hat. Ich habe jetzt noch nicht so enorm viele Exporter getestet, aber bei Cal3D war es z.B. so, dass wenn man zum animieren IKs benutzt hat, der Exporter die Animation "baken" (mir fällt gerade echt kein passendes, deutsches Wort ein) musste, und man somit zu jedem Zeitpunkt für jeden Knochen einen Key hatte, wodurch das über- und zusammenmischen von Animationen sehr komische Ergebnisse lieferte.

Ich weiß nicht, wie viele Exporter das betrifft, aber ich meine, dass auch in Ogre Dateien für Knochen die eigentlich überhaupt nicht bewegt wurden zumindest eine handvoll Keys vorhanden waren.

Grade entdeckt:

assimp-doku hat geschrieben: By default, all 3D data is provided in a right-handed coordinate system such as OpenGL uses. In this coordinate system, +X points to the right, +Y points away from the viewer into the screen and +Z points upwards. Several modeling packages such as 3D Studio Max use this coordinate system as well. By contrast, some other environments use left-handed coordinate systems, a prominent example being DirectX. If you need the imported data to be in a left-handed coordinate system, supply the aiProcess_MakeLeftHanded flag to the ReadFile() function call.

Ich dachte, es sei das 'andere RH' (X-Up, Y-Right, Z-Back)? Stimmt da die Doku nicht, oder hat sich das geändert?

Da ist die Doku veraltet. Wir haben das ja mal umgebaut, so dass das Standard-Koordinatensystem mehr dem entspricht, das die meisten zu erwarten scheinen. Das heißt: +X nach rechts, +Y nach oben, +Z zeigt aus dem Schirm heraus.

Gut, ich hab das dann mal in der Dokumentation korrigiert und werd' bei nächster Gelegenheit auch mal die Doku auf dem Server aktualisieren. Außerdem hab ich einen Herrn an der Angel der unseren Collada-Loader ausgiebig mit C4D plagt - ein Problem hat er schon gefunden, das dürfte jetzt aber gefixt sein.

Ich habe die D-Bindings wieder einmal auf den aktuellen Stand gebracht. Gibt es eigentlich schon Neuigkeiten von der »aiGetMaterialProperty«-Front?

Ich bin gerade am Linuxbuild per CMake drann. Hoffe, bald etwas liefern zu können.

Gruß Kimmi

Hoi,

hauptsächlich interessant für die C# und Java-Bindings (beide, soweit mir bekannt, unfertig).

SWIG- Simplified Wrapper und Interface Generator.

Zuerst hatte ich enorme Zweifel, ob es hält, was es verspricht. Nachdem ich heute damit erfolgreich funktionstüchtige Python-Wrapper für mein komplettes Engine-API generieren konnte, zweifle ich nicht mehr sondern glaube nur noch. Beeindruckendes Tool ... erstellt selbst für verhältnismäßig komplexe C++-Konstruktionen (Smart-Pointer, Templates) passende Bindings. Mit den Assimp-Headern wären vermutlich nicht die geringsten Probleme zu erwarten. Getestet habe ich bislang aber, wie bereits erwähnt, nur das Python-Backend.

@klickverbot
Sorry, das ist irgendwie untergegangen .. :-)
Danke für deinen stetigen Einsatz die Bindings aktuell zu halten!

Gibt es eigentlich schon Neuigkeiten von der »aiGetMaterialProperty«-Front?

Leider nein .. es ist und bleibt ein Rätsel.

Aramis hat geschrieben: Danke für deinen stetigen Einsatz die Bindings aktuell zu halten!

Leider nein .. es ist und bleibt ein Rätsel.

Naja, den »stetigen Einsatz« muss ich eigentlich nur leisten, weil ich bis jetzt zu faul war, einen Generator zu schreiben, der mir diese Aufgabe abnimmt. Ich werde mir einmal SWIG anschauen, vielleicht bekomme ich diesbezüglich etwas auf die Reihe. Dann würde es ja möglicherweise auch OOP-Bindings für D geben. ;)

Dass sich das aiGetMaterialProperty-Problem noch nicht aufgeklärt hat, verwundert mich mittlerweile ziemlich. Sollte es bis zum Release ungelöst bleiben, müsste ich noch entsprechende Hinweise in der Dokumentation hinzufügen. Aber noch besteht ja Hoffnung … :)

Der Linuxbuild mit CMake geht übrigens. Ich habe noch einige kleinere Probleme mit dem Unittests und dem gcc, die kriege ich aber auch in den Griff.

Gruß Kimmi

-SConstruct aktualisiert, ConvertUTF.c fehlte.
Außerdem hab ich zwei weitere SCons-Parameter eingebaut: 'shared' und 'noboost'. Kimmi, ich glaube du nutzt doch auch SCons ... könntest du das bitte auch mal bei dir testen?

Ich benutze mittlerweile zwar mehr CMake, aber klar, ich teste das gern.

Gruß Kimmi

Vielleicht sollten wir die Installerfrage lieber hier auf Deutsch ausdiskutieren. Nochmal meine Meinung dazu: ein MSI-Installer für's SDK und AssimpView-Binärpackage wäre meiner Meinung nach eine nützliche Sache ...

Was der Threadposter aber, wenn ich es richtig im Kopf hab, meinte war das 'install'-Target für Unixoide ... sollten wir auch für den MAKE-Build wohl mal einführen.
PS: http://wasaproject.net16.net/?p=175#more-175 - zufällig gefunden, nette Sache.

Unter dem normalen Make bäuchten wir dann ein Install-Target, daß nach /usr/lib ( oder etwas ähnliches ) die Lib und unter usr/include/ die Include hinterlegt. Für Windows würde ich unter Programme etwas ähnliches als Default hinterlegen. Ich muss mal schauen, was cmake da alles kann. Wenn die auch Workspaces für MSI'a ausspucken: toll. Ansonsten fällt mir für Windows noch WXI ein.

Gruß Kimmi

Kann es sein, dass die OBJ-Spinne seit den letzten Patches anders aussieht? Die Textur an den Beinen wirkt merkwürdig verzerrt und ist außerdem gelb.

Hm, das kann muß ich mal checken.

Gruß Kimmi

In der Tat ist da ein Problem eingeführt worden. ICh habe dementsprechend folgende Punkte gerade offen:

• 1. Installationstarget: Im GNU-Makefile und im CMake
  2. Obj-Loader: Ergebnisse zwischen Validate und real existierendem Modell unterschiedlich.
  3. Obj-Loader: Parsing-Problem auf Mac
  4. Obj-Loader: Scheinbar falsches Material

Ich denke, daß Punkt 2 und 3 am selben problem hängen.
Wenn der Schnee mich mal früher nach Hause kommen lässt, lege ich da los.

Gruß Kimmi

Von meiner Seite offen ist:

- Collada - MotionCaptureROM.dae sieht animiert seltsam aus. Das ging früher mal... was ist da passiert?

und eigentlich auch noch:

- Milkshape3D-Support
- FBX-Support

Die letzteren beiden wird's aber wohl nicht geben. Dazu hab ich einfach so schon zu viel um die Ohren. Nur leider wären das zwei recht wichtige Formate... FBX sogar sehr wichtig, wenn man die sonstige Tool-Unterstützung dafür betrachtet. Grmpf.

Bye, Thomas