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