Advertisement Jump to content


This topic is now archived and is closed to further replies.


Loose Octree: What's the point?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Howdy, I'm trying to compare different types of octrees. Right now these are the ones i've highlighted: AABB: Standard, most well known octree (main 3 axises) AOBB: (Adaptive Object Bounding Box)Resize your octree node to encompase an object that is "More" in it, than the other node the object shares, and then trim it's dimentions to fit tightly around it's objects Conforms to the main 3 axises KD: Steps Away from the AABB, by allowing off scale resizing of the octree nodes. It's like an AOBB tree, however, it calculates the dimentions of the tree while creating, rather than resizing the tree after creation. Still conforms to the main 3 axises BSP: Same concept as a KD tree, however, allows you to create "obtuse" (convex?) bounding nodes. (Not always a good thing) I've been looking over Loose octrees, and it seems like there's really not "good" reason to choose it. It boasts allowing quick insertion/deletion/movement from the scene, but other than that, it seems pretty pointless. Is their any reason why i would presue it past a standard AABB tree? And does anyone know of a better reference to the process than from Thatcher Ulrich? (tutorial or indepth evaluation?) thanks. ~Main [edited by - duhroach on December 2, 2002 9:57:57 PM]

Share this post

Link to post
Share on other sites
Like you said, it allows quick insertion/deletion/movement of objects. This makes it a lot better for scenes with very large numbers of dynamic objects than normal octrees.

So a place where you might use a loose octree over a standard AABB tree would be if all of your objects were moving around all the time, and you had hundreds of them.


Share this post

Link to post
Share on other sites
The biggest reason to use a loose octree is it solves the problems you have when you get bunching of objects around the boundaries between nodes.
If I have a top level 0, which has 8 level 1 children (standard octree), and a very small object is stradling two children I''ve got two choices:
1. Put it in the level 0 node (eek - now all intersections will end checking against it).
2. Put it in both children (same kind problem as above only now it''s in two places). I can offset this by subdividing the two children until putting in both isn''t such a big deal, but now I''ve got a needlessly deep octree - with will effect other searches badly.

Looses octree solves this, for a little extra cost when inserting and testing (not much through) and help to balance your spartial queries.


Share this post

Link to post
Share on other sites
Ok, so besides the case of a dynamic scene with lots of moving objects, it''s pretty pointless to look at.

The method i use to solve the object spanning nodees problem, is that I split the polygons and seperate the object. Most of my scenes are extreamly static in nature, so splitting objects up is the best option for me. Creates a little bit more to the poly count, but nothing to high (any polygon split only results in 3 new polygons)

thanks for the input though, very helpful!!!


Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!