[ODE] Scene Managenment / Partitioning

[Paulo Zaffari]

Hi,

   Mr. Hernandez , although you have a point saying "visibility has nothing 
to do with physics" and suggesting Mr. Luque to "create multiple spaces" 
Luque´s e-mail is mainly not about these topics. It´s about ODE´s 
architecture and integration with other sub-systems.
    First of all, Luque wants to be able to access ODE´s space partitioning 
data (quad-tree info). Requesting interfaces for this sounds like a very 
reasonable thing to me. More then that, this would allow other systems to 
better integrate with ODE and it would also allow Luque´s visibility issue 
to be better handled by him in his app. Also, by quering this data, many 
systems could avoid creating duplicated data structures, which is something 
error-prone and ineficiente.
    In other words: exposing interfaces for ODE´s internal space 
partitioning data (its´s quad-tree at least) would allow developers to 
create better software with ODE.
    Second, Luque´s per-body simulation callback sounds like a great idea to 
me. This would allow systems to make EASY any custom processing to the 
bodies a developer might think of (such as for example adding velocity 
constraints, and numerical constraints). Moreover, this would save the need 
to ODE step over all bodies and after the APP using ODE step over the same 
bodies AGAIN.
    In other words (again): creating a simulation callback which would be 
called by every simulated body would avoid a redundant pass over bodies.

Thank you all, Paulo.

>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.