Sign in to follow this  

Rendering: Limiting State Changes

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

First post of 2006, so hope you had a good christmas and a good 2006! Just a quick question regarding state changes. When rendering should my goal be to reduce the number of SetTexture calls or SetMaterial calls first and foremost. I guess what I am really asking is which is more computationally expensive (not necessarily directly, but including the knock-on effects each call has). Also if there is anything else I should bare in mind regarding the limitation of state changes during a render loop. Thanks for your time as ever, Alex.

Share this post


Link to post
Share on other sites
Hi, happy new year to you too ^^
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_Summer_04/directx/graphics/programmingguide/advancedtopics/ProfilingDirect3D.asp

Read that carefully to understand it.
To answer your question specifically, check the end of the page for a table of the average clock count per API operation.

Share this post


Link to post
Share on other sites
If you're running with Direct3D9 then you definitely want to get friendly with PIX. PIX is just awesomeness embodied in the form of software [smile]

I'd highly recommend you add in some profiling points and run a series of tests on your application to get some base-line information. Then do your optimizing. Now go back to your application and compare the two.

Comparing the call streams can reveal both performance improvements, as well as a simple count as to whether you've reduced the number of state changes. It's a great way to verify that your new algorithm(s) actually do what you intended.

hth
Jack

Share this post


Link to post
Share on other sites
Ok i read through that paper and found bits of it of interest. What i really want to know now is as follows:

(1) Is it good practise to draw subsets of different meshes together because they share the same texture/material (so you are not just drawing all the subsets of one entire mesh then moving onto the next mesh).

(2) If the above is true then obviously i'll need to have some kind of resource management (textures and materials being resources) so that i keep track of what objects are using the same textures and materials for subsets of the their meshes. Or should i approach it differently?

Thanks again,

Alex.

Share this post


Link to post
Share on other sites
Hey Jack,

Thanks for your reply. Still in the early stages of the simulation engine project which I have posted on before. Have the problem componentised and pretty much all the components designed at a high level. Started to implement a framework which the components plug into so i can be sure I have it all correct and just want to clarify what the best practise is for limiting state changes during rendering. That is pretty much all i want to know at the moment so I can make the relevant assumptions as to how i am actually going to render these scene objects (ordering). I will obviously profile as I develop and plug in each component, but for now I am just trying to work out the best practise for everything.

Alex.

Share this post


Link to post
Share on other sites
Quote:
Original post by CHTHONIC
(1) Is it good practise to draw subsets of different meshes together because they share the same texture/material (so you are not just drawing all the subsets of one entire mesh then moving onto the next mesh).
Well, that'd convert your renderstate changes into a vertex buffer change. If the vertices in your meshes are all the same format, then you can pack them together in a single vertex buffer and cut out the changes entirely - definitely a win.

Quote:
(2) If the above is true then obviously i'll need to have some kind of resource management (textures and materials being resources) so that i keep track of what objects are using the same textures and materials for subsets of the their meshes. Or should i approach it differently?


One approach you could take is to create a structure that defines "a subset" - vertex/index ranges, material and texture IDs - with meshes being defined as lists of subsets. When rendering, you'd first gather together the subset lists of all the meshes you want to render (stamping them with the particular object instance so they know where to get unique parameters like world position/orientation), then sort that list by texture/material, and then walk from start to end rendering each subset. This might also help you if you need to implement things like transparent materials; the sort function can simply push any transparent materials to the end of the list, and can try to sort subsets by depth.

Share this post


Link to post
Share on other sites
Here is a KBase article in which I flesh out the sorting of entities based on their material properties. That page uses more shader terminology than FFP terminology, so you may have to adjust it a bit. For instance, your Material would actually be a ConstantSet, since the members of Material essentialy are constants. Also, you would probably remove the Shader level, since the FFP really has no separate shaders.

You can re-order the tree so that it fits your particular application. For example, you may want to have textures under constants.

Share this post


Link to post
Share on other sites

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