• 15
• 15
• 11
• 9
• 10

# Tuts on organizing models before rendering?

This topic is 2613 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I read somewhere before that a good measure towards optimal performance is to organize your models in such a way as to minimize your glEnable/glDisables/etc. So, with this in mind, I'm looking for any examples or tuts on how to go about just that.

##### Share on other sites

I read somewhere before that a good measure towards optimal performance is to organize your models in such a way as to minimize your glEnable/glDisables/etc. So, with this in mind, I'm looking for any examples or tuts on how to go about just that.

Since texture switches and shader switches are expensive, you can use these as condition for sorting. I'm not sure which one is best so I go with texture (texture on unit 0 to be exact).

Besides that, I optimize for glBindBuffer, gl*****Pointer calls.
http://www.opengl.org/wiki/Vertex_Formats

##### Share on other sites
you mean like this?

http://realtimecollisiondetection.net/blog/?p=86

gets expanded upon slightly here (you can download the code for this engine too)

http://software.intel.com/en-us/blogs/2010/11/26/nulstein-v2-plog-rendering-overview/

##### Share on other sites
I was hoping for a slightly more in depth explanation but i'll figure something out...

In terms of sorting from nearest to farthest and visa-versa I'm assuming that means in relation to the camera. So with a frequently moving camera that seems like it could get pretty expensive, especially with a scene with a lot of objects to draw.. Unless there is a better means of sorting that I'm not thinking of.

##### Share on other sites
Hi Ahl:
I think that sorting isn't going to be a bottleneck here, if you take some care:

- you can use pointers, so sorting the vector of submeshes is just pointer swapping, which is pretty fast.
- if you apply the suggestion explained in realtimecollision blog, comparing two submeshes is almost an integer comparison

EDIT: and yes, is sorting relative to the camera position

##### Share on other sites
I read the whole realtimecollision blog yesterday and I'm sure I was giving my monitor the deer-in-headlights look. Now that I've had a chance to sleep on it then read it again I understand (I think) what's going on.

Is he talking about something like the follow?
 class RenderMe // Class for object rendering info { public: int Model; // VBO pointer info float x, y, z; // x, y, z coords float ScaleX, Scaley, ScaleZ; // Scale info // Etc, etc, etc, }; // And then std::map< MyContextKey, RenderMe *> SceneObjectList; 

Every object to be drawn is inserted into the SceneObjectList map and sorted according to its key. Is that correct?

How should the key be built?

##### Share on other sites

Every object to be drawn is inserted into the SceneObjectList map and sorted according to its key. Is that correct?

How should the key be built?

That's correct, but why use a map? You don't need sorted insertions, and you aren't going to look up individual values by key. I would rather use a vector or a queue, passing a sort function to the std::sort call.

As chris ericsson mentioned in rtc blog, you have to build a key where you store render information. You can get this key shifting values from render properties. For example, each texture in OpenGL gets an ID when it's created. Also you can use hashed strings ( i do it for example with materials names). All you need to do at the end is:

 s32 materialID = subMesh->mMaterialID; s32 textureID = subMesh->mTextureID; mDrawOrder = materialID << 31 | textureID; 
This is a simple example. You have to select which values to use and what are their contraints, using only the 8 least signnificant bits frome textureID, if you'll never have more than 256 textures loaded, for example

##### Share on other sites
Juanxo pretty much covered it, I'll add a couple of thoughts.

The key is pretty simple to build (and allows for quicker sorting). A similar method to this was also used in the Quake 3 renderer btw (worth having a look at, it may take a while to grasp what's going on though. the relevant stuff is in tr_main.c)

You use a single value - either a 32 bit or 64 bit integer, depending on how much information you need to store. Quake 3 got away with 32 bits, for a modern game 64 bits may be more suitable.

Build up the key as Juanxo described by bit shifting your different values into their positions within your key. Then you can simple run a sort over it, if you're using the STL then you can use the STL sort functions. Or if you are feeling adventurous maybe you could try something like a radix sort (depending on how your key turns out, but that's going off topic a bit).

The way the sort will work is it will sort from the most significant bit to the least significant bit (obviously), so if you think about that for a moment, you can use this to prioritize the items in your key. Ericson's order is pretty good.

Then when it comes to rendering, you can do something similar to nulstein which I linked to you earlier. Simply check the current state with the state for the next key, and set the new parts of the state which are different.

##### Share on other sites
Hmmm.... Looking at Q3 source. WTB better documentation. PST.