RenderQueue and matrix stack

The way I''ve done it in my engine is that when I transverse the scene graph I use the OpenGL matrix stack, then when sumbitting a geometry chunk from the scene tree it grabs the top of the modelview matrix stack and that gets stored, so when it gets round to rendering it, I do glPushMatrix( ), glMulMatrix( ), draw stuff glPopMatrix( ).

To make my matrices work with both D3D and OpenGL, I only have one matrix set at a time; each object (frame, actually) has its own absolute world matrix, which is pushed during rendering, then popped when the object is done.

During each update, the local matrix is completely updated, then concatenated with the object''s parent''s matrix.

quote:

---

Original post by Monder
The way I''ve done it in my engine is that when I transverse the scene graph I use the OpenGL matrix stack, then when sumbitting a geometry chunk from the scene tree it grabs the top of the modelview matrix stack and that gets stored, so when it gets round to rendering it, I do glPushMatrix( ), glMulMatrix( ), draw stuff glPopMatrix( ).

---

Do you have a render queue that sorts the geometry chucks by render state?

LizardCPP

Well everything gets added to a render queue, they don''t actually get sorted by state yet, but when I get round to coding it they will do.

quote:

---

Original post by LizardCPP
Do I have send the world matrix of every object I wan''t to render and do:

glLoadIdentity();
glMultMatrix(objectsWorldMatrix);
render object

---

You should be using glLoadMatrix(objectsWorldMatrix) instead of the two calls.

I think that the best way to handle the problem is just do the matrix concatenation yourself, either by CPU or you can precompute them using openGL and retrieve the combined matrix from openGL.
I think that you need to forget about using push/pop on objects if you sort them by state - the reason being that the matrix loading isn''t going to be your bottleneck - its more likely that a per-fragment texture op or fillrate will be your bottleneck. The advantages of using the matrix stack are nice if you use a traditional scenegraph, but when you start having to sort to take into account textures, pixel/vertex shaders then the matrix stack is unfortunately something you need to drop. Of course you could still group some of the geometry into ''matrix groups'' and render them using a special path which takes the heirarchy into account. This would only be useful if the objects you are rendering are dynamic(otherwise you may as well just precompute the matrix) and
use the same material to be rendered with(or uses relatively inexpensive state changes).

Well the method I use allows me to do a traditional scenegraph with a heirachy of transformations, but then I can render the objects in any order I want.

quote:

---

Original post by Monder
Well the method I use allows me to do a traditional scenegraph with a heirachy of transformations, but then I can render the objects in any order I want.

---

Yes your method is the traditional way and the way the OP originally had it done, but when the state changes for each render become expensive i.e. binding multiple textures/vertex/fragment programs then you could be making a lot of redundant calls, and possibly causing the driver to page in and out of video memory the same texture multiple times during a single frame - not good for frame rate. So to sort this we traverse the tree and get a list of objects that need to be rendered, sort that list by state and then render it. The OP wanted to know whether there was a way of using the matrix stack in this kind of system, but alas, in all but a few isolated well defined cases it's simply not possible.

EDIT: after reading your post again I see how you are doing it. I mentioned in the earlier post that you might as well just store the concatenated matrix, rather than use the matrix stack. Of course you can use openGL's stack to do the computation for you to do this.

James

[edited by - jamessharpe on January 17, 2004 11:19:29 AM]