[OpenGL] Blend/Binormal/Tangent-Attribute an OpenGL senden?

[Krishty]

Nach meiner Rechnung wäre übrigens ein MAD besser für GFLOP-Rechnungen: 4 muls und 4 adds. Ein dot bringt ja nur 4 muls und 3 adds auf die Waage :-)

Klar. Ich Kopf vorm Brett.

Nach meinem Wissen sind die enormen Rechenkern-Zahlen von ATI nur Marketing-Mathematik: man gibt halt die skalaren Einheiten an anstatt der Vektoreinheiten.

AMD kriegt die Recheneinheiten aber tatsächlich in allen relevanten Anwendungen zu über 80 % ausgelastet (leistungsfähigem Compiler sei dank) – mit der 6xxxer-Serie, die nur noch vier statt fünf Skalareinheiten pro Vektor hat, dürfte die Effizienz noch höher liegen. Es wird auch schon seit drei Jahren dazu geraten, für AMD aufs Verderben skalar zu programmieren.

[Lynxeye]

Die 68xx hat noch 5-wide VLIW, erst die 69xx hat die neuen 4-wide. Ganz 80% sind es auch nicht, nach AMDs Aussage können im Gamedurchschnitt 3,5 der 5 Einheiten gefüttert werden.

Allerdings stimmt es schon, dass AMDs Shadercompiler wirklich sehr gute Arbeit leistet. NVidia hat es sich mit seinen 1-wide Shaderkernen in der Hinsicht sehr einfach gemacht, bekommt deshalb aber zur Zeit massive Probleme mit der Effizienz, da sie massiv Mehraufwand für das Scheduling auf der Hardware betreiben müssen.

[Krishty]

Die 68xx hat noch 5-wide VLIW, erst die 69xx hat die neuen 4-wide.

Okay. Damit weiß ich nun auch endlich, warum die 6970 auf meinen Shadern theoretisch 10 % langsamer ist als die 6870 :(

Nachtrag: Scheinbar ist AMDs Compiler auch nicht so leistungsfähig, wenn es um das Erkennen von DOT- und MAD-Potential geht … auf 20 komplexe Multiplikationen in HLSL spare ich eine Anweisung, wenn ich manuell ein dot() einsetze, und erneut eine mit mad() (1,25 % insgesamt). Die IEEE-Konformität sollte nicht dazwischenfunken weil nichts als precise deklariert ist.

[Eisflamme]

So, neues Problem:

Ich aktivierte meinen Vertex Shader und dann aktiviere ich meinen Fragment Shader. Das funktioniert nicht gleichzeitig, immer der zuletzt aktivierte wird ausgeführt. Wenn ich nur einen von beiden aktiviere, geht der. Ist das normal, gibt es da irgendwelche Tricks? Oder wieder irgendwas cg-relevantes?

So, ich mach jetzt Mal was Schlaues: Ich schau mir die CG GL Beispielcodings an -_-

Ok, diesmal hab ich glaube wirklich n Bug gefunden in dem Zeug:
Ich hab ein Beispielprogramm von denen genommen und mal die Aktivierung VS/FS verändert. Erstmal geht's. Wenn ich dann aber von den veralteten Profilen auf die aktuellen Profile umstelle (ARBVP/ARBFP -> GLSLV/GLSLF), dann macht auch dort die Verdrehung einen Unterschied und nicht beides wird ausgeführt. -_-

Also Mal abwarten, was die bei NVIDIA jetzt antworten. Wenn da nix Gescheites kommt, fliegt CG wieder ausm Fenster.

Edit:
Ok, also ich muss cgCombinePrograms nutzen, um VS und FS zu kombinieren. Dann klappt's. So langsam wird's seltsam, aber egal, es klappt. :P

Aber der Pixelshader sieht genau so aus wie der Vertexshader, also was die Belichtung geht. Ich führe ein einfaches Punktprodukt von einem Eingangslichtstrahl auf die Normalenvektoren durch, welche doch eigentlich interpoliert an den PixelShader übergeben werden müssten, oder? Irgendwie hätte ich mehr erhofft.. Aber liegt wohl daran, dass das Directional Light ist. Für Point Lights sollte der Mehrwert größer sein.

Hier ein (low qualy) Vid: http://www.youtube.com/watch?v=mmR23cZk2aE

Ich hoffe, ich darf euren Zwerg auf nem Vid zeigen? Hab im Text auch extra für euch Werbung gemacht. ^^ Und nein, ich denk jetzt nicht, das wär was Tolles, aaaaber es ist die Basis für etwas sehr Tolles. :P

[anonym]

Was meinst Du mit "der Pixelshader sieht genauso aus wie der Vertexshader"? Meinst Du bei Per-Vertex-Beleuchtung (z.B. Gouraud-Shading: Interpolation der fertigen Beleuchtungswerte der Vertices über das Polygon; besonders unschön bei Glanzlichtern, aber je detaillierter die Geometrie, desto unauffälliger) im Vergleich zu Per-Pixel-Shading (z.B. Phong-Shading: Normale und Zu-Licht-Vektor über Polygon interpolieren und erst im PS oder der "Post-Rasterizer-Stage" im Falle der FFP den Bleuchtungswert errechnen, d.h. v.a. deutlich hübschere Glanzlichter auch mit gering aufgelöster Geometrie)?
Der Zwerg scheint sich richtig zu verhalten. Bisschen mehr Licht wäre schön.

[Eisflamme]

Ja, der verhält sich richtig. :) Und ja, ich meinte das, was du gesagt hast, denke ich. Die Auflösung ist jetzt ja nicht sehr hoch vom Zwerg. Na ja...

hab extra wenig und buntes Licht genommen, um die Schattierung besser zu sehn. :) Aber ingame später weiß ich eh noch nich, wie ich das mache, mal seeeeehen

[Eisflamme]

In welchem Rahmen sollte man eigentlich die Bonematrices buffern bzw. wie macht ihr das? Die ganze Berechnung entlang der Nodes und bla und blub ist ja schon lästig. Aber da man Matrizen ja nicht interpolieren soll, reicht es nicht, wenn man einfach nur ein paar Bonematrizen nimmt und dazwischen interpoliert.

Oder was haltet ihr davon: Die resultierenden Bonematrizen splittet man wieder in Positionsvektor und Rotationsquaternion auf, puffert diese und interpoliert dazwischen. Dann braucht man nicht so viel Speicher, kann das recht schnell zurückverwandeln und hat statt den statt Interpolationen + zig Matrixmultiplikationen eben nur noch die Interpolationen und die Umwandlung in die Matrix. Sollte einen guten Performanceboost geben, oder? Dass die Animationen ein Bottleneck sein könnten, kann ich mir nämlich schon vorstellen.

[Schrompf]

Hast Du es denn nachgemessen? Eben. Also freu Dich erstmal, dass es funktioniert, und bau an der Spielelogik weiter.

Der ganze Skinning-Kram ist bei uns immer im einstelligen Mikrosekunden-Bereich gewesen. Ob sich da die Optimierung lohnt... naja, ich weiß nicht. Wenn Du aber unbedingt daran arbeiten willst, dann wäre die Zerlegung in Position und Rotation bzw. das Behalten der separaten Pos- und Rotkomponente durchaus ne Idee. Du kannst die dann auch direkt in den VertexShader hochladen - das braucht dann nur noch 2 Konstantenregister, verlängert aber den VertexShader ein bisschen. Rotation eines Vektors mittels Quaternion ist etwas anstrengender als mittels einer Matrix.

[Eisflamme]

Also wenn ich z.B. fünf Zwerge parallel animiere, aber bei jedem halt die Bones komplett nochmal berechne (was ja sein kann, wenn fünf Zwerge in verschiedenen Animations-States sind), dann ist mein Programm extrem langsam und verzögert. Ich weiß jetzt natürlich nicht, ob irgendwelche Iterationen lange dauern, unnötige Kopien drin sind oder ob die Vertexshader alles so ausbremsen bzw. die Übergabe an diese. Am häufigen De- und Aktivieren liegt's jedenfalls nicht, denn das Deaktivieren funktioniert bei diesem kombinierten Programm nämlich gerade noch nicht. Mal wieder darf ich pausieren bis mir NVIDIA ne gescheite Antwort liefert, wobei ich jedes Mal halb schon der Idee anheim gefallen bin, doch von CG Abstand zu nehmen...

Danke für die Tipps jedenfalls, aber bei mir ist das weit über dem Mikrosekundenbereich ;)

Edit: Okay, hab Mal nachgeschaut. Meine Interpolationsfunktion ist das Bottleneck... ist auch furchtbar programmiert, da muss ich mir Mal was Anständiges überlegen. Die restlichen Funktionen sind schnell genug. :)

Edit2: Okay, hab nochmal nachgeschaut. Und es ist doch CalculateAllBoneMatrices, was den Ärger macht. Klar, man läuft ja auch jedes Mal alle Parents ab und zwar für alle Bones und macht dann zig Matrizenmultiplikationen. Irgendwie ist für mich da doch auch sinnvoll, dass das lange dauert...

[dot]

Da es sich bei einem Skelett zum Glück um eine Baumstruktur handelt kannst du deine Bones so in einem Array ablegen dass jeder Parent immer vor all seinen Children liegt. Dann brauchst du einfach nur einmal über das Array zu laufen und alle Matritzen upzudaten und fertig. Ich hab damit auch bei einer unoptimierten Implemtierung kein Problem mal 100 unabhängig animierte Modelle zu rendern...

[Eisflamme]

Das klingt nicht schlecht.

Leider sind bei mir anscheinend alle Einzelteile langsam. Ich habe z.B. mittlerweile eine map<string,Bone*> als Puffer gebastelt. Für jedes Node muss man natürlich nochmal ein einen Zugriff machen. Der sollte aber eigentlich ja auch nicht so lange dauern. Die Interpolation ist auch nicht schnell. Die läuft auch nicht toll ab. Ich laufe halt durch alle Einträge meines vector<float,Transformation> mit float für die Zeit und wenn dann die Wunschzeit über der Zeit des Vektoreintrags liegt, merk ich mir den Eintrag und den danach und interpoliere dann. Ständig zu interpolieren ist auch nochmal aufwendig und kostet Zeit.

Außerdem wird letztlich alles unsauber... Mein Model hat Bones und Nodes. Bones kennen Nodes, es ist aber absolut nervig, vom Bone eine Beziehung zurück zum Node zu haben (was ja nötig wäre, weil mein Model die einzelnen Nodes cacht... ob durch map oder einfach ein Array mit ein paar Zusatzinfos wie bei dir). Oder ich bastel in jedes Bone halt ein Array mit allen Zeigern, das ich dann durchlaufe, aber irgendwie glaub ich, das wird auch nich reichen.

Was also folgen muss, ist eine umfassendere Performanceanalyse und dann muss ich alles Mal irgendwie umbauen. Bisher hab ich ein Model und das hat 1 : 1 ein Mesh. Und das Mesh hat alle Buffer und bietet auch Methoden zum Befüllen. Und das ist alles so nervig, weil meine AssimpLoader-Klasse (und da es hier nur eine Instanz gibt, ist eine Klasse auch irgendwie ne doofe Wahl) Zugriff auf alle Modelteile braucht, um halt was reinzuladen. friend ist scheiße, weil ich neben AssimpLoader später noch nen Loader für mein eigenes Format bauen will -> Abhängigkeit zu speziellem Loader nervt...

Na ja, liegt also einiges im Argen...

[dot]

Ich habe z.B. mittlerweile eine map<string,Bone*> als Puffer gebastelt.

Darf ich fragen warum, musst du wirklich im laufenden Betrieb Bones über ihre Namen ansprechen? Assoziative Container und Stringvergleiche sind jetzt nicht so der Burner wenns um Performance geht, vor allem weil es in deinem Fall absolut nicht notwendig ist, zumindest wüsste ich nicht wofür.

Außerdem versteh ich nicht ganz wofür du Bones und Nodes brauchst, ich komm nur mit einem davon aus. Durch dieses verworrene Design hast du nun halt überall irgendwelche unnötigen Indirektionen. Ein lineares Array für alle Bones tuts bei mir auch, einfach und effizient...

Ich laufe halt durch alle Einträge meines vector<float,Transformation> mit float für die Zeit und wenn dann die Wunschzeit über der Zeit des Vektoreintrags liegt, merk ich mir den Eintrag und den danach und interpoliere dann. Ständig zu interpolieren ist auch nochmal aufwendig und kostet Zeit.

Du könntest dir den letzten Keyframe merken und von dort aus mit der Suche starten. Um die Interpolation kommst du so oder so nicht herum, du kannst höchstens versuchen sie zu optimieren.

Was also folgen muss, ist eine umfassendere Performanceanalyse und dann muss ich alles Mal irgendwie umbauen.

Ich würd gleich mal das ganze System neu strukturieren und dann die Performance vom neuen System messen und optimieren anstatt vorher schon Zeit damit zu verschwenden ;)

[Eisflamme]

Ich würd gleich mal das ganze System neu strukturieren und dann die Performance vom neuen System messen und optimieren anstatt vorher schon Zeit damit zu verschwenden.

Gute Idee, das ist ja auch mein Plan, weswegen ich gerade erstmal am brainstormen bin, wie ich das machen kann. :)

Die Struktur habe ich halt von Assimp übernommen. Ein Bone bezieht sich auf ein Node. Die Animation findet erstmal in den Nodes statt und die Verkettung der Nodes wird dann mit der Offsetmatrix der Bones jeweils verschlüsselt. Lineares Array heißt ja, dass ich die Offsetmatrix und alle passenden Nodematrizen hintereinander legen müsste... Aber dann habe ich doch ziemliche Redundanz? Ein Elternobjekt hat mehrere Kinder und dann hätte ich die Eltern für jedes Kind (im Endeffekt = Bone) nochmals gespeichert. Ich habe nicht das Gefühl, als wenn du von Zeigern auf die Matrizen sprichst, damit ginge das natürlich.
Aber auch für die Animationen brauche ich dann jeweils ja den Zugriff auf meine Nodes.
Daher auch der namentliche Zugriff (Bone kennt Node über Name, Animation kennt Node über Name), aber das lässt sich ohne großen Aufwand auf Zahlen abbilden. Ich hätte jetzt nur nicht gedacht, dass die Stringvergleiche so aufwendig sind, aber dadurch, dass man ständig zu Zeichen 2,3,4... iterieren muss, bevor der Vergleich statt findet, geht da wohl schon viel verloren...

Letzten Keyframe merken ist schon Mal eine Idee. Überhaupt waren da viele gute Anregungen dabei, ich lass mir das Mal durch den Kopf gehen, auch wenn ich das Gefühl habe, dass mir ein paar zu viele Puzzleteile im Verständnis von Animationen fehlen. :)

PS: Bist du eigentlich auf c-plusplus.de auch dot? ;)

[Schrompf]

Man kann die Nodes auch alle in ein lineares Array packen und mittels Parent-Index den Baum abbilden. Da Du immer nur von Node zu Parent gehst und nicht andersrum, reicht das völlig aus. Die Redundanzen sind dabei völlig schnuppe, das sind eh nur ein paar hundert Byte pro Mesh.

Ich muss aber nochmal betonen, dass Du an der falschen Stelle sparst. Solche Optimierungen merkst Du erst, wenn Du ein paar tausend Zwerge gleichzeitig animierst. Deine Rechenzeit wird eher woanders draufgehen. Und das wirst Du ohne Profilen nicht herausfinden.

[dot]

PS: Bist du eigentlich auf c-plusplus.de auch dot? ;)

Ja mir kommt vor wir haben dort schonmal über das geredet :D

[Eisflamme]

Also wenn ich entsprechende Methoden auskommentiere, kann ich die Zwerge ohne Performanceverlust "animieren", man sieht eben nichts Animiertes. Daher gehe ich schon davon aus, dass die Performanceverluste dort sind.

Aber kannst Du mir einen guten Profiler empfehlen? :)

[Lynxeye]

AMD CodeAnalyst ist gut und kostenlos. Funktioniert auch auf Intel CPUs, aber nicht mit allen Funktionen.

[Schrompf]

Ich benutze den in Visual Studio 10 eingebauten Profiler. Hab noch nicht so viel Erfahrung damit, aber bisher sieht der echt gut aus. AMDs Code Catalyst wird von anderen sehr gemocht, aber ich fand den nicht so praktisch. Intels VTune ist unerreichbar. VerySleepy und ähnliche Simpel-Profiler waren mir immer die liebsten, funktionieren aber unter Vista/Win7 nicht mehr so einfach.

Und es ist halt die Frage, was die auskommentierten Funktionen so alles machen... ein Lookup in eine Map mit ~40 Einträgen anhand eines Strings ist schon vieles langamer als ein Zugriff auf ein lineares Array anhand eines numerischen Index'. Allerdings solltest Du auf einem aktuellen Desktop-PC im Release-Build immernoch einige Dutzend Millionen davon pro Frame machen können, obwohl ein Zwerg nur ~40 davon pro Frame braucht. Daher meine Meinung, dass es an was anderem liegen muss.

[Eisflamme]

Ich mein nur: Wenn ich die Matrizen redundant abspeichere, muss ich ja auch für jede Matrix erneut die Animation anwenden und somit interpolieren.

VS-Profiler probier ich Mal aus!

Hat eigentlich jemand eine Idee, wie ich es mache, dass Model keine Gottklasse ist? Auf c++.de kommen irgendwie keine Vorschläge. Aber eigentlich find ich's auch nicht so schlimm, es ist nur ein Rieeeeeeeesenklasse.

[Eisflamme]

Okay, also auch ohne Profiler durch simples Auskommentieren ein paar Methoden habe ich herausgefunden, dass das Neuberechnen aller Bones bei 5 Zwergen genau 10 FPS gekostet. Es liegt also an den ganzen Containern, den Maps, der Parent-Matrizenmultiplikationen und und und... genau das geht in die Performance... ich bin natürlich im Debugmode und habe eine eigene Matrixmethode. Vielleicht ist die Multiplikation auch einfach nicht performant?

Code: Alles auswählen

		Matrix4x4 operator*(const Matrix4x4& mat) const
		{
			return Matrix4x4(	comp_[0] * mat.comp_[0] + comp_[1] * mat.comp_[4] + comp_[2] * mat.comp_[8] + comp_[3] * mat.comp_[12], // Coord 00
								comp_[0] * mat.comp_[1] + comp_[1] * mat.comp_[5] + comp_[2] * mat.comp_[9] + comp_[3] * mat.comp_[13], // Coord 10
								comp_[0] * mat.comp_[2] + comp_[1] * mat.comp_[6] + comp_[2] * mat.comp_[10] + comp_[3] * mat.comp_[14], // Coord 20
								comp_[0] * mat.comp_[3] + comp_[1] * mat.comp_[7] + comp_[2] * mat.comp_[11] + comp_[3] * mat.comp_[15], // Coord 30
								comp_[4] * mat.comp_[0] + comp_[5] * mat.comp_[4] + comp_[6] * mat.comp_[8] + comp_[7] * mat.comp_[12], // Coord 01
								comp_[4] * mat.comp_[1] + comp_[5] * mat.comp_[5] + comp_[6] * mat.comp_[9] + comp_[7] * mat.comp_[13], // Coord 11
								comp_[4] * mat.comp_[2] + comp_[5] * mat.comp_[6] + comp_[6] * mat.comp_[10] + comp_[7] * mat.comp_[14], // Coord 21
								comp_[4] * mat.comp_[3] + comp_[5] * mat.comp_[7] + comp_[6] * mat.comp_[11] + comp_[7] * mat.comp_[15], // Coord 31
								comp_[8] * mat.comp_[0] + comp_[9] * mat.comp_[4] + comp_[10] * mat.comp_[8] + comp_[11] * mat.comp_[12], // Coord 02
								comp_[8] * mat.comp_[1] + comp_[9] * mat.comp_[5] + comp_[10] * mat.comp_[9] + comp_[11] * mat.comp_[13], // Coord 12
								comp_[8] * mat.comp_[2] + comp_[9] * mat.comp_[6] + comp_[10] * mat.comp_[10] + comp_[11] * mat.comp_[14], // Coord 22
								comp_[8] * mat.comp_[3] + comp_[9] * mat.comp_[7] + comp_[10] * mat.comp_[11] + comp_[11] * mat.comp_[15], // Coord 32
								comp_[12] * mat.comp_[0] + comp_[13] * mat.comp_[4] + comp_[14] * mat.comp_[8] + comp_[15] * mat.comp_[12], // Coord 03
								comp_[12] * mat.comp_[1] + comp_[13] * mat.comp_[5] + comp_[14] * mat.comp_[9] + comp_[15] * mat.comp_[13], // Coord 13
								comp_[12] * mat.comp_[2] + comp_[13] * mat.comp_[6] + comp_[14] * mat.comp_[10] + comp_[15] * mat.comp_[14], // Coord 23
								comp_[12] * mat.comp_[3] + comp_[13] * mat.comp_[7] + comp_[14] * mat.comp_[11] + comp_[15] * mat.comp_[15]); // Coord 33
		}

Und der ctor weist das Ergebnis dann wiederum immer zu. Also ich glaube nicht, dass ich an der falschen Stelle optimiere... vll. sind auch die boost- und std-Container langsam, ich habe ja so einige finds, []-Zugriffe über string uvm. auf alle möglichen Container. Wieso ist das denn dann bei mir alles so langsam, wenn das eigentlich trotz allem nicht ins Gewicht fallen sollte? Ich bin im Debug-Mode und habe nen i7-Prozessor, also 4 x 2,7 GHz-Kerne, das sollte doch nicht sooo schlecht laufen. =/

[Schrompf]

Bau eine Release. Die ist bei mir 10 bis 50 mal so schnell wie die Debug. Außerdem: FPS sind keine Zeitangabe. 10 FPS bei was? 310 zu 320? Oder 10 zu 20?

[Eisflamme]

Geht von 100 auf 90 =/

Ok, die Release wird vermutlich schneller laufen. Aber ich sollte ja auch im Debug eine angemessene Performance haben, oder? Ich schau Mal, dass ich eine Release zu stande kriege. :)

[dot]

Deine 4 Kerne allein bringen dir nicht viel, wenn du dein Programm nicht entsprechend parallel programmiert hast dann lauft es auch nur auf einem Kern. Abgesehen davon sind Stringvergleiche und find Operationen in assoziativen Containern wie schon gesagt alles andere als optimal. Wenn wirklich die Matritzenmultiplikation das Problem ist vermute ich mal dass du zu viele davon machst!? Kann es sein dass du für jeden Child Node ständig die komplette Hierarchie traversierst? Wie schon gesagt musst du die Transformation für jeden Node eigentlich nur ein einziges Mal pro Updatevorgang berechnen. Du könntest zumindest eine Überprüfung einbauen ob der Node schon upgedated wurde und in dem Fall direkt das Ergebnis verwenden anstatt alles ständig von unten nach oben durchzurechnen was (wenn ich jetzt nicht schon zu müde für sowas bin) exponentielles Laufzeitverhalten hat. Am idealsten wäre es natürlich wie auch schon gesagt die Bones in einem linearen Array zu halten und zwar so sortiert dass Parents vor ihren Children kommen. Dann brauchst du nur einmal durchlaufen und kommst mit einer einzigen Multiplikation pro Bone aus...

[Eisflamme]

Ok, also im Release bleibt die Performance bei 5 animierten oder nicht-animierten Zwergen bei ~860 FPS. Bei 3500 animierten Zwergen (also Berechnung der Matrizen ohne Anzeige) geht die allerdings rapide zu Boden, da sind es nur noch 20-30 FPS.

dot:
Ja, alles richtig, jetzt kapiere ich so langsam auch, was ich falsch mache. Aber nur nochmal, um das klar zu machen: Die Hierarchie muss ich ja immer komplett gemäß ihrer Animationen berechnen, also habe ich folgenden Ablauf:

1) durch alle Animationen laufen und entsprechende Nodes aktualisieren (hier: zZ Stringzugriff auf einzelne Nodes -> kann mit Indexzugriff optimiert werden)
2) entsprechende Nodes linear ablaufen (angenommen, die liegen jetzt bereits im sortierten Array) und für jeden Node die Multiplikation mit der Matrix der Animation (von Schritt 1) mit dem Elternelement (oder E) durchführen
3) Offset-Matrix des Bones mit entsprechender Nodematrix multiplizieren

Ich sehe irgendwie noch nicht, wie ich davon so viele Schritte auslassen kann, dein Vorschlag ist ja mehr oder weniger nur der zweite!?

[dot]

Wenn du bei jedem Bone immer rekursiv von unten nach oben durchläufst brauchst du nicht nur eine Multiplikation pro Bone sondern n wobei n die Anzahl der Parents des entsprechenden Bones ist. Unter der Annahme dass dein Skelett ein perfekt balancierter Baum ist kommt das am Ende auf exponentiell viele Multiplikationen wobei aber nur linear viele notwendig wären. Das ist was ich gemeint hab. Aber wenn du 3500 Zwerge animieren kannst machst du das wohl eher nicht so weil sonst wär da schon viel früher Schluss. tbh seh ich jetzt nicht gleich sooo ein großes Performance Problem wenn 3500 Zwerge mi 30FPS laufen^^

[Eisflamme]

Hm...

Also mein Bone schaut nach dem passenden Node und dann wird komplett zum TopParent hochverkettet, das ist schon ne unglaubliche Unnötigkeit :P Das Gerät hier kann halt was.

Okay, dann sehe ich wirklich, wo ich die Optimierung bauen kann. Ich werde dies tun! :)

Vielen Dank nochmals! Der nächste Post kommt bestimmt.

[dot]

[...] das ist schon ne unglaubliche Unnötigkeit :P [...]

In der Tat :P

[Eisflamme]

Ne unordered_map von Boost dürfte bei strings keine Performanceprobleme mehr haben, oder? Dann finde ich es nämlich ganz schön, weiterhin über strings zu gehen (auch wenn ich verstehe, dass der Hauptperformanceverlust an o.g. Stelle liegt ;)).

[Krishty]

Ich habe z.B. mittlerweile eine map<string,Bone*> als Puffer gebastelt.

Warum eigentlich ein Zeiger?

[Eisflamme]

Ich meinte Node statt Bone. Und ein Zeiger deswegen, weil das nur ein erster Performance-Test war und ich somit erstmal nur Kopien auf meine nach wie vor in Hierarchie gegliederten Nodes verwendet hab.

Aber ich baue das jetzt ja sowieso komplett um.

Hm... eigentlich könnte man die AnimationChannel doch einem Node komplett unterordnen, wir haben ja nicht 1:n Node:Animation.