I don't use the matrix stack, it's quite old fashioned and meant for the fixed function pipeline; Direct3D doesn't even have one.

What you're doing at the moment is calculating each nodes world-space matrix (or aboslute matrix) each frame, in practice you only need to accumulate those matrices if a node's local matrix changes and even then you only have to start at that node since the nodes and branches above it are unaffected.

As webjeff suggests in the future you might not want to render your nodes when you traverse the scenegraph. A more optimised way of doing it is to build a list of renderable items and sort them to minimise changes of state (like textures and blending and vertex arrays), so you could end up actually rendering in a different order to the way things are found in the scene-graph.

So to sum up, the more common way is to cache a concatenated (accumulated) matrix.

Quote:Original post by dmatter
I don't use the matrix stack, it's quite old fashioned and meant for the fixed function pipeline; Direct3D doesn't even have one.

Did I miss that memo?

I can't speak for DirectX 10, but D3D9 offers the ID3DXMatrixStack. There's nothing old-fashioned about matrix-stacks. They provide a perfect structure for hierarchical construction of complex 3D scenes.

And I don't see how they are any less important in shader-driver applications. The diverging point of FFP and the shader-pipeline lies after the world-view-projection matrix has been constructed, which is the terminal point of a matrix-stack's usefulness.

Anyway, to answer the OP's question, it depends on the dynamicity of the scene. If the low-level nodes are changing frequently then a stack is ideal, but you can save yourself some CPU time by storing accumulated transformations for more static scenes. I'm not convinced that the processor time being saved here is really worth anything, as matrix-multiplication is rarely a bottleneck, but you may know something about your program that I don't. However, these two two ideas are not incompatible - which is good, 'cause most scenes have static and dynamic bits.

Memory is cheap and 4x4 matrices are pretty small, so why not store both the cumulative and non-cumulative transformations in each node. That way, you can have the luxury of choice.

Admiral

Quote:Original post by TheAdmiral

Quote:Original post by dmatter
I don't use the matrix stack, it's quite old fashioned and meant for the fixed function pipeline; Direct3D doesn't even have one.

Did I miss that memo?

I can't speak for DirectX 10, but D3D9 offers the ID3DXMatrixStack. There's nothing old-fashioned about matrix-stacks. They provide a perfect structure for hierarchical construction of complex 3D scenes.

And I don't see how they are any less important in shader-driver applications. The diverging point of FFP and the shader-pipeline lies after the world-view-projection matrix has been constructed, which is the terminal point of a matrix-stack's usefulness.

The OP is referring to the OpenGL matrix stack, it's a matrix stack held internally by the OpenGL state machine, this stack is intended for the FFP and has a limited depth also.

The ID3DXMatrixStack isn't part of the D3D core library it's part of the D3DX library written over the D3D core functionality, it's nothing special that you couldn't do yourself whereas the OpenGL matrix stack is an old part of the core library.

Quote:Original post by Fabio de T P
Hi.. thanks for answers

i have both, acummulated and local matrix, and I am using the stack

but I already coded octree and, to use it to draw (using frustrum culling and to fix up alpha blending problems) I will need to use acummulated

I just want to know what you use, because probably, if everybody make in the same way, it is because it is the good way to do this...

Well I use my own matrix stack for accumulating matrices and this is a common approach. Other people might use one that comes with their API (as described in posts above). Some people may use an existing library with (potentially very optimised) support for matrices.

Quote:well, and I would like to know some performance issue about push matrix and multiply by the local, or just load the acmumulated.. if there is some gain in performance between this operations... but i think i will make some tests to know..

Provided you don't use a very slow method to multiply matrices yourself then I doubt you'll see much of a difference. Then again it all depends, profiling really is the only way to tell. Remember though that pushing and popping matrices in OpenGL is only any good for the fixed function pipeline, thats why I wrote my own [smile]

Quote:someone said to sort to avoid context changes... this way you must use the depth test, dont you??? I said this because i thought to use octree to draw the objects in order to turn off depth test, but thinking now, avoid context changes will give me much more performance... and just draw in order the transparent objects, and juts in the end...

I suspect you mean state-changes. Minimising state changes is a good thing as it's more efficient. Depth testing is also a good idea using the depth buffer. Sorting your geometry front to back *can* lead to better performance but not generally (it quite often costs more to sort than it would have just to render as-is). Sorting your transparent objects is a good idea for correct blending.
As for context switching, it is only needed to render to different windows or pbuffers, they are expensive. If you have (good) support for FBOs then you don't need pbuffers anyway :-)