Sign in to follow this  
PumpkinPieman

Rendering Process

Recommended Posts

I'm still pretty confused on what would render first. I'm well aware that there are different loads depending on what changes and when, but how exactly can you manage different different models while reducing the amount of texture \ buffer \ state switches you have to do? Also, is it wise to dump all of the vertices into the video card or using something like a oct-tree to only dump the ones visible in the view frustum?

Share this post


Link to post
Share on other sites
Quote:

I'm still pretty confused on what would render first.


Not sure what you mean... Transparent object should at least be rendered later, and also should they be z-sorted.

Quote:

I'm well aware that there are different loads depending on what changes and when, but how exactly can you manage different different models while reducing the amount of texture \ buffer \ state switches you have to do?


First of all, it's a good idea to sort by texture... Texture-binding is quite time-consuming, so it's good to avoid that when possible.

Quote:

Also, is it wise to dump all of the vertices into the video card or using something like a oct-tree to only dump the ones visible in the view frustum?


Yes! That's a very good idea :)
There sorting mentioned before, should only be done to objects that are actually visible.

Hope that answers your question :)

Share this post


Link to post
Share on other sites
Render polygons of like states and/or textures in groups. Usually you want to batch polygons when some feature of them constantly changing and is causing significant slowdown.

For instance, if you are getting texture thrashing, sort and render polys based on groups of textures. To further help, render those groups in reverse order on the next frame.

Often sorted groups like these will conflict with the order or other groups, like transparent polygons for instance. You just have to use some judgment when deciding what takes precedence.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
if using effects (.fx)/pixelshaders/vertexshaders, then sort by them first. IIRC, they're almost the slowest to change.

see "Accurately Profiling Direct3D API Calls" in the DXSDK 9.0c documentation. at the end of said topic, there's a table listing how much time every important operation takes.

Share this post


Link to post
Share on other sites
Quote:
Original post by lack o comments
Render polygons of like states and/or textures in groups. Usually you want to batch polygons when some feature of them constantly changing and is causing significant slowdown.

For instance, if you are getting texture thrashing, sort and render polys based on groups of textures. To further help, render those groups in reverse order on the next frame.

Often sorted groups like these will conflict with the order or other groups, like transparent polygons for instance. You just have to use some judgment when deciding what takes precedence.
But say I'm using an Oct-tree to sort static poly's, how exactly could I sort what polys belong with texture[i] that intersect with the view frustum? And if I were to do batches of poly's, how exactly could I accomplish that with an oct tree (seeing as it splits up poly's). Would it mean that I'd have to rewrite the indices each frame for all VB's(assuming each VB uses only one texture)?

Share this post


Link to post
Share on other sites

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