Full dynamic octree, worth it ?

Started by
8 comments, last by fries 8 years, 5 months ago

Hi,

Is it worth it to have a full dynamic octree for all or stay octree for static only still nowadays the best way ?

Thanks

Advertisement

Have you looked into loose octrees? They looked pretty nice to me for moving objects.

-potential energy is easily made kinetic-

Dynamic BVH is a good option for moving objects. They can be very cheaply refit, and incrementally reoptimized.

http://www.codeproject.com/Articles/832957/Dynamic-Bounding-Volume-Hiearchy-in-Csharp

One of BVHs main advantages is that objects are listed only once, and cells overlap.. Making updates and some queries cheaper.

Octree, however, can more cheaply answer geometric neighbor queries - such as for a physics simulation.

As for whether it is "worth it", that depends on your situation. How many dynamic objects? How many queries per frame?

What kind of queries you are going to need? If you just need single query for frustum culling which is linear operation then updating octree would just be more expensive. But if you have hundreds shadow casting point lights then it would make perfect sense.

Any data structure by itself is useless. What problem are you trying to solve?

It's essentially for frustum culling because doing frustum culling of each actor and then actor components gives worse performance than render all directly.

But it can be also be the question about the generation of shadow map atlas for point light and spot light to find the 16 nearest lights, can reduce the test of distance.

For terrain rendering I actually do GPU Quad Tree doing the culling in the hull shader, in the tessellation pass.

It's essentially for frustum culling because doing frustum culling of each actor and then actor components gives worse performance than render all directly.

But it can be also be the question about the generation of shadow map atlas for point light and spot light to find the 16 nearest lights, can reduce the test of distance.

For terrain rendering I actually do GPU Quad Tree doing the culling in the hull shader, in the tessellation pass.

Updating dynamic objects to octree is not linear operation. Frustum culling is. For just sake of frustum culling using dynamic octree isn't making any sense.

I have no empirical evidence for this but if you're doing this for culling I'd use a static octree for static geometry (probably with bigger vertical nodes since there isn't much verticality in games), then a fixed grid for dynamic objects. Trying to solve it all with a single structure is hard, and probably not even the right choice.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

It's also because I have a light limit on the clustered shading and using the octree could add less test to select the N light visible near from the camera.

Apparently Humus will do an article on GPU Pro 7 about a new method for clustered shading using d3d12, but surely a max light still needed about perf and memory.

These days there are fast and simple incremental BVH update algorithms that produce trees of comparable, or better quality than the best SAH kdTrees and ocTrees. Since the update will not really be affected by static geometry, I don’t see a problem mixing static and dynamic geometry together in most cases. The other nice thing about incremental update of BVH is that you can trade update speed/time for tree quality.

http://dcgi.felk.cvut.cz/home/bittner/publications/cgf-r2.pdf

You can find a partial C++ implementation (which I will be finishing soon) that supports n-ary BVHs somewhere on my blog…

This topic is closed to new replies.

Advertisement