Skip to main content
GameDev.net gamedev.net
🔒 Locked

Rendering changing vertices

Started by v0dKA Jan 22, 2006 at 7:17 PM 1 replies 600+ views
Original Post
v0dKA
v0dKA
I'm making a simple top-down car game (think GTA 2). I want to add turning tires to my cars - that is, if the player turns left, he would see the tires rotate to the left from underneath the car. To accomplish this, I was advised to manually calculate the vertices of the rotated tire myself instead of recalculating the world matrix for every tire of every car. This means the following method, though the simplest, is not the most ideal: Method #1 Vertex buffers: 1 for car, 1 for single tire, both static Textures: 1 for car, 1 for single tire Rendering: calculate world matrix for tire #1; render tire #1; recalculate world matrix for tire #2 (same rotation, but translated to the other side of the car); render tire #2; calculate world matrix for car; render car. I suspect that I will need to use a dynamic vertex buffer, correct? Would the following be better? Method #2 Vertex buffers: 1 static buffer for car, 1 dynamic buffer for 2 tires Textures: 1 for car, 1 for single tire Rendering: calculate vertices of both tires and write them to the dynamic buffer every frame, then render the tires; for car, same as method 1: calculate world matrix for car and render However, it seems a bit overkill to use a dynamic vertex buffer for tires -- the geometry of the tires is rather static, the only thing that changes is their rotation and position. Besides, dynamic buffers have their drawbacks, so is it even worth it to use them? I happened to fall across DrawPrimitiveUP(), which can render data that is not stored in a vertex buffer. I've never used it before, but it appears that it would be better because 1) I can recalculate the vertices as much as I need, and 2) it would eliminate the need for a dynamic buffer. Thus, Method #3 Vertex buffers: 1 static buffer for car; for the tires, simply store them as an array of vertices (with the appropriate FVF) without a vertex buffer Textures: 1 for car, 1 for tire Rendering: Recalculate the vertices of the tires per frame and store them in the array; use DrawPrimitiveUP() to render the tires; render the car as usual Would that be better than the other solutions? Besides this, should I store the tire picture and the car picture in the same image file? If so, there would be some wasted space (required to make the image square), but nevertheless, is there a performance benefit for storing multiple textures in a single file? Thanks for any help!
.:-v0d[KA]-:. <<>>
circlesoft
circlesoft
Quote:
Original post by v0dKA
I happened to fall across DrawPrimitiveUP(), which can render data that is not stored in a vertex buffer. I've never used it before, but it appears that it would be better because 1) I can recalculate the vertices as much as I need, and 2) it would eliminate the need for a dynamic buffer.

hehe...DPU() just makes you *think* you don't need a vertex buffer to render. What it does is locks an internal buffer, feeds in your data, then unlocks, and renders. Needless to say, it's horribly slow.

I believe the best approach would be to separate the tires from the rest of the car. This way, you can apply a simple rotation matrix to the tires when you render them. So this would be the psuedocode:
// Render carSetStreamSource( carBuffer );SetTransform( world, carMatrix );DrawIndexedPrimitive();// Render wheelsSetStreamSource( wheelBuffer );SetTransform( world, carMatrix * wheelRotationMatrix );DrawIndexedPrimitive();

If you want to optimize further you could actually combine them into one buffer, and just render each call with separate parts of it (using the various params of DIP). I certainly don't see the need to *manually* update the vertices - that doesn't make sense to me at all. This way requires absolutely no locking, and just 2 renders.
Nik02
Nik02
Locking vertices is always a bad idea, if you can avoid it. I agree with Dustin - use matrices to rotate the wheels.
Niko Suni

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.