Assimp - Brainstorming zum Release

[Chromanoid]

mmh das ist seltsam. also ich hatte an dieser stelle probleme:

Code: Alles auswählen

unsigned int texCoordChannel;
material->GetTexture(aiTextureType_DIFFUSE,0,texturePath,&textureMapping,&texCoordChannel,NULL,NULL,NULL);

In dieser Variable steht soweit ich mich erinnere immer der Index der auch beim input_set Attribut steht. Es werden zwar alle Kanäle geladen, aber leere Kanäle werden nicht in den Array gepackt, so dass man wenn man sowas macht:

Code: Alles auswählen

GLfloat *texCoords=&base->mTextureCoords[texCoordChannel][0].x;

auf die Nase fällt, wenn zum Beispiel die erste "reale" Kanalnummer 1 ist und Kanal 0 nicht belegt ist.

Ich kann mich auch irren aber ich glaube das ganze liegt an diesen Zeilen in ColladaLoader.cpp:537
Das kommentar lässt auch darauf schließen.

Code: Alles auswählen

// same for texturecoords, as many as we have
// empty slots are not allowed, need to pack and adjust UV indexes accordingly
for( size_t a = 0, real = 0; a < AI_MAX_NUMBER_OF_TEXTURECOORDS; a++)
{
	if( pSrcMesh->mTexCoords[a].size() >= pStartVertex + numVertices)
	{
		dstMesh->mTextureCoords[real] = new aiVector3D[numVertices];
		for( size_t b = 0; b < numVertices; ++b)
			dstMesh->mTextureCoords[real][b] = pSrcMesh->mTexCoords[a][pStartVertex+b];		
		dstMesh->mNumUVComponents[real] = pSrcMesh->mNumUVComponents[a];
		++real;
	}
}

[Schrompf]

Hm... guter Einwand. Ich weiß es ehrlich gesagt nicht genau. Der Collada-Loader hat mit seinen ganzen Mappings von WertX auf WertY über WertZ, aber nur wenn WertV gesetzt ist, und manche Exporter schreiben es stattdessen in WertU rein... jedenfalls schon lange die Grenze der Beherrschbarkeit hinter sich gelassen. Deine konkrete Datei hatte ja drei Sets Texturkoordinaten:

Code: Alles auswählen

          <input semantic="VERTEX" source="#Box01-mesh-vertices" offset="0"/>
          <input semantic="NORMAL" source="#Box01-mesh-normals" offset="1"/>
          <input semantic="TEXCOORD" source="#Box01-mesh-map-channel1" offset="2" set="0"/>
          <input semantic="TEXCOORD" source="#Box01-mesh-map-channel3" offset="3" set="3"/>
          <input semantic="TEXCOORD" source="#Box01-mesh-map-channel4" offset="4" set="4"/>

In den Nodes, wo die Meshes instanziiert werden, wird pro Texturkoord-Set eine Semantik festgelegt, also eigentlich nur eine ID.

Code: Alles auswählen

              <instance_material symbol="_2_-_Default" target="#_2_-_Default">
                <bind_vertex_input semantic="CHANNEL3" input_semantic="TEXCOORD" input_set="3"/>
              </instance_material>
              <instance_material symbol="_1_-_Default" target="#_1_-_Default">
                <bind_vertex_input semantic="CHANNEL4" input_semantic="TEXCOORD" input_set="4"/>
              </instance_material>

jetzt wissen wir, dass nur das zweite und dritte Set Texkoords überhaupt benutzt wird, namentlich also die "3" und "4". Die beiden werden auf die Begriffe "CHANNEL3" und "CHANNEL4" gemappt. Und diese Begriffe tauchen dann in der Material -> Effect -> Blinn -> Diffuse -Parameterdefinition wieder auf, die gleichzeitig auf einen Sampler verweist, der als Parameter in der Effektsammlung liegt, der auf ein Image in der ImageLibrary verweist, dass dann den Dateinamen der Textur enthält.

Soweit alles klar? Wundert sich noch jemand, warum ich Collada hasse? Nunja, nach dieser Logik müsstest Du, wenn alles korrekt läuft, zwei aiMeshes mit jeweils Position, Normale und 3x Texkoords bekommen. Und wenn Du zu Material 1 AI_MATKEY_UVWSRC( aiTextureType_DIFFUSE, 0) abfragst, müsstest Du eine 1 bekommen, für Material 2 müsstest Du eine 2 bekommen. Ich befürchte aber nach meiner aktuellen Darlegung eher, dass Du für Mat1 eine 3 und für Mat2 eine 4 bekommst, weil die Material Properties das Zusammenrücken der Kanäle nicht mitmachen.

Nimmst Du's mir übel, wenn ich den Bug einfach liegen lasse?

[Chromanoid]

Nimmst Du's mir übel, wenn ich den Bug einfach liegen lasse?

Nein :D ich kann das gut verstehen.
Wenn man sich einfach merkt, dass keine leeren Channels auftreten dürfen und die Set-Nummern bei 0 beginnen müssen, ist das ganze ja auch gut beherrschbar. Übrigens benutzt 3DSmax soweit ich weiß beim Collada Export immer die Channelnummern, die auch tatsächlich vergeben wurden (Channel kann vom Benutzer frei gewählt werden und ist für Texturkanäle standardmäßig 1). Würde man also mit material->GetTexture bei diesen Modellen, die Kanalnummer ermitteln um diese dann als Index für mTextureCoords zu benutzen, läuft das ganze immer schief (man versucht in einem Array in dem es nur ein Element gibt auf das zweite zuzugreifen). Ich vermute übrigens, dass das ganze auch bei den Vertexfarbkanälen in diesem Sinne schief läuft.
Ich habe eben nochmal geschaut und ich glaube die Informationen über die Zuordnung werden schon früher verloren (nicht erst in der Funktion in der ich den Fehler vermutet habe). Von daher wäre das einbauen wahrscheinlich ziemlich nervig und man müsste an den Parser ran... Von daher würde ich das erst fixen wenn sich genug für den collada loader angesammelt hat und es wirklich jemanden gibt, den das akut stört :D.

[Aramis]

Uff. Ok, es wird. Ich hab fast alles up-to-date, getestet, usw … Pakete lade ich aber wohl erst heute Abend hoch.

Hat jemand grade zufaellig Zeit Lust sich den Text fuer die Release-Ankuendigung zu ueberlegen? Die relevanten Aenderungen seit dem letzten Release sind in der CHANGES zu finden.

[klickverbot]

Wenn die Vertex-Anim-Datenstrukturen doch drin bleiben, muss ich mir dringend noch mal die D-Bindings vornehmen, dadurch ändert sich ja das struct-layout…

[Aramis]

So. Done! Assimp 2.0 ist released. Pakete sind hochgeladen und verlinkt.
Jetzt muessen wir nur noch den ganzen Spass ankuendigen ;-)

[kimmi]

Super, vielen Dank für deinen tollen Einsatz!

Gruß Kimmi

[Aramis]

Es sieht so aus als sei in der zuletzt releasten Version ein Fehler im finalen Paket drin, genauer die .lib's fuer die Debug-Konfiguration fehlen, stattdessen liegen im Verzeichnis dann die Release-Versionen, die natuerlich gegen die Release-DLL linken.

Das ist bedauerlich, aber nun nicht mehr zu aendern. Ich wollte nur dass ihr bescheid wisst falls mal entsprechende Hilferufe kommen sollten.

Danke an Jonathan fuer den Hinweis :-)

[klickverbot]

Naja, was spricht gegen einen aktualisierten 2.0-r2 (oder wie auch immer) genannten Download, zusammen mit einem Hinweis in der Download-Sektion?

[Aramis]

Dass man ihn machen muss. Jedes mal wenn ich auf SF.net Dateien hochladen will, brauche ich dafuer ’ne Stunde … einmal mit Chrome, halbe Stunde warten, dann nochmal mit IE weil’s mit Chrome nicht klappt. Waehrenddessen noch ein paar Links korrigieren. Noch Fragen? :-)

(mal gucken, eventuell schaffe ich es morgen die Motivation dafuer zu finden …).

[klickverbot]

Okay, diesem Argument ist natürlich kaum etwas entgegenzusetzen… ;)

[Schrompf]

Falls jemand Interesse hat: ich habe gerade einen ersten Vorschlag für die Assimp-Export-API eingecheckt. Entspricht in dieser Form grob dem, was Aramis und ich im Skype beschwatzt hatten, aber ich bin mir nicht mehr ganz sicher... bin an jeder Art von Kommentar oder Kritik interessiert.

[kimmi]

Die Idee dahinter ist, dass man die ganzen Daten in ein spezielles Format exportieren kann, damit Transformationen von obj nach Collada möglich sind, korrekt? Dementsprechend müsste jeder Loader eine Export-Funktion unterstützen, die dann per aiGetExportFormatDescription als unterstützt zurück gegeben wird und dann per id in aiExportScene den Prozess startet, richtig? Wenn ich das alles richtig verstanden habe, würde ich sagen: die API ist selbsterklärend :).

Gruß Kimmi

[Aramis]

Ja, nur dass Importer und Exporter komplett getrennt sind. Wir brauchen auch unbedingt ein #define um alle Exporter auf einen Schlag nicht mitzubauen.

Sieht soweit uebrigens gut aus. Schlage vor, wir machen dazu noch eine export.hpp, die im Prinzip bloss den Destruktormechanismus zum Loeschen der Daten ausnutzt. Die eigentliche Implementierung kann dann auf Basis des C-Apis erfolgen – damit entfaellt das Ownership–Problem des Importer-Interfaces.

[Aramis]

Hm … MD5 koennte man damit beispielsweise nicht exportieren - es besteht aus mehreren Dateien.

Die einzige Loesung die mir einfaellt, waere dass wir dem ExportBlob einen Satz benannter SubBlobs geben. Das koennen wir dann ja bei Bedarf machen - fuer Collada, Obj, 3DS etc. tritt das Problem ja nicht auf, zudem wollen wir uns ja gerade afu die gaengigen Formate beschraenken (Ob MD5 da dazu gehoert … schwer zu beurteilen, jedenfalls ist es nicht das allerunwichtigste).

[Aramis]

Ok – ich hab mal zu Thomas’ Vorschlag noch folgendes hinzugefuegt:

• Ein Vorschlag, wie das zugehoerige C++–Wraepperchen aussehen koennte
• 1,2 Bequemlichkeitsfunktionen (insbesondere auch mit dem oben gaeusserten Problem mehrerer Ausgabedateien im Hinterkopf)
• Einen Ansatz zur internen Implementierung (*1, sicherheitshalber per #ifdef deaktiviert). Thomas, ich hoffe, du wirst mir zustimmen, dass es sich dabei um eine ziemlich pragmatische und wenig aufgeblasene Variante handelt :-)

… ansonsten noch ein paar Mini–Fixes an der export.h. Meinungen zu allem zusammen?

Gruss, Alex

[1] http://assimp.svn.sourceforge.net/viewv ... iew=markup

[kimmi]

Der Blob beinhaltet die jeweiligen Daten der Dateien? Oder beinhaltet der Blob die Assimp-Daten ( also so etwas wie ein Container ) als Ganzes? Man könnte die Blob's einfach als Linked-List darstellen. Mir ist gerade nicht ganz klar, was da hinein kommt und mein Schlafmangel tut da übrige. Vielleicht erklärt ihr euch kurz. Selbstredend könnte ich die Doku erneut lesen, aber das Lesen hier ist einfacher und man hat mehr Meinungen an der Stange, hier lesen mehr mit :).

Gruß Kimmi

[Aramis]

Sorry wenn das nicht so eindeutig war.

Der Blob enthaelt die exportierten Daten. Man koennte ihn also 1 zu 1 auf die Platte schreiben, in einem Archiv archivieren, via FTP hochladen, wegwerfen usw. :-) Einfach um uns nicht an das Dateisystem zu binden.

Gruss, Alex

[Schrompf]

Genau das ist der Zweck. Der Blob enthält den Binärinhalt einer exportierten Datei. Bei Collada also z.B. ein paar Megabyte XML-Kram, bei 3ds ein Haufen Binärdaten, sowas halt. Wenn man einfach eine Datei aufmacht und den Blob da reinschreibt, bekommt man eine fertig exportierte Datei. Eine Bindung an Loader ist da nicht nötig, der Export arbeitet ja nur auf Basis einer aiScene. Und wo die herkommt, ist egal. Für die Splitterwelten brauche ich z.B. eine Exportfähigkeit und werde dafür auf Anwendungsseite eine aiScene aus den bestehenden Daten erstellen müssen. Aber es ist möglich. Und darauf kommt's an :-)

Das Problem mehrerer Exportdaten ist mir auch aufgefallen, aber ich hatte mich entschieden, das Thema erstmal ruhen zu lassen. Wenn Du das jetzt behandelt hast... sehr gut :-) Hatte .obj nicht auch ein separares Materialfile?

[Schrompf]

Ich habe noch eine Weile über das MehrDatei-Problem nachgedacht. Mein Gedanke war, dass wenn ein Exporter mehr als eine Datei ausspucken sollte, man als Anwender ja nicht weiß, welche Datei wo drin steckt. Ich würde also vorschlagen, wir entfernen den RecommendedFileExtension-Eintrag wieder aus der ExporterDesc und fügen ihn stattdessen zum Datenblob hinzu. Zur Verbindung würde ich Kimmis LinkedList-Vorschlag aufgreifen, um eine zusätzliche Indirektion durch ein Array mit Größenangabe zu vermeiden.

Ein OBJ-Export könnte dann z.B. folgende Strukturen ausspucken:

Code: Alles auswählen

DatenBlob1
{
  size: xyz
  data: abcde
  file: ".obj"
  nextBlob: zeiger auf DatenBlob2
};

DatenBlob2
{
  size: xzy
  data: qwertzy
  file: ".mtl"
  nextBlob: NULL
};

Ist das akzeptabel?

Teil zwei meiner Änderungsüberlegungen betreffen nur noch die Implementation des Arrays verfügbarer Exporter. Ich würde nämlich gern eine doppelte Datenhaltung vermeiden, wie sie aktuell in den zwei separaten Arrays aus a) Beschreibungsstruktur und b) Export-Funktion vorgeschlagen ist. Ist im Endffekt nur eine Implementationsänderung:

Code: Alles auswählen

/// Internal description of an Assimp export format option
struct ExportFormatEntry
{
  /// Public description structure to be returned by aiGetExportFormatDescription()
  aiExportFormatDesc mDescription;

  // Worker function to do the actual exporting
  fpExportFunc mExportFunction;

  // Constructor to fill all entries
  ExportFormatEntry( const char* pId, const char* pDesc, fpExportFunc pFunction);
};

// global array of all export formats which Assimp supports in its current build
ExportFormatEntry gExporters[] = 
{

#ifndef ASSIMP_BUILD_NO_COLLADA_EXPORTER
  ExportFormatEntry( "collada", "Collada .dae", &ExportSceneCollada),
#endif

#ifndef ASSIMP_BUILD_NO_3DS_EXPORTER
  ExportFormatEntry( "3ds", "Autodesk .3ds", &ExportScene3DS),
#endif
};

Auf die Art gibt es nur ein Array, Abweichungsfehler können nicht aufkommen, und die Größe ist jederzeit einfach aus dem Array selbst ableitbar. Ich weiß allerdings nicht, ob das kompiliert :-)

Bye, Thomas

[kimmi]

Der Datenaustausch ist dann aber nicht universell plattformunabhängig, richtig? Und für mich sieht das sonst gut aus, mal reifen lassen.

Gruß Kimmi

[Aramis]

Good catch. Dass bereits Obj davon betroffen ist, hatte ich ganz vergessen. Zustimmung zur einfach verlinkten Liste. Wir sollten noch vorschreiben, dass der erste Blob immer das eigentliche 'Master-File' ist.

Den 'recommended extension'–Member wuerde ich aus der FormatDesc aber trotzdem nicht entfernen.

und die Größe ist jederzeit einfach aus dem Array selbst ableitbar

Ist sie jetzt auch. Schlussendlich ist es mir aber voellig egal ob jetzt 1 oder 2 Arrays. Ob das von dir Vorgeschlagene kompilieren wuerde - ja, das sollte klappen. Array-Initialisierung klappt auch mit Non-PODs, nur POD-Initialisierung (wie in der jetzigen Exporter.cpp) ist, wie der Name schon sagt, nur bei PODs legal.

[Schrompf]

Der Datenaustausch ist dann aber nicht universell plattformunabhängig, richtig?

Doch, eigentlich schon. Was sollte denn dagegensprechen?

@Aramis:
Ok, dann machen wir das so. Hab es inzwischen erprobt. Ich commite das mal und fang bei Gelegenheit dann mal an mit dem Collada-Export an.

Andere Frage: was ist der Grund dafür, dass die konkreten Exporterfunktionen den ersten Blob mit reingereicht bekommen, anstatt ihn selber zu erzeugen?

[Aramis]

Ich dachte mir das so -

Code: Alles auswählen

blob* blob = new Blob();
try {
	exporter(blob,..);
	return blob;
}
catch(DeadlyExportError&) {
	delete blob;	
	return NULL;
}

… ich wollte nur vermeiden, dass diese Struktur in jedem Exporter dupliziert wird (DeadlyExportError haette ich ganz perfide als typedef fuer DeadlyImportError hergezaubert). Ich denke, dass sich Exceptions als Abbruchhilfe bei unseren Importern (de-fakto ist Exportcode ja aehnlich strukturiert, wenngleich weniger validiert werden muss) bewaehrt haben.

IIRC hat es irgendwo im Repos auch einen ScopeGuard, der wuerde an der Stelle super reinpassen.


PS: Ich baue sobald ich dazu komme mal ein Export-Menue in den Viewer ein - der haelt sowieso die geladene aiScene die ganze Zeit im Speicher und eignet sich also optimal zum Testen.

[kimmi]

Geraten wir beim Austausch von Binärdaten von Mac-OS zu Linux nicht in Byte-Swapping-Problemstellungen ( von wegen Little- against Big-Endian )? Sicherlich ist das kein übliches Szenario, aber der Teufe ist ja bekanntermassen ein EIchhörnchen. Vielleicht sollte man einem Blob noch einen Header spendieren, aus dem man diese Infos ( Byte-Format ) ausziehen kann. Oder wollen wir das explizit verbieten beziehungsweise dafür einen Converter-Step anbieten. Oder liege ich hier komplett falsch, ich hatte bisher nur mit plattform-spezifischen Binär-Files zu tun gehabt, die man nicht austauschen kann und habe dementsprechend nicht so viele Erfahrungen vorzuweisen.
Und ja, Obj kann sogar mehr als ein mtl-File anziehen. Daher halte ich Linked-Lists hier für recht praktisch.

Gruß Kimmi

[Aramis]

Jedes Dateiformat hat ja seine eigene, genau definierte Endianess. Die Daten im Blob entsprechen dem – was wir intern eher brauchen ist ein Aquivalent zum StreamReader um es den Exporter leicht zu machen, Daten in der richtigen Endianess zu schreiben. Obj und Collada sind ja textbasierte Formate, ergo ist das fuer sie irrelevant (3DS hingegen ist ein Binaerformat).

Um die Daten wieder lesen zu koennen, muss man ja sowieso die Spezifikation des Formats kennen und somit auch die Endianess. Also besteht eigentlich kein Bedarf fuer so einen Header.

Einzig die Zeilenenden fuer Textdateien koennten problematisch werden. Eventuell koennte man dem Blob noch einen mFlags-Member geben um Textblobs zu markieren. Die Exporter schreiben dann Unix-Newlines (\n), aber wer \r\n lieber hat, kann dann manuell konvertieren bzw. beim Rausschreiben der Daten die entsprechenden File-Flags angeben.

Gruss, Alex

[Schrompf]

Endianess ist kein Problem, da muss man eh auf jedem System genau die Endianess reproduzieren, die das Dateiformat spezifiziert. Das hat Aramis ja korrekt beschrieben. Die Zeilenenden würde ich dagegen als unwichtig abtun. Ich vermute, es gibt heutzutage eh keinen Parser mehr, der eine Textdatei als binär liest und dann ganz genau eine bestimmte Kombination aus \r und \n erwartet und bei allen anderen scheitert. Die Idee mit den Flags können wir später noch einbauen, aber ich würde das erstmal aufschieben. Immerhin weiß man ja auch bisher beim Laden von textbasierten Formaten nicht, auf welchem System und mit welchen Zeilenenden die Datei erzeugt wurde.

In Anbetracht der Ausnahmen ist es in der Tat eine gute Idee, den Blob vorab zu erzeugen. Evtl. weitere Blobs erzeugt dann jeder Exporter für sich, aber wenn wir den Destruktor des Blobs ordentlich schreiben, ist das auch alles kein Problem.

[Aramis]

Parsern nicht – aber ich rieche aufgebrachte Unixler bei \r\n und verwirrte Windowsler, die ihre Textdateien nicht ordentlich im Notepad oeffnen koennen wenn wir \n nehmen bzw. keine Moeglichkeit zur Verfuegung stellen um Text-Blobs zu erkennen.

Ich wuerde das also trotzdem einfach mal einfuegen - viel Arbeit ist es ja nicht. Jeder der Text rausschreibt, setzt einfach ein Flag.

[Schrompf]

Ok, Du hast Recht. Die Änderungen sind ja minimal und noch dazu steht es dem Anwender eh frei, ob er die Flags beachtet.

[kimmi]

Also ich resümiere:

• Jeder Loader definiert seine eigene Endianess
• Dementsprechend ist der Austausch der Daten kein Problem, wenn man ein Binär-File unter Windows erstellt und dann dieses unter Mac-OS irgendwas einlesen möchte.
• Blobs werden als Linked-List eingelesen, ein Blob stellt dabei den Master dar, der Auf andere Blobs referenziert.

Einige Fragen habe ich da noch:

• Wie erkennt man den Master-Blob, der den Head der Liste darstellt? Bekommt er diesbezüglich einen speziellen Namen?
• Macht es nicht trotz dessen Sinn, Blobs einen Header zu definieren. Dieser braucht ja nicht viele Daten zu halten, Ein Flag ( 32 Bits ) für Master, Text / Binärfile reicht ja zur Zeit.
• Sollen Blobs überhaupt auf die Platte gestreamt werden können? Wenn nein: die Frage mit Endianess erübrigt sich dann, sofern niemand die Blobs per Netzwerk verteilt.

Das Problem mit den verschiedenen Zeilenumbrüchen sehe ich nicht so streng. Zumindest der Obj-Loader sollte alle Endungen korrekt erkennen und wenn dieses nicht so ist, ist das ein Bug. Vielleicht kann man ja mal schauen, wo wir im Parsen redundanten Code haben und hier mal etwas aufräumen.

Gruß Kimmi