In my current system, I have a collection of Entity objects (planets, ships, missiles, etc.). Each Entity contains one or more Geode objects. A Geode is a batch of geometry with a single texture and material. Whenever an Entity moves, I update its world transformation based on its local transformation and the transformation of its "parent" Entity (if any). Each rendered Geode uses its Entity's world transform. For rendering, I maintain a list of all visible geodes, sorted by transparency/depth, then texture, then material. Each frame, I iterate through the list of geodes and set the geode's transform and state and draw the geometry to the screen. This works great, except my Python code runs extremely slow with only about 1000 entities on the screen. The bottleneck seems to be my Matrix code. Beyond trying to use C++ to speed up that particular code, this has made me think about a fundamental design question: Is it better to sort my objects by state and perform extra matrix calculations so each geode has an absolute world transform, or should I render from a transform heirarchy (i.e. scene graph) and sort the nodes as best as I can, with the matrix heirarchy taking precedence over reducing texture/material state changes? - Mike

Generally it is better to only depth sort transparent objects. Other objects should be sorted to reduce state change in the system. The kinds of state changes you should be avoiding are these (not in any particular order, I don't know where the bottle necks are on PC, prob best to experiment so see where the bottleneck is on your system). You could also experiement with hardware instancing (though would only work on more advanced GPUs).

- SetStreamSource (I beleive this is a big hit on PC) - Render all the instances of the same geometry at once (or combine static terrain into the same vertex buffer).
- FX technique/pass begin/end - Sort by material type so only called once for each shader type.
- Set constant and render state - Sort by material so only gets called once per material.

It seems pretty unusual to have matrix multiply be the bottleneck, though you are going to taking a big hit by using an interpreted language. Generally it is a good idea to have "sync" operation that goes through your scene and sync's all the heirachies before rendering (so when you get to the rendering each object has its own correctly transformed world matrix), this would avoid having to do unnessacary matrix multiplies.

BTW I thought this was the directX forum :-) Those were the directX commands I listed, there will be equivalents in OGL.

Quote:Original post by griffin2000
Generally it is a good idea to have "sync" operation that goes through your scene and sync's all the heirachies before rendering (so when you get to the rendering each object has its own correctly transformed world matrix), this would avoid having to do unnessacary matrix multiplies.

That's what I'm doing. Each frame (prior to the rendering loop), I iterate through all Entity objects and call an Update() method. If an entities' transformation changes, its world transform and the world transform of each "child" entity is automatically updated.

The problem is that in my current setup, I have 256 star systems, each with five planets. Each planet rotates around its axis AND orbits a sun, so for each planet I'm constantly calculating two new rotation matrices and a translation matrix and multiplying them all together. I can probably improve this by multiplying the current "local" transform by a static quaternion rotation matrix, rather than re-allocating three or four Matrix objects per planet per frame. I will give that a try when I get home from work, but I'm not sure how much that will help.

Quote:Original post by griffin2000
BTW I thought this was the directX forum :-) Those were the directX commands I listed, there will be equivalents in OGL.

No problem. I spent six or seven years learning unmanaged C++ and DirectX before switching to Python and OpenGL, so I know about the functions you're talking about.

Yeah sounds like each object should have have a position vector and quaterion vector, and an LTM. During sync you just fill in the LTM from the quaternion and the position (quat->mtx equation is here http://skal.planet-d.net/demo/matrixfaq.htm#Q54), then multiply it by its parents LTM.

The other thing would be to have an LOD system so you ignore planets for suns that are far from the camera (don't update them or render them).

Still I think moving C++ for your numerically intensive operations will be a huge speed up.

I still have lingering doubts about my system, so here are a few more questions:

1) If it is more important to sort by texture/shader/material, why does OpenGL and D3D even provide a matrix stack? The only purpose of this stack seems to be iterating through a tree of parent-child entity transforms and rendering each entity's geometry batches with little or no sorting by texture/shader/material.

I could iterate through an entity tree, call the OpenGL transform functions, and use glGetFloatv() to retrieve the generated matrix for each entity. I could then use this matrix to set the current transform when I iterate through a sorted list of entities. However, a previous thread recommended against using the stack in this way. The main point was that custom matrix functions would often be faster than the OpenGL functions. I find this a little hard to believe, since I have not been able to match their performance with a Python matrix class, a C++ matrix class compiled as a Python extension, or a Pyrex matrix class.

2) The OpenGL Redbook recommends using the built-in functions rather using custom matrix logic:

Quote:Page 464:
Use specific matrix calls such as glRotate*(), glTranslate*(), and glScale*() rather than
composing your own rotation, translation, or scale matrices and calling glMultMatrix().

I want to maintain an entity transform heirarchy (i.e. scene graph), so that I can attach wheels to a car, a torch to a hand, etc. In order to accomplish this and still use the OpenGL functions, I would need to have each function traverse the tree backwards to its "topmost" parent, and then traverse back through the tree and call each entity's "UpdateTransform()" method. Would there be a benefit to this approach?

- Mike