3d Modelle auf Datei-Ebene transformieren ?? :/

[ponx]

Hallo die Herren,
peinliche Frage, aber ich bin hier am Verzweifeln..! :? Nachdem ich dank assimp jetzt fast jedes 3D-Modell aus dem Netz in mein Spiel einbinden kann (danke nochmal Jungs, für diese wundervolle Lib !), steh ich vor dem Problem, dass die Modelle in verschiedene Richtungen gucken, und ich die einfach geometrisch einheitlich ausrichten müsste. Frage: Wie macht man das ?? Ich hab hier die Demo von 3Ds Max 2009 und kann da zwar wunderbar drehen etc, nur wenn ich's dann exportiere und wieder reinlade, ist scheinbar alles wieder so wie vorher ! Alle Transformationen wirken sich anscheinend immer nur die Ausrichtung des (unveränderlichen ?) Objekts im World Space aus.
Mit Blender komm ich gar nicht klar, wenn ich da versuche was zu exportieren, erscheint es danach nichtmal im Spiel, obwohl die assimp debug-ausgabe gesund aussieht. Jetzt woll ich euch fragen, was ihr so benutzt, um ein Modell schnell und einfach (oder irgendwie) zu zentieren / rotieren / skalieren ?

Für jeden Tipp dankbar:
der ponx

[Zudomon]

Du könntest dir eine kleine Funktion basteln, die die Positionen der Eingabedaten umtransformiert. Skalieren, rotieren und positionieren machste wie gewohnt über Matrizen... Mit der Funktion D3DXVec3TransformCoord kannst du einen 3D-Vektor durch eine Matrix schicken und bekommst dann das Ergebnis zurück.
Vielleicht solltest du anschließend das Objekt umtransformiert speichern, da das ganze ja sonst bei jedem laden gemacht werden muss.

[Schrompf]

Evtl. übersiehst Du, dass auch der Wurzelknoten der Assimp-Szene eine Transformationsmatrix hat. Wenn Du in 3DSMax ein Objekt drehst und dann wieder abspeicherst, dürfte sich die Änderung nur an genau dieser Trafo-Matrix zeigen. Die scheinst Du aber zu ignorieren. Anders kann ich mir das beschriebene Phänomen nicht erklären.

Bleibt natürlich immernoch das Ärgernis, dass 3D-Modelle aus dem Internet beliebige Standards für "Wo ist vorn" und "wo ist oben" definieren. Dafür gibt es halt keinen Standard, das ist Absprachesache mit den Grafikern. Wir importieren bei uns immer erstmal alles in den hauseigenen Editor, wo wir es dann noch zurechtdrehen und nachbearbeiten können. Evtl. solltest Du auch so eine Zwischenstelle einbauen. Du ermittelst beim Import per Klick, wo "vorne" ist, und bearbeitest dann die Meshes und die Bone-Offset-Matrizen mit der entsprechenden Rotationsmatrix. Bzw. die Offsetmatrizen mit der inversen... naja, wirst Du dann ja sehen.

[Aramis]

Beziehungsweise: du bastelst dir am besten einen kleinen Minimalviewer der die Modelle via Assimp lädt und anzeigt. Da drehst du sie dann manuell zu recht und speicherst sie dann in einer für deine Zwecke geeigneten Datenstruktur wieder ab. Im Hauptprogramm lädst du dann diese optimierten Datenhaufen, was auch noch deutlich schneller gehen dürfte als direkt via Assimp.

Bei der von dir beschriebenen Vorgehensweise gibt es 3 potentielle Schuldige ... der betreffende Assimp-Importer, der 3DS-Max Importer und dann auch noch der 3DS-Max Exporter. Da kann einfach eine Menge schief gehen :-) Ich denke daher, dass obige Lösung am geschicktesten und auf Dauer am stressfreiesten ist.

Alex

PS:

Mit Blender komm ich gar nicht klar, wenn ich da versuche was zu exportieren, erscheint es danach nichtmal im Spiel, obwohl die assimp debug-ausgabe gesund aussieht

Schick mir doch bitte mal so einen Blenderexport :-)

[ponx]

vielen Dank euch dreien für die wertvollen Tipps ! Ich werd das wohl tatsächlich so machen dass ich erst per Funktion drehe, und dann in einem eigenen Datenformat abspeichere.
Dass assimp bei komplexen Modellen schon mal ne ganze Weile braucht (ca 10 Sekunden in meinem Fall), war noch so ein Problem, das damit dann vielleicht vom Tisch ist. Ich dachte ich könnte später per 3D-Editor irgendwie die Polygon-Dichte reduzieren, aber wenn ich nichtmal das Drehen hinbekomme...! :) oder gibt's da eine gute Standard-Herangehensweise ? wie macht ihr das , oder tastet ihr euch polygonzahl-technisch bei den Modellen eher von unten ran ?

cheers,
ponx

[Zudomon]

Einen Standard gibt es nicht. Wie du schon sagst, hat man zwei Möglichkeiten. Tesselieren ( Polygonzahl erhöhen ) und Optimieren ( Polygonzahl verringern ).
Zu beiden gibt es einige Algos. Zum Tesselieren könntest du bei Dreiecksnetze auf LoopSubdivison zurückgreifen, bei Vierecksnetze CatmullClark. Zum optimieren kann man "Progressive Meshes" benutzen. Unter DX9 sind die implementiert.

Bei der Tesselierung wird ein Dreieck/Viereck in weitere Dreiecke/Vierecke unterteilt. Bei den Standardverfahren ( ohne adaptives Subdivide ) vervierfacht sich die Dreiecks-/Viereckszahl.
Bei der Optimierung kenne ich es nur, das man sich eine Kante sucht, die am unwichtigsten ist ( aufgrund von Winkeln usw. ) und diese dann "collapsed", also beide Endpunkte der Kante, auf ein gemeinsames mittel bringt. Dadurch verschwinden dann auch die beiden Dreiecke, die mit der Kante verbunden waren. Das ganze wird solange gemacht, bis der gewünschte Detailgrad erreicht ist.
Bei den sogenannten "Progessive Meshes" werden die Schritte gespeichert, damit man das auch wieder Rückgängig machen kann.

Vielleicht konnte das einen kleinen Überblick verschaffen.

[Schrompf]

Im Nachhinein am Polycount eines Objektes zu drehen ist eine ganz miese Idee. Das ist für Detailreduktion auf die Entfernung noch ganz ok, aber die automatischen Algorithmen, die ich kenne, haben kaum den Blick für das Detail, dass der Mensch sofort sieht. Wir machen das bei uns mit einer Mischung aus manuell und automatisiert im Editor, nach dem Import.

Mach Dir über den Polycount nicht so viel Sorgen. Das lohnt sich nur für Objekte, die wirklich oft auftauchen. Grundsätzlich musst Du erstmal dankbar sein, vom Grafiker überhaupt irgendwas zu bekommen. Und erst wenn das wirklich aus dem Rahmen fällt, musst Du Dir Gedanken über den Polycount machen. Ansonsten sei lieber glücklich und nimm es. Wenn der Grafiker tatsächlich arbeitsbereit ist, schickst Du ihn lieber auf ein anderes benötigtes Objekt los, anstatt das gleiche mit anderem Polycount nochmal machen zu lassen.

Nachträgliche Unterteilung halte ich für ebenso unnötig. Das macht der Grafiker, wenn er es für nötig hält, und auch wo er es für nötig hält. Das, was Du dann noch an automatischem Polycount hinzufügen kannst, ist den optischen Effekt kaum wert.

[Aramis]

Wenn der Polycount der Engpass ist, könnte eventuell auch brutaleres Culling helfen um die Zahl sichtbarer Dreiecke möglichst klein zu halten. Eventuell Occlusion-Culling.

[Zudomon]

Nachträgliche Unterteilung halte ich für ebenso unnötig. Das macht der Grafiker, wenn er es für nötig hält, und auch wo er es für nötig hält. Das, was Du dann noch an automatischem Polycount hinzufügen kannst, ist den optischen Effekt kaum wert.

Das denke ich aber nicht! :D Bei meiner Fledermaus setze ich das Subdivide gezielt ein, um aus dem Low-Poly, High-Poly zu machen. Wobei dann automatisch bei den wichtigen Stellen mehr Dreiecke entstehten. Siehe hier Im Mund sind die Dreiecke für die Zähne viel detaillierter, als im Gesicht. Das Modell hat in der Detaillierten darstellung 108k Dreiecke, gespeichert aber gerade mal 60kb da es ja reicht, das Low-Poly Modell abzuspeichern.
Außerdem kann man so ja direkt verschiedene LODs erzeugen.
Ich denke, es hat viele Vorteile, den Detailgrad eines Objekts direkt zur Laufzeit bestimmen zu können.

Wenn der Polycount der Engpass ist, könnte eventuell auch brutaleres Culling helfen um die Zahl sichtbarer Dreiecke möglichst klein zu halten. Eventuell Occlusion-Culling.

Viele machen den Fehler und glauben, das zu viele Dreiecke ein Grund für langsames Rendering ist. Um mal deutlich zu machen, wie viele Dreiecke man dafür braucht:
Mit einer GeForce 9600GT ( die ja alles andere als High-End ist ) habe ich bei ner Auflösung von fast 1920x1200 etwa 195 FPS bei diesem abgerundeten Zylinder.
Dieser besteht aus genau 2.949.120 Dreiecke, siehe Wireframe.
Wenn man mal bedenkt, dass man bei einer Auflösung von 1920x1200 gerade mal 2.304.000 Pixel hat, könnte man auf jeden Pixel mehr als ein Dreieck rendern bei 195 FPS.
Nur mal, damit man ein Grfühl dafür bekommt, wie viel man an Rechenleistung zur Verfügung hat. :D

Edit: Was nicht heißen soll, das Culling überflüssig ist, ganz im Gegenteil! Aber es muss halt sehr schnell sein, und wenn mal tausend Dreiecke mehr oder weniger gerendert werden, macht das nicht viel aus.

[Schrompf]

Nachträgliche Unterteilung halte ich für ebenso unnötig. Das macht der Grafiker, wenn er es für nötig hält, und auch wo er es für nötig hält. Das, was Du dann noch an automatischem Polycount hinzufügen kannst, ist den optischen Effekt kaum wert.

Das denke ich aber nicht! :D Bei meiner Fledermaus setze ich das Subdivide gezielt ein, um aus dem Low-Poly, High-Poly zu machen. Wobei dann automatisch bei den wichtigen Stellen mehr Dreiecke entstehten. Siehe hier Im Mund sind die Dreiecke für die Zähne viel detaillierter, als im Gesicht. Das Modell hat in der Detaillierten darstellung 108k Dreiecke, gespeichert aber gerade mal 60kb da es ja reicht, das Low-Poly Modell abzuspeichern.
Außerdem kann man so ja direkt verschiedene LODs erzeugen.
Ich denke, es hat viele Vorteile, den Detailgrad eines Objekts direkt zur Laufzeit bestimmen zu können.

Hmm... wenn Du magst, dann tu das. Aber abgesehen von der technischen Faszination an den Algorithmen und Ergebnissen finde ich da nicht viel zu holen. Die Fledermaus ist halt bewusst so modelliert, dass sie erst durch die Tesselierung gut aussieht. Der Basismesh ist teilweise ziemlich formentstellt, mit übermäßig ausufernden Rundungen, damit nachher der unterteilte Mesh vernünftig aussieht. Und 108k sind eine völlige Verschwendung dafür. Wenn der mal Bones und komplexere Oberflächenshader bekommt und am Ende sogar noch 20 davon in der Dorfszene auf dem Bildschirm rumlaufen sollen, ist der Ofen aus.

Ich wollte mit meinem Beitrag sagen: ob ein Charakter 5k oder 10k hat, ist erstmal Schnuppe... freut euch lieber, dass ihr überhaupt einen Charakter habt. 20k gehen auch noch, ab 50k sollte eine Überarbeitung ran. Es ist immer ein Abwägen zwischen Arbeitsaufwand und Performance-Gewinn. Bei einem einzelnen Charakter wird der Gewinn nie sonderlich groß sein, daher lieber behalten, auch wenn er zuviele Polys hat. Wenn euch jemand einen Farn mit 500 Dreiecken anbietet, müsst ihr dagegen kämpfen... denn immerhin werden davon nachher ein paar tausend Instanzen in der Szene rumstehen.

Viele machen den Fehler und glauben, das zu viele Dreiecke ein Grund für langsames Rendering ist.

Ja, aber viele machen auch den Fehler und glauben, dass zu viele Dreiecke ein Grund für das schnelle Rendering wären. 200fps bei einem einzelnen statischen Mesh mit Trivial-Shadern sind eben kein relevantes Performance-Szenario, egal wieviele Dreiecke der Mesh hat.

Mit obigem Farnbeispiel habe ich übrigens selbst meine Radeon 4870 plattbekommen. Einmal PräZ-Pass, einmal Hauptpass, einmal für die Sonnen-ShadowMap - und schwupps sind wir bei fünf Millionen Polys. Und dann holt noch jemand die Fackel aus dem Inventar. Seit der Reduktion auf 200 Polys läufts auch auf einer seligen Geforce7800 wieder mit vertretbarer Geschwindigkeit.

[Zudomon]

@Schrompf
Deine Kritik ist berechtigt und es stimmt ja auch soweit. Was ich vermitteln wollte war, dass die Dreieckszahl selbst nicht groß ins Gewicht fällt. Wenn man natürlich Effekte und etliche Instanzen von einem Objekt rendert, dann kommt man sehr schnell in den siebenstelligen Polygonzahl.
Was allerdings ins Gewicht fällt sind, wie du auch sagst, aufwendige Shader und die Füllrate.

Bzgl. der Fledermaus, gerade weil das Basismesh so formentstellt sein muss um nach dem Subdivide normal auszusehen, wäre es für mich eine überlegung Wert, auch dieses Progressive Verfahren einzubauen, damit ich an ein einigermaßen normal aussehendes Low-Poly-Modell rann komme.
Wenn man LOD einsetzt, dann bin ich mir aber ziemlich sicher, dass man 20 davon in einer Dorfszene rumlaufen lassen kann. Wenn man erstmal 1-2 Meter weg ist, gebe ich dir Recht, dann sind 108k Verschwendung, aber ansonsten sieht man schon einen Unterschied.

[Aramis]

Nunja, hier würde man das Subdivisionsmesh sehr wohl brauchen. Nämlich um aus ihm und dem Low-poly-Mesh eine passende Detail-Normalmap zu berechnen. Im Spiel nimmt man den Unterschied zwischen Low-poly mit Parallax-Mapping und High-Poly sowieso nicht wahr. Insofern hat das ganze imho schon seine Daseinsberechtigung :-)

Mit Grafikkarten der nächsten Generation könnte man das dann auch alles auf der GPU machen. Automatische Tesselation, dann Displacement Map um feine Details hineinzubringen. Ich will gar nicht wissen, was Thomas mit seinen Farnen dann noch alles anstellt.

Alex

[Zudomon]

Die Frage ist auch, wie aufwendig die einzelnen Shader sind. Ich denke, sehr bald ist es sinnvoller, lieber mit Displacementmaps und Dreiecke zu arbeiten, als mit Parallaxmapping. Vor allem, wenn man das ganze schattiert und auch korrekte Silhouetten haben möchte, wird der Aufwand dafür extrem hoch.