Assimp - Brainstorming zum Release

[Aramis]

Ich bin auch fuer -simple, habs auch auf der ML gepostet.

[kimmi]

So, ist geliefert. Der M3-Loader nimmt auch Gestalt an. Hoffentlich kann ich die nächsten ein bis zwei Wochen da was liefern.

Gruß Kimmi

[Aramis]

Gotcha. Precise hat Assimp. https://launchpad.net/ubuntu/+source/assimp (aus Debian-unstable ruebergeschwappt).

Ich freue mich auf den Tag, an dem <package manager of choice> install libassimp2-dev als Installationshinweis ausreicht :-)

[kimmi]

Auch wenn ich gerade nicht zu so viel komme: Wann wollen wir mal wieder etwas releasen? Zumindest einen Bugfix-Release rate ich langsam an, da mittlerweilse schon recht viele Fehler im aktuellen Developer-Snapshot gefixed wurden. Wir könnten die noch nicht stabilen Teile als experimental deklarieren.

Was sagt ihr?

Gruß Kimmi

[Aramis]

Zustimmung. Gab ne Menge Bugfixes. Naechste Woche haette ich Zeit, mich drum zu kuemmern falls ich wieder das Verpacken etc uebernehmen soll ... ich wuerde es aber wieder zweiteilen und vorerst einen RC rausbringen und dann erst zum Jahreswechsel/Dreikoenig das Release.

[kimmi]

Das klingt gut. Kannst du den Release-prozess eigentlich mal kurz umreißen. Dann kann man dir da etwas abnehmen.

Gruß Kimmi

[Aramis]

Oehm ... es hat in /packaging ein (nicht hauen) Batch-Skript um die ZIP-Releases zu erstellen. Nun kam ja die berechtigte Kritik dass es keinen Source-only-tarball gaebe, dafuer muss das noch ein bisschen angepasst werden.

Vorher muss man die Doku ein bisschen durchgehen und auf den neuesten Stand bringen, die Website etc … Fuers finale Release dann Ankuendigungen auf diversen Seiten (falls wir die noch noetig haben). Fuer den RC reicht aber die ML + eine Newsmeldung auf SF.net aus.

Unittests sollten durchlaufen werden (funktionieren aktuell) .. Regressionstests auch (laenger nicht mehr probiert, was die Idee dahinter minimal ad absurdum fuehrt …). Der Patchtracker sollte soweit wie moeglich abgearbeitet werden, gucken dass wir keine Patches uebersehen usw.

[Aramis]

Ich zitiere mich einfach mal selber von der ML und spare mir die Uebersetzung:

I just did some major rework in the C API, addressing some long-time issues.

I dropped the global importer map to map scenes to importers - the
importer instance pertaining to an imported scene is now stored in the
aiScene::mPrivate pimpl.

This makes the C API threadsafe even without boost (with an exception
for the logging facilities, which are still global).

I also reworked the property interface in the C API - importer settings
are no longer global.

New usage is as follows (taken from AssimpView)


aiPropertyStore* props = aiCreatePropertyStore();
aiSetImportPropertyInteger(props,AI_CONFIG_IMPORT_TER_MAKE_UVS,1);
aiSetImportPropertyFloat(props,AI_CONFIG_PP_GSN_MAX_SMOOTHING_ANGLE,angle);

...

const aiScene* sc = aiImportFileExWithProperties(...,props);

aiReleasePropertyStore(props);
aiReleaseImport(sc);



THIS IS A BREAKING API CHANGE for anyone using properties with the C
API. It is, however, a huge step forward and finally makes our C API
functionally equivalent to the C++ interface.

I hope we can adapt all ports as soon as possible. I'd be grateful if
the respective maintainers could do this.

Documentation is not yet up to date.

All this is in anticipation to the upcoming 3.0 release, which I'm
actively working on.

[Aramis]

Naechster Punkt: nachdem ich damit eben Tatsachen geschaffen habe, koennen wir auch gleich weitermachen und noch mehr Altlasten loswerden. Stoert sich jemand dran wenn wir alle Dateien in /include nach /include/assimp verschieben?

Damit macht es dann keinen Unterschied mehr ob man den Assimp-Trunk oder das Assimp-Paket verwendet.

[Aramis]

Oh und kimmi .. was ist eigentlich der Status des M3-Importers?

[kimmi]

Fundament fertig, ich muss das gute Stück noch zu Ende debuggen. Was ich wohl langsam mal anfangen sollte *auftochterspäh* ...

Gruß KImmi

[Aramis]

Schaffst du das in absehbarer Zeit .. oder sollen wir den lieber fuers naechste Release ausklammern?

Toll waeren auch noch Testmodelle dafuer.

Hoffe, ich stresse dich nicht, aber ich versuche grade, die verbleibenden Baustellen zu identifizieren und zu eliminieren :roll:

[Jonathan]

Für wann ist der Release denn geplant? Ich wollte auch imemr nochmal Animationen in mein Spiel einbauen und in diesem Zuge vielleicht den OgreImporter überarbeiten. Ich glaube, da sind so einige Baustellen noch offen.

[Aramis]

Geplant war der RC fuer .. uh, ich glaube, ich hatte was von 24-31.12 11 getoent. In der Woche war ich aber leider ziemlich eingespannt.

Nun habe ich mich entschlossen, noch einige lange faellige Aenderungen durchzuziehen um endlich ruhig schlafen zu koennen … das verzoegert alles, und ich wuerde nicht damit rechnen, dass wir in den naechsten 4 Wochen releasen koennen. Gleichzeitig waere ich aber froh, wenn wir es noch im Februar schaffen wuerden, notfalls anfang Maerz.

Funktionierende Animationen im Ogre-Importer waeren tatsaechlich eine nette Sache, wenn du Zeit dafuer faendest :-)

[kimmi]

Schaffst du das in absehbarer Zeit .. oder sollen wir den lieber fuers naechste Release ausklammern?

Toll waeren auch noch Testmodelle dafuer.

Hoffe, ich stresse dich nicht, aber ich versuche grade, die verbleibenden Baustellen zu identifizieren und zu eliminieren :roll:

Ich hoffe doch. Und nein, das ist kein Stress :). Stressig sind hier eher gerade andere dinge *zurunsinntreibendentochterschiel* ...

Gruß Kimmi

[Jonathan]

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.

[Jonathan]

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.

[kimmi]

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

[Jonathan]

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".

[kimmi]

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

Code: Alles auswählen

debug\assimp.dll
release\assimp.dll

Gruß Kimmi

[Jonathan]

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

[kimmi]

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

[Jonathan]

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?

[kimmi]

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

Gruß Kimmi

[Aramis]

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.

[Jonathan]

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.

[Jonathan]

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:

Code: Alles auswählen

# Make sure the compiler can find include files from our Hello library.
include_directories (
	${Assimp_SOURCE_DIR}/include
	${Assimp_SOURCE_DIR}/code
	${DX9_INCLUDE_PATH} //DX9 Pfad hinzufügen
)

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?

[Aramis]

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.

[Jonathan]

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.

[Jonathan]

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.