Sign in to follow this  

Doubt on drawing the scene, accumulated or local matrix??

This topic is 3734 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 am using Scene Graph to organize my scene. To draw the scene, I use the matrix stack from opengl and for each node, I put the local matrix on stack and pop it when the node finishs to draw its sons. I would like to know if you use the matrix stack or just load the accumulatted matrix for each node, and why? I will probably change and use the acummulated matrix, but I would like to know what method is more commmon used and why.. thanks in advanced

Share this post


Link to post
Share on other sites
Fabio:

I can only speek for myself, but I like the pre-calculated matricies better only because you don't need to update them unless the objects actually move. This also gives you the flexibility in that you don't need to draw your objects in the same order as a matrix stack (though, you could have two stages, one which concatenates all the matricies using a matrix stack or update them immediately, then proceed to rendering in a more optimized way).

Jeff.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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, 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..

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...

well, I think I will do this! thanks again

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites

This topic is 3734 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this