[ODE] Scene Managenment / Partitioning

[Rodrigo Hernandez]

Well, I am still unable to see how exposing partitioning data helps 
other systems integrate better with ODE,
it is not clear to me how.

In any regards, there are things Mr Luque is overlooking, the most 
important one is the Automatic enabling and disabling feature of
ODE, documented here: http://ode.org/ode-latest-userguide.html#sec_6_5_0 
having that feature enabled and tweaking its threshold values
would do exactly what he is doing manually, without any overhead, and 
probably in a much more efficient manner.

The other thing is that by using a space per partitioning node, not only 
will objects be tested against closer objects (those inside the same space)
but also that using dSpaceGetNumGeoms and dSpaceGetGeom he can iterate 
thru the geoms contained in each space for rendering, thus,
you use a visibility query for partitioning spaces, retrieve the ODE 
space, and iterate thru the geoms for rendering. When a geom crosses a node,
it gets moved from one space to the next.

I don't see any duplication, just layers of collision detection from 
broad to narrow.

Cheers!

Paulo Zaffari wrote:

>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.
>>>      
>>>
>
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode
>
>  
>