# Handling polygons in multiple nodes of an Octree

This topic is 2526 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm building a 3d software renderer for grins to learn the math and rendering concepts. I've implemented the basic drawing of polygons with some basic optimizations like back face culling and frustrum culling. Its going pretty well for it being java and all (15k polygons at 30fps at 1900x1080) but I want to implement an Octree to reduce the amount of overdraw happening and correctly sort the polygons for drawing without using a z-buffer for the entire screen.

I get the basic ideas of how to partition the world and how to traverse the tree from front to back to order the polygons correctly, but I'm a bit confused on how to handle polygons that are in more than one node of the Octree.

Some example cases I'm concerned about are:

• A floor of 2 big polygons that intersect all of the nodes at the bottom of the Octree
• A polygon that extends across a node boundary

I figure I should split the polygon at the node boundaries, but then do I need to check on each frame for objects that have moved in the world that need recalculation in the Octree.

##### Share on other sites
What I do in my (loose) octree is that I allow objects to reside not only in leaf nodes, but also on the inner nodes. If an object does not fit into a lower level, it is placed onto a higher level. The fact that it is loose enables each object to reside in some inner node completely.

##### Share on other sites
I suppose I should be looking into loose octrees as opposed to straight octrees.

So how do you order the polygons that reside in a parent node when you go to render the polygons? It seems there's still going to be ordering issues with the polygons in the parent and its child nodes. Is that where you punt and create a z-buffer for just that node in the octree and use that to order the pixels in those nodes? Seems like that wouldn't work well for really large polygons like a floor, but that could be a know limitation and the floor could be constructed of lots of smaller polygons.

##### Share on other sites
You're right, the most straightforward method would be to use a z-buffer, since octrees don't directly allow producing a depth-sorted ordering.. at least not in an elegant way like BSP-trees do. It might be possible to collect the tris inside octree nodes in an almost depth-sorted manner, then sort the individual tris manually (using a sort that is effective when the input is nearly sorted), but that could just be slower than using a z-buffer.

1. 1
2. 2
Rutin
20
3. 3
khawk
18
4. 4
A4L
14
5. 5

• 12
• 16
• 26
• 10
• 44
• ### Forum Statistics

• Total Topics
633765
• Total Posts
3013730
×