[ODE] Scene Managenment / Partitioning

[Rodrigo Hernandez]

It was my perception that you could create multiple spaces (one per 
Octree Node/Quadtree Node/KDTree Node/Portal) and assign bodies to each 
such that you could enable them or disable them all at once based on 
proximity/culling queries, what partition strategy you use is up to you.

Visibility has nothing to do with physics though, if someone drops a 
ball behind me, it will not stay frozen in midair just because I can't 
see it, if a body is in movement, it should keep updating itself until 
it comes to rest, so, there is no reason for ODE to have any visibility 
code whatsoever, that you have to code by yourself.

Cheers!

Rodrigo Luque wrote:

>Hi!
>
>    I noticed that others collision packages have some sort of scene managenment integrated. I think there is no problem to implement something like this, but there are some issues.
>    First, ODE has a built-in partitioning algorithm (quadtree, hash-space...) that cannot be properly used outside (lack of interface). It's difficult to use hash-space for something like this, but a quadtree is easy because bodies are indexed by quadtree nodes that represent a portion of the space. So, I just need to disable bodies inside nodes that are away from the observer and wake-up bodies that are close. However, there is no C interface to retrieve nodes in quadtree.
>    Second, for visibility queries it's not possible to use the quadtree or any other partitioning structure in ODE because of the lack of interfaces. There is a way to use a geom object to make the visibility test by checking 
>all the geoms that are intersecting it, but there is no convex geom to represent a view frustrum and trimesh it's not good enough to do this (it's not considered a volume, only a triangle soup).
>    In order to solve these problems, I implemented my own partitioner outside. However, to keep it up-to-date, I need to check all bodies after every simulation call. I know that ODE has a dirty flag that is used to update partitioner only if it's necessary, but I can't use this flag outside. Moreover, I am wasting time because ODE already visits all bodies in dWorldSimulation and I am visiting again. Also imagine a situation that I need to make sure that all bodies are OK, I mean not in dInfinity, NAND or something like this or I want to implement a linear / angular velocity limit. I will probably need to check all bodies after the simulation step to make sure that everything is ok. This shows I am doing redundant tasks by visiting all bodies more then once.
>    Actually, I have one idea to solve this problem. We can add a simulation callback to ODE. So, everytime that a body is simulated, this callback is called and the body is passed through a parameter. So, we can retrieve application data by using body user data and modify the body's property or update application's objects in dBodySimulation call. This is much more efficient than visiting all bodies again.
>
>    Well, it's a suggestion. Maybe I am missing something...
>
>    Thanks you all in advance.
>
>
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode
>
>  
>