Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

thona

(Advanced) How many different FvF's in a 3d engine?

This topic is 5893 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, according to my information switching vertex buffers is expensive - especially when different formats get involved. I am in the middle of starting (nice, eh) a 3d engine and am thinking now on how to handle this. My options are: (a) have a small number of defined FvF''s that get used by the engine, and actually organise rendering by FvF - I indend to use dynami buffers extremely extensive (to prevent stalls), btw. (b) have a number of differen but non overlapping (!) FvF''s that get mixed into the final format using different Streams. I would order the rendering by stream, too (like (a)), but have one FvF for 3d coordinates, one for textures etc. What is the optimal way t o handle this? For sure not every "part renderer" is needing all potential FvF information - so how do you guys handle this for optimum performance? Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
Advertisement
Your basically saying the same thing in both options.

Either way you come down to a set number of FVFs for your engine. Just determine then ahead of time and you''ll be fine. The only place I might put flexibility into it would be in the number of textures. Otherwise you pretty much know what type of data your going to be rendering. Determine it ahead of time, tell your artists to constrain to it, and your done.

Headaches are what make programming hard. ;-)

Share this post


Link to post
Share on other sites
I realised that, too - it basically is a switch.

Now, how do you handle the problem with textures? Ok, all tris willl have at least one texture (or the engine is basically gourard shaded). But how to do the rest?

What is the best aproaach?


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
I actually just create one VB per FVF, including one for each number of textures. I usually only have four or five different types of VBs total. The less the better, so try to make decisions to effect that.

I have an idea now that I think about it. I''m not sure if you want to try this right now but it would bee interesting to see what happens.

Setup one VB for dual textures and VB or three textures. If you only need to render one texture, just set the second and/or third textures to null.

Lets say most of your objects are dual texture with just a few single texture objects. Make just dual texture VBs and have all objects use dual texture vertices, just zero out the second set of UVs if the object only has one texture. When you go to render, your render primitive can set the second texture channel to NULL so it''s not used. The renderer will think it''s rendering dual texture objects but the second texture is null and not rendered.

This will probably blow something up, although it would be interesting to try.

Share this post


Link to post
Share on other sites
Well, I posted this on a not public newsgroup and Philip Taylor from Microsoft actually gave me a very interesting advice:
quote:

the issue with texture coordinates, thats the entire reason
streams were introduced in DX 8. with streams, you can have
position and color in one stream, texcoord1 in a 2nd stream,
and texcoord2 in a 3rd. you only need map the 2nd and 3rd
stream when you are doing texturing, or multi-texturing.
this avoids keeping extra data in the vertex struct, or
duplicating data. we have been giving this advise since
pre-DX 8 days in 2000. nothing new here, (cut for NDA)



This basically means: do NOT use different FvF''s, but use "complimentary" FvF''s. In your case:

One for xyz, color, one for maybe texture 1, one for texture 2, one then one for texture 3 - that way you have one structure in your code and can basically ad/remove streams. Keeps the engine design coherent.


In your suggestion this would be FvF 1: xyz, FvF 2: Texture 1,2, FvF 3: Texture 3,4.

I will continue thinking alonw this way :-)


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
thona gave some excellent advice.

I can't recommend using FVFs with unused parts, as you're just wasting bandwidth sending the stuff to the card. This is an extremely important issue with dynamic buffers especially. Try to use static vertex buffers as much as you possibly can, and keep the total amount of data to a minimum.

Edit:
Another thing. Often, you don't even need to modify all of the vertex data, just texture coordinates, for example. This is another point where streams are priceless.

- JQ
Full Speed Games. Coming soon.

[edited by - JonnyQuest on August 29, 2002 8:29:35 AM]

Share this post


Link to post
Share on other sites
Static buffers?

How?

I mean, buffer switches are expensive, and you can hardly have a ton of small vertex buffers for the objects, or?


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
Just put them all in the same one. I doubt that you''re using fundamentally different vertex formats for each object. You have, what, position, normal, texture 0 to texture n or instead of the normal, diffuse and/or specular component - and you won''t usually be varying those between models a lot. If you have more than one or two textures (remember, only GeForce 3+, Radeon 8500+, and matrox parhelia actually support more than 3 textures, and Radeon+ supports 3, all others, including the wildly popular GeForce2 support only two textures anyway) the additional textures are usually dynamically applied anyway, which makes them ideal for an additional dynamic stream or so.

- JQ
Full Speed Games. Coming soon.

Share this post


Link to post
Share on other sites
Ok, putting them all in the same one. Now,

(a) how do I handle world transformations for them? Lets say I have terrain, and an object is a tree. I have 150 of these trees (in a small area, so no culling), but they are turned and on different positions. Do I make the transformations manually to put them into one static VB?
(b) How doI handle this if I have to cull objects? Becaue the player is in a forest of 4000 trees - and I surely dont want to render them all. Just create hundred patches?

I heard as advice to use dynamic VB''s. Now you advice to use static ones.


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
quote:
Original post by thona
Ok, putting them all in the same one. Now,

(a) how do I handle world transformations for them? Lets say I have terrain, and an object is a tree. I have 150 of these trees (in a small area, so no culling), but they are turned and on different positions. Do I make the transformations manually to put them into one static VB?


Er, no. Just take that tree and render it 150 times using different world matrices.

quote:
(b) How doI handle this if I have to cull objects? Becaue the player is in a forest of 4000 trees - and I surely dont want to render them all. Just create hundred patches?


Culling has nothing to do with vertex buffers. That should happen in your application''s pipeline (scene graph).
One way to do this is with trees (octrees, quadtrees) - but there are others as well. See 100s of articles on this site about culling.

quote:

I heard as advice to use dynamic VB''s.


You''re obviously using the wrong sources. Both the Radeon SDK and the nVidia SDK plus the respective documents say, in just about every second sentence, that static vertex buffers are much, MUCH faster. (for obvious reasons - you don''t send megabytes of data to the graphics card 1000s of times per second)

- JQ
Full Speed Games. Coming soon.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!