Original Post
(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
)
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