Vertex-buffers question..

Started by
4 comments, last by simon_brown75 23 years, 6 months ago
Hi, I''m writing a racing game in D3D IM and I was thinking of converting it to use vertex-buffers instead of DrawPrimitives. My question is this - I read in the SDK that when using un-transformed vertices, using vertex-buffers is ''unlikely to be faster than using DrawPrimitives''. First of all, is this the case, and if there *is* a speed increase in this case, how much are we talking about? It says in the SDK that the advantage of using vertex-buffers is that ''static'' geometry doesn''t have to be transformed every frame, since the transformed vertices stay in the destination vertex-buffer. This confused me though, because what does it mean by static geometry? In my racing game, obviously the track never moves, but every time the camera rotates or moves, the track polygons still have to be re-transformed. Therefore geometry can only be ''static'' if *neither* the camera or the object moves, and surely this is rarely the case in any sort of game. In which case what is the point of ever using vertex buffers? They would only be faster when both the camera and the objects were stationary. Can someone shed some light on this for me. I''ve also read that vertex-buffer will help to get the maximum performance from any Hardware TnL capability, and at the moment using DrawPrimitives is only around 10% faster with Hardware TnL on a GeForce 2 GTS (although these figures do not necessarily mean much with a low polygon count of 4000). This contrasts with a story a friend told me, that his 3d engine can shift 8 million polygons per second on a GF2 with h/w TnL, but only 2 million when h/w TnL is switched off. Basically I want to know whether to switch to vertex-buffer and how to get the best out of h/w TnL. Thanks in advanced, Simon Brown. (sorry about the long post )
Advertisement
Im only just beginning so maybe im talking rubbish, but anyway.

As far as I understand, using vertex buffers doesnt mean not using draw primitive - you still have to use DrawPrimitiveVB, right.
And the static geometry, i dont know but id guess its geometry thats static in world space, although obviously it wont be static in view/camera space.

Cameron
Well, I''m not the VB expert, and I''m not going to shed much light on the subject, but I will say that shifting to VB is an easy change. So if reworking code is worrying you, you really shouldn''t have to rework that much.

Now, from what I''ve read in a limited amount, D3D is supposed to be able to optimize VB more than regular drawprimitive calls and that is the main advantage. I believe it figures out where to store that vertex information.

Also I seem to remember in the back of my skull, that with VB you can just transform the vertices and then use those to do texture passing? Or some other operations. So if you look at the pipeline, you can tell it I believe is called like ProcessVertices or something, and that will do the transformation, and then you can do a bunch of operations on top of those vertices again and again without redoing the transformation step.

So there are advantages, and it''s an easy change.
Thanks for those replies

Yep, I read the whole vertex-buffers section in the SDK and it seems straight-forward. I just want to know I''m going to gain something for the effort.

So, if I understand correctly, I should get some kind of performance increase because the vertices are located in video-card memory, which obviously means faster access for the GF2''s h/w TnL.

That explains why vertex-buffers are recommended for TnL devices.

I think the multi-texturing case would only apply for multi-pass multi-texturing, where you are rendering multiple copies of polys. Presumably for single-pass multi-texturing D3D only needs transform the vertices once (although that''s just a guess ).

Anyway, I now understand why VB''s are worthwhile, thanks.
Remember that ProcessVertices doesn''t use a cards TnL abilities.
Thanks for that. I shouldn''t need ProcessVertices since I don''t need to access the transformed vertices.

This topic is closed to new replies.

Advertisement