Jump to content
  • Advertisement


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


Maximizing 3D API performance

This topic is 5962 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, I already know that in order to achieve optimal performance you have to: - avoid runtime memory allocation - group the rendering of subset with identical render states (i.e. textures), to minimize texture change (which is a quite slow operation) - same goes for swapping from one VB/IB to another. Now assume you''re holding your geometry in an octree, you have two choices: - The "trivial" way to do this is when you reach an octree leaf, you render all its faces, but if you have say 20 different textures in this leaf, you''ll loose a lot of time, swapping texture. - Another way would be to maintain a list of subset to be drawn for each material, so that while traversing the octree, you list what need to be drawn, and once it is done, for each material, set correct render states, then render listed subset. The problem that is arising is that allocating list nodes at run time is time consuming ... expect if you use some kind of "list node pool" (pre-allocate a predefined number of listnode before any rendering, and put them in an "unused node list"). This implementation seem right to me, but I''d like to know if someone has been experiencing with this, and what did he learn from this. Plus, I am wondering if it is best to have : - one IB/VB per octree leaf - or one for all the octree (in this case, I''m not sure about how to handle the 65535 limit for indexing) then having multiple subsets in this VB/IB - or maybe one VB/IB for each material. I know I should experiment myself, but I''m really short of time, and next week I have to show a little demo to a game company for PERHAPS being employed. thanks

Share this post

Link to post
Share on other sites
First, decide whether you want to have a prototype (a quick shot) or whether you address such an important issue in depth..

Yes, the pool idea is what most do. Typically it goes:
- you traverse your octree (or other representations) and check what has to be drawn (is in sight and is not occluded (advanced topic))
- you keep the things to draw in some kind of pool, e.g. a simple list (just the references to your data)
- if you have transparent stuff that needs to be sorted (additive blends do not), or wnat to use billboarded stuff, then you have 2 or 3 lists: solid stuff, transparent, billboarded
- now render the lists according to their needs. Take in count: transparency may need back-to-front sorting, solid things can be optimized by minimizing texture changes AND state changes. This gets more complicated for multipass scenarios.

You may want to search for keywords "shade tree" for the minimization task. The good thing is: once you have the pool(s) running with simple sorting (or none at all) the prog works, and you can spread your demos while focusing on the minimization task.

- thomas

Share this post

Link to post
Share on other sites
Actually rendering from front to back is better than sorting by textures on new NVIDIA and ATI cards.

See this thread in opengl.org:


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!