Rendering Process
Author
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?
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 :)
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.
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.
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.
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.
Author
Quote:Original post by lack o commentsBut say I'm using an Oct-tree to sort static poly's, how exactly could I sort what polys belong with texture 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)?
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
