Ac1DF1R3
02-10-2003, 06:01 PM
I read the other thread entitled 'Combining Octrees and BSP trees... is it possible?' and from what Yann said - Octrees are the way to go instead of BSP. They seem easier to implement (which is good for a relative beginner like me) and can handle dynamic objects.
So I hope to use Octrees in my scene/demo. However I have a few questions regarding the optimum way to go about them.
1) For the static data, it may contain different objects within the same leaf, and they may have different material properties. I read somewhere in this forum, that vertex arrays could be contained within the leaf for quick(er) rendering, but I guess different materials/textures sort of makes that awkward as you can't have one array. Am I right about that?
2) For static objects, is it always best to split polygons that cross the partioning planes of nodes (e.g. an object that can be contained in 2+ different nodes at the same time)? Or is it best to just store duplicates of the actual object.
Now for dynamic objects, where my main confusion lies...
3) When I create my initial octree from the static geometry, some octree nodes may be completely empty at a high level, so it may not be partitioned to the full depth/level. But when dealing with dynamic objects (e.g. particle system) hundreds of dynamic objects may enter that empty node, so surely it would be an advantage to partition that node to the full level anyway, even if empty? So that when dynamic objects do move into that empty space they can be put in smaller nodes immediately?
4) Overall, isn't sorting and actually moving dynamic objects from node to node a slow process? Especially in a particle system? Are there any optimisations?
Perhaps if I ask more questions this could become one of those good reference threads
P.S. For collision detection, I'll either use a completely separate octree (with less polygons/convex hulls for faster collision detection) or just add the collision objects to the same octree but with separate pointers and perform collision detection on them. Oh, and this is in OpenGL if that helps with the rendering questions (vertex arrays etc..)
So I hope to use Octrees in my scene/demo. However I have a few questions regarding the optimum way to go about them.
1) For the static data, it may contain different objects within the same leaf, and they may have different material properties. I read somewhere in this forum, that vertex arrays could be contained within the leaf for quick(er) rendering, but I guess different materials/textures sort of makes that awkward as you can't have one array. Am I right about that?
2) For static objects, is it always best to split polygons that cross the partioning planes of nodes (e.g. an object that can be contained in 2+ different nodes at the same time)? Or is it best to just store duplicates of the actual object.
Now for dynamic objects, where my main confusion lies...
3) When I create my initial octree from the static geometry, some octree nodes may be completely empty at a high level, so it may not be partitioned to the full depth/level. But when dealing with dynamic objects (e.g. particle system) hundreds of dynamic objects may enter that empty node, so surely it would be an advantage to partition that node to the full level anyway, even if empty? So that when dynamic objects do move into that empty space they can be put in smaller nodes immediately?
4) Overall, isn't sorting and actually moving dynamic objects from node to node a slow process? Especially in a particle system? Are there any optimisations?
Perhaps if I ask more questions this could become one of those good reference threads
P.S. For collision detection, I'll either use a completely separate octree (with less polygons/convex hulls for faster collision detection) or just add the collision objects to the same octree but with separate pointers and perform collision detection on them. Oh, and this is in OpenGL if that helps with the rendering questions (vertex arrays etc..)