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

[kimmi]

Stimmt, nun habe ich die probleme verstanden. Ich bin drann!

Gruß Kimmi

[Jonathan]

Ich fixe das.

Schon eine Idee, wie man das schön lösen könnte? Nachdem ich dort nochmal in eine Endlosschleife geraten bin, habe ich den rfind-Hack mit -1 wieder eingebaut, aber besonders toll fühle ich mich dabei nicht.

[Jonathan]

Noch ein paar Infos: mit dem rfing-1 hack gibt es zwar keine Endlosschleife mehr, aber dafür bekomme ich eine Exception "Error, T5400: invalid string position". Mein Code sieht folgendermaßen aus:

Code: Alles auswählen

	IOStream* MatFilePtr=m_CurrentIOHandler->Open(MaterialFileName);
	if(NULL==MatFilePtr)
	{
		//try the default mat Library
		if(NULL==MatFilePtr)
		{
			
			MatFilePtr=m_CurrentIOHandler->Open(m_MaterialLibFilename);

(Die Verwendung vom Rückgabewert ist doch so richtig, oder? Also, wenn die Datei nicht gefunden werden konnte, sollte keine Exeption kommen, sondern 0 zurückgegeben werden und mein Code weiterlaufen?)

Dabei ist der Dateiname "C:\Visual Studio 2010\Projects\Apocalyptical Age\OgreTest\Cube.material"

[Aramis]

Schon eine Idee, wie man das schön lösen könnte?

Eher diesen Thread vergessen - mea culpa.

Dafuer hab ich es eben reproduzieren koennen (mit vc 2008).

[Aramis]

Das hier muesste es fixen. (jedenfalls kriege ich damit keine Endlosschleife mehr)

Index: D:/dev/assimp3.svnc/trunk/code/FileSystemFilter.h
===================================================================
--- D:/dev/assimp3.svnc/trunk/code/FileSystemFilter.h (revision 1195)
+++ D:/dev/assimp3.svnc/trunk/code/FileSystemFilter.h (working copy)
@@ -213,12 +213,12 @@
dirsep = in.rfind('\\', last_dirsep);
}

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

- last_dirsep = dirsep;
+ last_dirsep = dirsep-1;

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

Im Uebrigen denke ich dass die von dir verlinkte Cpp-Referenz fehlerhaft ist, der Startindex gehoert zur Range dazu.

Edit: Ist mal so eingecheckt.

[Jonathan]

Danke, jetzt geht es :)

Stimmt, nun habe ich die probleme verstanden. Ich bin drann!

Schon Fortschritte?

[kimmi]

Leider bisher nicht. Ich habe mich durch die Änderungen seit dem letzten Relase durchgewühlt und konnte noch nicht feststellen, was falsch läuft.

Gruß Kimmi

[kimmi]

Hi,

irgendwie komme ich dem Fehler nicht auf die Spur, was auch dem Umstand geschuldet ist, dass hier sowohl meine Freundin als auch unsere Tochter mit Erkältungen rum-flaggen. ich habe in den Obj-Änderungen im wesentlichen nur die Line- und Point-Änderungen gesehen. Hat sich da vielleicht irgend etwas an der Post-Processing-Steps geändert? Für mich sieht das ein wenig nach degenerierten Dreiecken oder so etwas aus. Bin über jeden Denkanstoß dankbar!

Gruß Kimmi

[Aramis]

Ich waere dankbar wenn einer von euch die beiden Patches einspielen koennte (ich hocke gerade leider an einer Windows-only Box und das hiesige patch kommt mit den diffs nicht klar):

http://sourceforge.net/tracker/?func=de ... id=1067634

Die Patches sind i.O.

[klickverbot]

Done.

[Aramis]

Danke!

[Jonathan]

Hat sich da vielleicht irgend etwas an der Post-Processing-Steps geändert? Für mich sieht das ein wenig nach degenerierten Dreiecken oder so etwas aus. Bin über jeden Denkanstoß dankbar!

Gut, dann kommt hier einer: Ich bin mir ziemlich sicher, es liegt am PostPro. Ich habe eine Kugel in Blender, wenn ich die Blend-Datei lade, fehlen Dreiecke. Wenn ich die exportiere (in Obj oder Collada) fehlen auch die Dreiecke, außerdem flimmer irgendwelche Dreiecke beim drehen komisch (Assimp-Viewer). Wenn ich die Kugel nach 3ds exportieren, sind die Dreiecke da und es flimmert nichts.
Nun, 3ds trianguliert vielleicht alles, also habe ich die Kugel in Blender trianguliert und siehe da, die Datei lädt richtig. Collada und Obj Import klappt jetzt auch, allerdings flimmert hier immer noch irgendwas. Ich hab mal alle Modelle hochgeladen, *Tris sind jeweils die triangulierten.

Spheres.zip

Kugel in verschiedenen Formaten

(322.5 KiB) 470-mal heruntergeladen

[edit]Mein Grafiker hat mir gerade bestätigt, dass der Zombie auch funktioniert, wenn er vor dem Export trianguliert wird.[/edit]

[Aramis]

Das Flimmern wird vom Viewer verursacht, das ist harmlos.

Vermutlich haengt es mit einer nicht sonderlich alten Aenderung am Triangulator zusammen - der laesst neuerdings auch auf Quads den Ear-Cutting-Algo los nachdem mich freundlicherweise jemand darauf hinwies dass auch Vierecke konkav sein koennen.

[Jonathan]

Das Flimmern wird vom Viewer verursacht, das ist harmlos.

Rein aus Interesse: Woher kommt das? Oder ist das einfach so ein kleiner Bug, bei dem niemand die Ursache kennt, aber er interessiert eigentlich auch nicht weiter?

[Aramis]

Genau das :-) AssimpView sortiert transparente Polys schoen fein saeuberlich, aber irgendwas laeuft dabei hin und wieder mal schief. Ich hab die betreffende Stelle im Quellcode sicher schon 10 Mal durchgeguckt, aber mich dabei immer nur aufs neue drueber geaergert dass eigentlich der ganze Viewer ein sauberes, plattformunabhaengiges Rewrite von Scratch braeuchte :-)