In general, is this kind of frustum culling some of the fastest methods today? For comparision, we currently use bounding spheres on each scenegraph node and these are tested against the view frustum planes (so if a parent sphere that encloses any child spheres is completely visible/invisble, all children are visible/invisible, etc). If I understand the bounding volume tree method correctly then some information is pre-computed into the tree when it's generated/updated, and this helps speeding up the process per frame.
If we only want to use this for the culling (no collision detection or simulation, etc.):
- should I still use two btDbvt trees like the btDbvtBroadphase does (one for dynamic objects, the other for static ones)? I assume updating nodes in a huge tree costs more than updating a small one + two cull tests and this is the reason why we have two trees?
- what do I need to do with the btDbvt tree when changing a node's bounding box (when the object moved)? Is it enough to call btDbvt::update for that node?
- Are there any methods that should be called each frame to keep the tree up-to-date if a node was modified? (like for example btDbvt::optimizeIncremental / optimizeTopDown, etc?)
- Does it make sense to include the velocity and margin in the btDbvt::update call, or is that only useful for continuous collision detection?
Best regards,
Ola
