About octrees

Started by
2 comments, last by Shnoutz 21 years, 6 months ago
(this is not a question, if you think of something to say that would be constructive you are welcome to write it down ) Allo, I have finished my octree compiler. It is alright for my needs but I would like to know the opinion of other about the idea. Most of octree structure I read about are either splitting polys that are sharing node boundaries or they use loose octree and some sort of frame counter by polygons/area to make sure that the polys are not rendered twice. I think that splitting is not a good solution for most maps and the loose octree/frame counter solution would force me to use dynamic buffers wich I would like to avoid because I would need to send my polys to the video card for each pass (multipass). I came up with a solution with static index/vertex buffers. Instead of having a list of triangles by nodes I have a range of triangles in the indexbuffer by node. I sorted my indices from the lowest to the highest level so that the range of a node would encompass the ranges of all of its child. There is no framecounter and no splitting, each triangle is assignated to the smallest node possible. if the octree is fully visible it resolve to rendering it as a standard model. That way i would save bandwidth because all data would be in videocard. I can stop the octree traversal if a child has less than a specified number of polys to render. struct Node { dword texture; dword startvertex; dword numvertex; dword nodeTrisCount; // this node only primitive count dword nodeStartIndex; // this node only first index in ib dword childTrisCount; // this node and its child primitive count dword childStartIndex; // this node and its child first index }; Thank you for your comments Gab
Advertisement
"Instead of having a list of triangles by nodes I have a range of triangles in the indexbuffer by node. " -

I am not quicte sure what you mean there. The way I see it is that you are not referencing vertex buffers in the nodes, although you are referencing indices in the same nodes? (And that idea doesn''t make so much sense.)

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: http://students.washington.edu/andrey
-------Homepage: http://www.pclx.com
The idea is simply to group the triangles indices of each node in a consecutive array in the index buffer. So that when you render a node, if the node is fully visible then you render "childTrisCount" triangles from the node's startindex, else if node is not fully visible then you render "nodeTrisCount" triangles from the node's startindex and then go in the child and repeat the operation to get finer detail culling.

index buffer : iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii <- those are indices|- nodeTrisCount     -|- child         -| |- childTrisCount                      -| 



[edited by - shnoutz on September 30, 2002 7:59:03 PM]
Well this is working out well for a static scene, although not for a scene that is changing. If you have a static scene then why use oct-trees? You can probably pre-build an outside space by grouping objects into spheres or obb''s (etc) by using percise positioning and sizing of those binding volumes not having to worry about an object intersecting and get better efficiency/memory usage than oct-trees, because this way the sorting will be focused only in space where grouping is needed. Spheres would be quick and simple ehere as well.

Oct-Trees are good for dynamic scenes where objects are moving and each object is being transformed & rendered separately anyway so no batching of different objects is possible.

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: http://students.washington.edu/andrey
-------Homepage: http://www.pclx.com

This topic is closed to new replies.

Advertisement