Archived

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

extralongpants

Octree decisions

Recommended Posts

I am currently writing a simple octree for my renderer... well, at least it started out simplistic. A problem arises when deciding whether or not objects should be allowed to be dynamically removed, inserted, or replaced in the octree (My octree works on a per-triangle basis, and is only used for visibility tests). My first thought was to have each triangle as an object node that could be attached or detached from an octree node. This would ensure fast removal/insertion of objects into the octree. It would be, however, potentially very slow. Traversing the triangles of the node would take substantially longer than if those same triangles were in an array. My second thought was to have only static geometry in the octree, and just determine visibility of dynamic objects seperately, on a per-object basis. But what if I were rendering a city, with hundereds of people and cars, moving about? Visibility determination might be pretty slow, if done on a per-object basis. My last idea is to have static geometry inserted in the form of triangles, and dynamic geometry inserted as whole meshes. This way, finding the new node for a moved dynamic object should be pretty quick (only some AABB inside AABB tests). Does this seem like a feasable solution? If anyone with experience in creating flexible octrees has any ideas, or thinks I should ditch this effort entirely, please let me know. Thankyou in advance for any help. PS. I''m sorry if I can''t spell

Share this post


Link to post
Share on other sites