Scenegraph vs. Statechanges [SOLVED]
Author
hi,
i'm still far from my scenegraph but one big question is spooking in my head,
probably it's something really easy but i didn't get it, yet.
sorting for state changes is quite simple, sort all objects for shader, textures, buffers... well but how could it work to use a scenegraph, iterative traversal of the nodes and still group all states together ???
if anybody can explain that to me because,
e.g.: planet system
Sun - sun shader
Planet1 - planet shader
Human1 - human shader
Planet2 - planet shader
Human2 - human shader
in the scenegraph i traverse the nodes so
Sun -> Planet1 -> Human1 ->(back to sun) -> Planet2 -> Human2
well,
if i sort for states it will look like this (hopefully)
Sun
->Planet1, Planet2
->Human1, Human2
thx in advance for your help and time,
greets
tgar
[Edited by - Thaligar on August 17, 2005 3:22:21 AM]
Author
uh,
no answer ??
ok, if anyone have got an idea, please post,
even if someone shows me that i'm completly misguided,
thx in advance,
greets
tgar
no answer ??
ok, if anyone have got an idea, please post,
even if someone shows me that i'm completly misguided,
thx in advance,
greets
tgar
Collect traversed nodes in render queue.
Afterwards sort queue as you want. (First by shader, then by texture and VB or in any other order)
Afterwards sort queue as you want. (First by shader, then by texture and VB or in any other order)
Author
well, probably i havn't got enough coffee, but what for should i then use the scenegraph, i thought i traverse the graph and render the nodes how they come,
if i push them into a queue for later sorting, why should i use a sg when i can push them directly into the queue,
please correct me where i'm wrong and open my eyes,
i wanna understand this,
thx in advance,
greets
tgar
if i push them into a queue for later sorting, why should i use a sg when i can push them directly into the queue,
please correct me where i'm wrong and open my eyes,
i wanna understand this,
thx in advance,
greets
tgar
I implemented my scenegraph strictly for representing the hierarchial scene and traversing it. I have a system that walks the hierarchy checking to see if it is in view of the camera and if so batches the entities to a render queue which later sorts and renders.
Author
you use it for frustum culling, well but i read that
it's also used for relative positioning let's say of planets
(culling makes sense to me)
but what benefits brings it to traverse the tree, adapting the rotation matrices and then push the node into the queue where you loose your actual matrix and have to recalculate it any way,
or could you push the matrix as well as the mesh, state, texture... what ever into the queue??
thx for your attendance and your time,
greets
tgar
it's also used for relative positioning let's say of planets
(culling makes sense to me)
but what benefits brings it to traverse the tree, adapting the rotation matrices and then push the node into the queue where you loose your actual matrix and have to recalculate it any way,
or could you push the matrix as well as the mesh, state, texture... what ever into the queue??
thx for your attendance and your time,
greets
tgar
Quote:Original post by Thaligar
but what benefits brings it to traverse the tree, adapting the rotation matrices and then push the node into the queue where you loose your actual matrix and have to recalculate it any way,
or could you push the matrix as well as the mesh, state, texture... what ever into the queue??
Each item in the you place in the render queue should have enough information to render the object independantly. Some of this information will come from the scenegraph, some of it will be properties associated with each object (ie. the leaf nodes encountered in the traversal of your scenegraph). From the scenegraph you'll want (at least) the geometry and the transformation. Some people also like to store render state in the scenegraph, but IMHO having a separate material system has far more benefits.
Yep, you push all the required attributes to draw your geometry into the queue.
Instead of drawing the object as soon as you hit it in a scenegraph, you store the object and all info such as matrix, shader ids, texture ids and so on in the queue. And if you then sort these based on Rendertarget, shader, texture so you can reduce the costly state changes and you could also increase the batch size.
Instead of drawing the object as soon as you hit it in a scenegraph, you store the object and all info such as matrix, shader ids, texture ids and so on in the queue. And if you then sort these based on Rendertarget, shader, texture so you can reduce the costly state changes and you could also increase the batch size.
Author
i can see a light ;)
thanks for all the replies,
and thanks for your time,
greets
tgar
thanks for all the replies,
and thanks for your time,
greets
tgar
I haven t implemented the scenegraph yet but the way I plan to do it is combining the scenegraph with a hierarchical culling system(octree/quadtree/manual PVS)
I plan to pass all the information geometry, objects and translation information ... down the octree once it reaches its geometrical location (leaf) I build up a leaf base scenegraph
I hope to reduce the scenegraph iterations that way to allow a lot more details/objects .....
Also in my engine I understand shaders as a surface description that describes what texture to apply which render path to use ....
one or two 32 bit integers will hold all the flags needed to hold all the state information and information about render paths ....
these flags will be hierarchically grouped (curved surfaces, shader x, shader y..,shadowed, .....)
the size of the leaves will be fixed(n subdivisions to get to the leaf) because I aim for a fps quake like engine mixed with outdoor capabilities with indoor and outdoor lighting, parallax mapping, bumpmapping, grass and the most complexe feature destructable walls
well not dynamically destructable, the mapper has to choose which walls can be destructed, but the amount of destruction will be enormous, the destruction will be calculated at runtime but the fps shall not suffer
I plan to pass all the information geometry, objects and translation information ... down the octree once it reaches its geometrical location (leaf) I build up a leaf base scenegraph
I hope to reduce the scenegraph iterations that way to allow a lot more details/objects .....
Also in my engine I understand shaders as a surface description that describes what texture to apply which render path to use ....
one or two 32 bit integers will hold all the flags needed to hold all the state information and information about render paths ....
these flags will be hierarchically grouped (curved surfaces, shader x, shader y..,shadowed, .....)
the size of the leaves will be fixed(n subdivisions to get to the leaf) because I aim for a fps quake like engine mixed with outdoor capabilities with indoor and outdoor lighting, parallax mapping, bumpmapping, grass and the most complexe feature destructable walls
well not dynamically destructable, the mapper has to choose which walls can be destructed, but the amount of destruction will be enormous, the destruction will be calculated at runtime but the fps shall not suffer
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
