Hardware Instancing

Wally

Beim Hardware Instancing unter Dx9 brauche ich ja 2 Vertex Buffer.

VB0 mit der eigentlichen Objektgeometrie.
VB1 mit den per Instance Daten (Transformation,Shaderparams).

Wie ich das prinzipiell implementier ist mir klar, nur nicht wie ich das ins Szenenmanagement einbaue.
Mal angenommen, ich traversiere meinen SG vorm rendern, sortiere alle Nodes mit instanzierbarer Geometrie nach eben diesen Objektgeometrien, ist es dann kritisch einen VB aus den Transformationsinformationen "on the fly" zu erstellen, über den Bus zu jagen und anschließend die DrawCalls zu feuern? Natürlich weiß ich das es auf jeden Fall performanter ist die VB1 schon auf Halde zu haben, aber müsste man die "on the fly" Methode schon als Kontraproduktiv bezeichnen?

Ab wie vielen zu rendern Objektinstancen würdet ihr Hardwareinstancing vorziehen?

MfG Wally

rapso

Wally schrieb:

ist es dann kritisch einen VB aus den Transformationsinformationen "on the fly" zu erstellen, über den Bus zu jagen und anschließend die DrawCalls zu feuern?

du schiebst die selbe menge an instanzdaten ueber den bus wie bei einzelnen drawcalls, lediglich die drawcall anzahl wird kleiner, es wird also ein bisschen weniger kritisch sein als ohne instanzing.

Natürlich weiß ich das es auf jeden Fall performanter ist die VB1 schon auf Halde zu haben, aber müsste man die "on the fly" Methode schon als Kontraproduktiv bezeichnen?

nein, dynamische VB in begrenzter form koennen schnell sein.

Ab wie vielen zu rendern Objektinstancen würdet ihr Hardwareinstancing vorziehen?

je nach hardware usw. so ca 8-10 wuerde ich sagen
bei so ca 3000 objekten.

Wally

Erstmal danke für die Antwort.

je nach hardware usw. so ca 8-10 wuerde ich sagen
bei so ca 3000 objekten.

Meinst du damit, dass du die 3000 Instanzen in 8 bis 10 Batches rendern würdest?
Soll das ein Hinweis sein, dass ich auch mit HardwareInstancing die "3000er" Grenze nicht überschreiten kann?

Stimmt die Aussage, die ich mal irgendwo meine gelesen zu haben, dass man anstelle von vielen Dynamischen Resourcen lieber eine große Dyn Textur und einen großen Dyn VB nutzen soll?

Ich hab das Problem mit den "nur" 300 Batches bei ca. 40FPS auch schon gelöst. (Beziehe mich hier auf einen anderen Thread). Hab statt dem Materialsystem der Engine welches DX Effekte in Kaskaden nutzt (siehe Codekasten) einfach mal nen einfachen Diffusen Pixelshader ans Device gebunden. Mit ein paar wenigen Calls schafft die Engine bis zu 5000 FPS. Bei voller Geometrie (300 Batches) immer noch über 350 FPS . Scheint wohl durch die Kaskadentechnik, oder allgemein durch den Einsatz des Effektframworks zu einem Overhead an Statechanges (=ApiCalls) zu kommen.

fx0->BeginPass
     fx1->BeginnPass
     //.....
     fx1->EndPass
fx0->EndPass

MfG Wally

rapso

Wally schrieb:

Erstmal danke für die Antwort.

je nach hardware usw. so ca 8-10 wuerde ich sagen
bei so ca 3000 objekten.

Meinst du damit, dass du die 3000 Instanzen in 8 bis 10 Batches rendern würdest?
Soll das ein Hinweis sein, dass ich auch mit HardwareInstancing die "3000er" Grenze nicht überschreiten kann?

nein, damit meinte ich dass man die 3000auch ohne instanzing hinbekommen sollte, bevor man sich an das instanzing setzt, weil ich mich erinnert hatte dass du das problem hattest.

Stimmt die Aussage, die ich mal irgendwo meine gelesen zu haben, dass man anstelle von vielen Dynamischen Resourcen lieber eine große Dyn Textur und einen großen Dyn VB nutzen soll?

wenn man sie richtig managen kann.

Ich hab das Problem mit den "nur" 300 Batches bei ca. 40FPS auch schon gelöst. (Beziehe mich hier auf einen anderen Thread). Hab statt dem Materialsystem der Engine welches DX Effekte in Kaskaden nutzt (siehe Codekasten) einfach mal nen einfachen Diffusen Pixelshader ans Device gebunden. Mit ein paar wenigen Calls schafft die Engine bis zu 5000 FPS. Bei voller Geometrie (300 Batches) immer noch über 350 FPS . Scheint wohl durch die Kaskadentechnik, oder allgemein durch den Einsatz des Effektframworks zu einem Overhead an Statechanges (=ApiCalls) zu kommen.
fx0->BeginPass
     fx1->BeginnPass
     //.....
     fx1->EndPass
fx0->EndPass

ja, deswegen hatte ich dir das letzte mal gesagt, dass du die drawcalls weglassen sollst und nur den rest testen solltest, dann haettest du das gleich herausgefunden.

effects sind nunmal sehr langsam, das setzt man eher auch einfachheit ein (du kennst ja die mentalitaet, ist die software zu langsam, besorg sich der user halt ne neue hardware, 2GB fuer word ist doch nicht zuviel verlangt )

du kannst ins effect framework einen callback einhaengen und das groebste an performance loss wegen states selbst herausfiltern, wenn ich mal richtig gelesen hatte.