Sign in to follow this  

Advice request about rendering vBuffers

This topic is 4557 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

Hi guys... I am setting up a porting from an old BSP system to a more compliant DX system... I am dealing with format for vertex buffer... and I wonder... How much Gouraud Shading can impact in speed of rendering...? I mean... I have many triangles, some of them flat shaded, and some Gouraud shaded... Then, I could built 2 lists, one with vertex normals and the other no, passing them to the DX for shading/rendering with different shading states, saving memory for sure as I have no V Normals for flat polys, but having to switch shading state in btw the 2 V Buffers... The other way could be to have a single uniform VBuffer with vertex normals, setting vertices normals at same value of the plane normal for flat polys, and to pass the whole buffer for shading/redndering... this will need more memory for sure, but no status change in btw, and just a huge feed to the DX, leaving the processor free doing other... However, Gouraud shading on flat polys, how much could impact on timings, compared to shding in flat mode...? can u give me an advice/info about it...? tnx [R]ed

Share this post


Link to post
Share on other sites
On any modern GPU (probably GeForce256 onwards) things like gouraud shading are FREE. It's not even worth thinking about [smile].

Consequently your VB/state switching (if done regularly) is likely to have a lot more impact on the performance. As a general rule of thumb you should avoid resource modification, resource switching and state switching if you don't actually need it - and even then it's worth trying to minimize the number of times you do.

I don't like to post "X" is going to be faster than "Y" as it's usually a fools game without some decent profiling [wink]. Things like PIX for Windows are a big ally in answering these sorts of things.

I would try combining the vertex buffers and despatching them as one big draw call...

Which brings me on to another comment - you mention BSP systems, which from my experience tend to divide the scene up into quite a lot of sections which can be highly efficient in representing ONLY those triangles that will appear on the screen. On modern GPU's you can often get better performance by throwing a few extra triangles at it, but sending it all in one go compared with sending preceisely the correct list in several smaller draw calls.

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers

Which brings me on to another comment - you mention BSP systems, which from my experience tend to divide the scene up into quite a lot of sections which can be highly efficient in representing ONLY those triangles that will appear on the screen. On modern GPU's you can often get better performance by throwing a few extra triangles at it, but sending it all in one go compared with sending preceisely the correct list in several smaller draw calls.


Yep... Tnx jolly...
In fact is what I am doing, trying to move all BSP Trees to single huge optimized draw calls and letting backculling by DXs based on windings and not by BSP code faces normal...

tnx for advice...

[R]ed

Share this post


Link to post
Share on other sites

This topic is 4557 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this