   Shrinking AABB + Frustum Culling
  I had an idea to write a scene graph where there is a root node and inside each node can have more nodes.by checking if a parent node is in the frustum, can I reduce the number of checks in the child nodes if the parent is not even intersecting the frustum.each node remembers its AABB, which is a union of all child AABB. If a child node undergo a transform, (new parent AABB) = (parent ABBB) union (child new AABB) and propogate the new parent AABB up to the root.or so i thought...Now I realize that this cannot work efficiently because the union operation only works if the new AABB is expanding. for shrinking AABB, I have to loop through ALL child nodes and child's child node and so on... it turns out that simply going through all nodes in a linear O(n) fashion is faster. But this cannot be true! What about AABB in this case am i missing out? Any ideas? Thanks in advance!   
  Looks like no one has been interested enough in my noobish question. =(I dug deeper into the forums and saw a great number of posts on ADT which (qoute one of the posts) "is basically AABB frustum culling". I will go read those in the meantime (after I get back from school). If you feel like it, please drop me some advice. thanks!   ;Quote:Original post by jakeseeI had an idea to write a scene graph where there is a root node and inside each node can have more nodes.it's a bad habbit to use a scenegraph for culling, usually some dedicated AABB tree gives far better results, ( but yeah, it's ok for some quick&dirty optimization if u don't want to spend 10times the time for the proper way. I'm lazy as that as well ;) )Quote:Now I realize that this cannot work efficiently because the union operation only works if the new AABB is expanding. for shrinking AABB, I have to loop through ALL child nodes and child's child node and so on... it turns out that simply going through all nodes in a linear O(n) fashion is faster. But this cannot be true! What about AABB in this case am i missing out? Any ideas? Thanks in advance!usually you have a hierarchy that is deeper than just one root node with all the other nodes attached, so usually there are not that many nodes attached, it's not that bad to process like maybe one node per frame to get the "perfect" hierarchy back.In normal games 99% of the objects are static, and those that aren't are usually within some very deep culling hierarchy. the amount of "suboptimal" AABBs will be quite limited and optimizing one per frame will work quite well. (you could even add those "suboptimal" ones into some "dirty" list, to really just process those that have been expanded during the last frames.I've no time to google atm, but there is quite a good paper from NVidia about AABB trees for games.