ZFX + Developia

Aaaaalso
Ich habe endlich nochmal an meinem Spiel weitergemacht. Und dabei das Buildsystem auf CMake umgestellt. Und natürlich im Zuge dessen versucht Assimp zu kompilieren. Es kamen wieder die selben Fehler, die ich früher hatte:
http://zfx.info/viewtopic.php?f=4&t=927&hilit=assimp
Dann hab ich ein bisschen gesucht, wie ich das wohl umgehen könnte, und das hier gefunden:
http://sourceforge.net/projects/assimp/ ... ic/4666308
Und das funktioniert für mich. Da andere scheinbar das selbe Problem mit VC 10 haben, sollte man das in irgendeiner Weise fixen. Keine Ahnung, ob die pstdint generell Probleme mit VC hat, oder assimp da irgendetwas komisch macht, aber ich schlage einfach mal folgende Änderung im CMakeSkript vor:

code/CMakeLists.txt ab ca. Zeile 730

OPTION( VC10_STDINT_FIX "Fix for VC10 Compiler regarding pstdint.h redefinition errors" OFF )
if( VC10_STDINT_FIX )
ADD_DEFINITIONS( -D_STDINT )
endif( VC10_STDINT_FIX )

ADD_DEFINITIONS( -DASSIMP_BUILD_DLL_EXPORT )

if ( MSVC80 OR MSVC90 OR MSVC10 )
ADD_DEFINITIONS( -D_SCL_SECURE_NO_WARNINGS )
ADD_DEFINITIONS( -D_CRT_SECURE_NO_WARNINGS )
endif ( MSVC80 OR MSVC90 OR MSVC10 )

Interessant ist nur der erste BLock, den Rest hab ich nur gepostet, damit ihr wisst, wo ich es eingeordnet habe (bei den defines, ist ja auch nur ein bedingtes define). Die Lösung hat zumindest für mich funktioniert und hat den Vorteil, dass man die Projektdateien nach dem generieren nicht mehr ändern muss. Was das eventuelle neugenerieren nach Änderungen vereinfacht. Und auch wenn ein solcher Hack eventuell etwas unsauber ist, ist es dneke ich dennoch besser, als gar keine Lösung. Vielleicht muss man es bei VC10 ja auch einfach immer definieren, dann könnte man es in den untersten BLock packen und nicht mehr bedingt machen, aber solange man sich nciht sicher ist, was genau den Fehler verursacht, ist es mit der Option meiner Meinung nach besser.

Und wo wir gerade dabei sind: Wieso boost 1.35? Die hab ich nicht. Ich hab also die top-level CMakeLists.txt auch abgeändert:

ELSE ( ENABLE_BOOST_WORKAROUND )
SET( Boost_DETAILED_FAILURE_MSG ON )
SET( Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0" "1.48.0" "1.48" )
FIND_PACKAGE( Boost )

Versionen bis 1.46 sind in meiner Standard findboost.cmake schon drin.

Nach den zwei Anpassungen schnurrt der Build durch. Weiter bin ich noch nicht, aber ich denke, es wird auch so laufen.

Achja, wer betreut eigentlich das CMake Skript? Wie wäre es mit einem debug Postfix? Finde ich ansich immer ganz angenehm, damit man es in 2 Konfigurationen parallel kompilieren und installieren kann.

Ich betreue die CMake-Skripte, wenn ich mal wieder dazu komme. Debug-Postfix braucht man nur, wenn Debug- und Release-Binaries zusammen in einem Verzeichnis liegen, was bei uns zur zeit nicht der Fall ist. Das würde dann bedeuten, dass man hier grundlegend die Output-Verzeichnisse ändern müßte.
Boost 1.35, weil das damals die aktuelle Version war. Ich werde deine Version da mit rein-mergen.

Gruß Kimmi

Hm, also ich habe sonst nichts am CMake-Skript geändert. Und bei mir hat er im Debug und Release Mode immer nur eine assimp.dll erstellt. Die hieß auch immer einfach nur "assimp.dll" und nicht wie die fertig kompilierte "assimp32.dll".

Stimmt, die hat immer den gleichen Namen. Die liegen dann jeweils unter Gruß Kimmi

Hm, ja, aber wenn man INSTALL ausführt, liegen die beide in lib/assimp.dll, wodurch die ältere überschrieben wird.

Hm, das ist natürlich richtig. Entweder könnte man da ebenfalls 2 verschiedene Verzeichnisse anlegen oder halt den Namen ummünzen. Ich wäre für beides offen, jedoch bevorzuge ich zur Zeit den Vorschlag mit den Verzeichnis je Konfiguration, da das IMHO weniger Arbeit mit sich bringt.

Ich habe deine Fixes committet. Sorry, hat lang gedauert, ich hänge hier gerade mit einer Nebenhöhlenentzündung rum und komme zu nicht viel.

Gruß Kimmi

Ich glaube, ich fände unterschiedliche Namen besser. Erstens werden dadurch die Linkereinstellungen einfacher, weil man keine Pfade realtiv zu seinen Standardpfaden oder gar absolute Pfade angeben muss (wobei mir das egal ist, seit ich CMake nutze, aber für andere könnte das interessant sein). Zweitens wüsste ich gerade nicht, wie man dann jeweils die passende dll lädt. Klar könnte man die Debug und Release exe in 2 verschiedenen Ordnern haben und da jeweils die passende Assimp.dll zupacken, aber was ist, wenn man sie doch in einem Pfad haben möchte oder gar in irgendeinem Standardpfad?
Zu dem Aufwand: Was müsste denn konkret alles geändert werden? Mit 32/64bit hab ich noch nicht herumexperimentiert, aber für die Debug Version reicht doch ein einfaches SET_DEBUG_POSTFIX("d") oder nicht?

Stimmt, das Kommando kannte ich noch gar nicht *ankopfffass*

Gruß Kimmi

Ich war mal so frei, alle Tracker-Items hochzupriorisieren, die ich gerne fuer 3.0 gefixt sehen wuerde :roll:

Fuer die restlichen Aenderungen des heutigen Tages, siehe die ML.

Nur eine Kleinigkeit: Setzt mal bitte den Ogre XML Import auf der Featureliste auf limited. Irgendwo in der DOku steht zwar, was alles geht und was nicht, aber es dürfte nichts schaden, das auch in der Übersicht zu haben.

So ich hab nochmal die aktuellste Assimp Version aus dem SVN (rev 1170) und nicht den gepackten Download probiert.
Assimp_Viewer fand die d3dx.h nicht, wenn man die CMakeDatei entsprechend ändert, geht es aber: Mit dieser Einstellung kompilieren schonmal die meisten Projekte. assimp_simpletexturedogl findet allerdings die assimp.h und assimp.hpp nicht. Interessanterweise gibts die im ganzen Repo auch nicht, in dem SDK (2.0.864) allerdings schon. Gabs diesbezüglich irgendwelche Änderungen?

Headernamen sind neuerdings etwas einheitlicher :-) Siehe Mailingliste.
(http://comments.gmane.org/gmane.comp.li ... general/62)

Zu dem CMake-Fix muss Kimmi sich aeussern. Die Samples muessen noch angepasst werden, ich gucke dass ich so schnell wie moeglich dazukomme.

Ah, danke. Die neuen Namen Gefallen mir auch wesentlich besser :)
Für sowas wäre eigentlich eine News-Sektion auf der Homepage gut. Es will vielleicht nicht jeder Benutzer die Mailingliste abonieren und einen Überblick über solch größere Änderungen zu haben wäre bestimmt gut. Auch wenn in Zukunft z.B. weitere Formate dazu kommen oder so.

SO, jetzt scheint alles zu laufen. Ich kann alle Projekte ohne Fehler durchkompilieren (interessanterweise brauch ich diesen VC10 fix nicht mehr, keine Ahnung, was jetzt wieder anders ist...)

Ich habe in beiden Beispielen die Header angepasst, und in der model_loading.cpp zahlreiche (unnötige?) structs entfernt:

GLenum fill_mode;
int ret1, ret2;
struct aiColor4D diffuse;
struct aiColor4D specular;
struct aiColor4D ambient;
struct aiColor4D emission;
float shininess, strength;
int two_sided;
int wireframe;

DUrch die war aiColor4D immer undefiniert, ohne die 'struct's läuft es sauber durch. Warum standen die da? (und an vielen anderen Stellen in dieser Datei). Ansonsten hab ich wie gesagt die assimp_view CMakeList angepasst. Achja, ich glaube für assimp_viewer.exe fehlt das INSTALL-Target.

Wenn niemand was dagegen hat, probiere ich morgen aus, ob meine SVN Daten noch stimmen und lade die Änderungen hoch.

Danke fuers Korrigieren! Deine SVN-Daten sollten noch stimmen, also nur zu :-)

Newsmeldung ... ich denke, damit koennen wir doch noch bis zum Release warten? Damit wird die API-Aenderung dann ja offiziell. Aber ich werde einen deutlichen Vermerk auf der HP anbringen dass der aktuelle trunk nicht mehr zur hochgeladenen Doku passt.

AH, na klar, hatte ganz vergessen, dass der SVN Release ja eher unoffiziell ist. Dann wäre vielleicht ein kleiner Hinweis über den SVN-Link ok. Denn etwas groß anzukündigen, was nicht im offiziellen Release ist, macht ja irgendwie echt keinen Sinn.
Ich habe mal Probiert die Venetica-Modell mit dem Ogre-XML Konverter in Textdateien umzuwandeln und mit Assimp zu laden. Scheinbar ist das Format etwas flexibler als gedacht, statt allen Vertexdaten zusammen kann man wohl auch erst alle Positionen, dann alle Normalen usw. angeben. Aber das sollte eigentlich recht leicht einzubauen sein, bin gespannt, ob ich dann zumindest die statischen Dateien laden kann :)
Was war in etwa der Termin für den Release?

O, ich hab die Änderungen hochgeladen. Ich habe mir auch erlaubt, eine DEBUG_POSTFIX Cache Variable anzulegen, die auf alle Targets angewendet wird, denn ansonsten macht das installieren irgendwie wenig Sinn, wenn ständig die DLLs überschrieben werden. Jetzt hat man die schön nebeneinander in einem Verzeichnis :)

Die CMake-Anpassungen habe ich angesehen und ich finde die ok.
@Jonathan: Danke für die Hilfe! Wieder etwas weniger auf der ToDo :).

Gruß Kimmi

Ich habe gerade festgestellt, dass sich der M3Importer bei einem "drkwood2.jpg" angesprochen fühlt. In dem Loader passiert ein entsetzliches Pointer-Cast-Gebastel, das bei einem JPEG-Bild natürlich crasht. Kimmi, kannst Du da einen Check oder sowas an den Anfang setzen, damit der Loader ein ungültiges File erkennt und sauber beendet?

Klar, mache ich! Dieser Loader treibt mich eh noch in den Wahnsinn, das will nicht funzen. Aber ich bleib drann! Und danke für den Hinweis.

Gruß Kimmi

Danke! Ich hatte aus Versehen mein kleines Batch Converter Tool auf "*" losgejagt, da fiel mir das auf. Die .mtl-Dateien von OBJ hat der MTL-Loader sauber abgelehnt, für die .jpg-Dateien aber hat sich irgendwie der M3-Loader verantwortlich gefühlt... Irgendwann jag ich mal rekursiv über die gesamte Platte drüber. Nur so als Test. :-)

So, Issue is solved :)

Kimmi

Ich komme in eine Endlosschleife bei FileSystemFilter::BuildPath:
Verursacht wird der Aufruf durch: Die Datei die ich zu Laden versuche, existiert nicht. Soweit ich die Schleife richtig verstehe, soll er von dem untersten Pfad immer weiter nach oben finden, wofür die Position des letzten Pfadestrenners weiter gespeichert wird.
http://en.cppreference.com/w/cpp/string ... ring/rfind
Sagt mir, dass das Intervall [0, pos) durchsucht wird, d.h. pos darf nicht als Ergebnis zurückkommen, richtig? Nun, in meinem Fall (VC2010 Prof STL-Version) übergibt er bei der Suche nach \\ 21, und als Ergebnis kommt 21 zurück. Demnach wird daraus eine Endlosschleife. Wenn ich bei beiden rfind von der Position noch 1 abziehe, läuft es durch. Das könnte natürlich Probleme machen, weil Pfade übersprungen werden oder wenn das erste Zeichen ein / ist (Linux?) und dann durch einen Überlauf wieder bis npos gesucht wird und sich so eine Endlosschleife ergibt. Aber ich weiß nicht, wie ich das Problem bei mir sonst lösen sollte.

Bau dir doch einen Unittest und teste die umliegenden Randbedingungen. Da kriegst du eher ein Gefühl, was noch alles zu beachten ist. Besonders Schlechtfälle mit gemischten Dir-Separatoren sind gefährlich.
Und irgendwie fehlt mir bei deinem Coeschnipsel die Abbruch-Bedingung.

Gruß Kimmi

Ich fixe das.

Wer betreut den Obj-Importer? Hat sich da in letzter Zeit etwas dran geändert?

Ich habe festgestellt, dass die aus dem aktuellen SVN kompilierte Version seltsame Fehler hat, Dreiecke und Texturkoordinaten fehlen:

(um den Mund, die Nase und in den Augen sind schwarze Bereiche, dort fehlen Dreiecke) Hier ein Bild von einer älteren Version des Viewers, der eine alte Assimp Version benutzt: Im Assimp_Viewer treten die selben Probleme auf. Irgendeine Idee, was das verursacht haben könnte?

Huch? Ich überprüfe das am Wochenende. Ich meine, nur Kosmetik betrieben zu haben. Kannst du mir das Modell zukommen lassen, bitte?

Gruß Kimmi

So schaut das bei mir lokal aus: http://dl.dropbox.com/u/64072475/screen ... et_rev.png . Wie erwartet irgendwie. Hast du da den aktuellen Stand vorliegen?

Gruß Kimmi

Doch, es ist auch bei dir falsch. Ich zeige nochmal Großaufnahmen vom Kopf:

http://dl.dropbox.com/u/30364356/KopfFalsch.PNG
http://dl.dropbox.com/u/30364356/KopfOk.PNG

Interessant ist auch: Der Alte Viewer zeigt im ersten SubModel 1908 Dreiecke an, der neue (mit der aktuellen, kaputten Assimp Version) 1743. Dreiecke fehlen in der Nase und den Augen und die Zähne sind irgendwie komplett nicht da.