Jump to content
  • Advertisement
Sign in to follow this  
Ahl

Tuts on organizing models before rendering?

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

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.

Thank you in advance.

Share this post


Link to post
Share on other sites
Advertisement

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.

Thank you in advance.


I'm not sure why you would need an example. If we are talking about a game, when you loading your map file, you execute your sort "routine".
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.
This page describes what I do
http://www.opengl.org/wiki/Vertex_Formats

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
I don't see anything in tr_main.c that generates the key. I could be mistaken as I'm still kind of new to C/C++ and this stuff is a little advanced for me. Can anyone point out/clarify the code for me?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!