Assimp - Brainstorming zum Release

[Aramis]

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.

[Jonathan]

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?

[Jonathan]

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

[kimmi]

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

[Schrompf]

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?

[kimmi]

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

[Schrompf]

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.

[kimmi]

So, Issue is solved

Kimmi

[Jonathan]

Ich komme in eine Endlosschleife bei FileSystemFilter::BuildPath:

Code: Ansicht erweitern :: Alles auswählen


if (std::string::npos != pos) {
std::string tmp;
std::string::size_type last_dirsep = std::string::npos;

while(true) {
tmp = base;
tmp += sep;

std::string::size_type dirsep = in.rfind('/', last_dirsep);
if (std::string::npos == dirsep) {
dirsep = in.rfind('\\', last_dirsep);
}

if (std::string::npos == dirsep) {
// we did try this already.
break;
}

last_dirsep = dirsep;

tmp += in.substr(dirsep+1, in.length()-pos);
if (wrapped->Exists(tmp)) {
in = tmp;
return;
}
}
}


Verursacht wird der Aufruf durch:

Code: Ansicht erweitern :: Alles auswählen


IOStream* MatFilePtr=m_CurrentIOHandler->Open(MaterialFileName);


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.

[kimmi]

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

[Aramis]

Ich fixe das.

[Jonathan]

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?

[kimmi]

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

Gruß Kimmi

[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

[Jonathan]

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.