Vertexbuffer und Wellen
-
Hmm, Wellen könnte man doch auch mit einem statischen VB + passendem IB und einigen Tranformationsmatrizen hinbekommen. (Behaupte ich jetzt einfach mal so)
-
was ist dein problem?
ich glaube schon das das mit den vertexbuffern allgemein so ist. bei mir ist es jedenfalls so (->gf4 ti4600). ich habe mehere tage lang die unterschiedlichsten geschwindigkeits-test mit verschiedenen größen, flags, ... etc. gemacht und habe festgestellt, das kleine vertexbuffer mit DrawPrimitveUP schneller gezeichnet werden als mit einem "richtigen directx-vertexbuffer-objekt". vorallem bei hardwarevertexprocessing!
oder gefällt dir meine schreibweise nicht ? hätte ich schreiben sollen:
directx-vertexbuffer müsen nicht statisch sein. man sollte sie immer verwenden wo es nur geht. ausser bei ganz kleinen vertexbuffern (ca. vertexanzahl<100), hier ist eine DrawPrimitiveUP-variante mit user-defined-vertexbuffer (für directx'ler) schneller.
[ Dieser Beitrag wurde am 10.07.2003 um 12:58 Uhr von KXII editiert. ]
-
Original erstellt von <TGGC>:
Hmm, Wellen könnte man doch auch mit einem statischen VB + passendem IB und einigen Tranformationsmatrizen hinbekommen. (Behaupte ich jetzt einfach mal so)Und wie soll das gehen? Denkst Du da an so eine Art Geometry-Blending? Da müsste man ja immer noch die Blend-Weights im VB verändern.
-
Nein ich denke daran, das man z.b. einen VB mit einer Periode Sinuswelle füllt, diese dann mehrmals hintereinander rendert (per Transformationsmatrix verschieben). Zur Animation gibt man in die Transformationsmatrix dann noch einen Offset hinein. Also 'ne ganz simple Methode, die auch eine V1 kann.
-
Ja, das geht! Wenn man nicht irgendwelche Besonderheiten will.
-
Original erstellt von TomasRiker:
Ja, das geht!Sonst wüde ich's nicht behaupten.
-
Ist ja schon gut.
Warum postest Du immer unregistriert?
-
Original erstellt von TomasRiker:
Warum postest Du immer unregistriert?Um auf den Misstand aufmerksam machen
-
Original erstellt von KXII:
stattdessen sollte man D3DPOOL_SYSTEMMEM verwenden. bei managed dauert das locken/unlocken bei hardwarevertexprocessing extrem lange.wenn ich mal ATI paper zitieren darf:
"Dynamic vertex and index buffers always have to be created in D3DPOOL_DEFAULT memory pool. If they are allocated in D3DPOOL_MANAGED memory pool, two copies of the buffers will be maintained - one in the system memory and another in D3DPOOL_DEFAULT pool. Whenever a managed buffer is locked and writen to, the application gets a pointer to system memory copy, which ist copied to D3DPOOL_DEFAULT pool buffer instance once the buffer is unlocked"das heißt, wenn man managed buffers nutzt, hat man auch immer auch einen SYSTEMMEM buffer der rüber kopiert wird. das locken,schreiben ist genauso schnell wie beim "pure-system" buffer. SYSTEMMEM wird erst beim rendern in die GRAKA kopiert und MANAGED gleich nach dem unlock, was aber in der gleichen performance resultieren sollte, falls man jedes frame lockt, falls nicht müßte managed schneller sein. aber wie die ATI paper sagen, sollte man DEFAULT verwenden, dann schreibt man direkt in die GRAKA, falls gewisse AGP optionen aktiviert sind, schreibt man da vielleicht mit der vollen AGP geschwindigkeit hin und das wird dann wohl am performantesten.
das steht jedenfalls in der d3d doku, in ati und nvidia papern.aber am schnellsten wäre sowas natürlich ohne locken, wenn man im Vertexshader FFT machen würde, dazu gab es sogar ma bei nvidia ne demo mit source wenn ich mich richtig erinnere.
rapso->greets();
-
Original erstellt von <rapso>:
wenn ich mal ATI paper zitieren darf:Vielleicht hat er es mit nvidia probiert. Könnte sein, das solche Sachen treiberabhängig sind. Evtl. so stark, das gleiche Karte andere Treiber schon einen Unterschied macht.
-
Original erstellt von <rapso>:
**
das steht jedenfalls in der d3d doku, in ati und nvidia papern.**