[Bf-committers] point cache

Brecht Van Lommel brechtvanlommel at pandora.be
Fri Feb 29 11:50:32 CET 2008


I don't think that is an important issue at this point, we have bigger problems to solve. It could be a nice optimization to only update physics systems when a colliding object gets near them, but it's only an optimization, and a difficult one since it's hard to predict all the indirect effects that changing an object might have on the physics systems.


>I don't believe the current depsgraph will necessarily work very well 
>here.  For one thing, it's not designed for persistent data (at least as 
>far as I can tell), and is also run on user transforms (if a user moves 
>an animated object but ultimately decides not to insert a new keyframe, 
>then they'd be no point resetting the caches.  on the other hand, if the 
>object isn't animated then of course they should be cleared).

>My idea for a physics depsgraph basically was in two parts.  The first 
>one is a system to detect is the bounding boxes of two objects get close 
>to each other.  This would then be used by a dependency graph based on 
>updates to animation data, not transformations.   The idea is graph 
>updates would happen when users change animation keys, not per-frame or 
>per-view3d-drawcycle during transform.
>So, for example, you might have an animated effector that moves along.  
>The physic depsgraph system would report to the relevant physics code 
>when the effector is close to another physics-enabled object.  Point 
>caches would then be updated.  Then, if the user changes the animation 
>path of the effector the physics graph would send the appropriate 
>events, add or remove edges as necessary, etc.

More information about the Bf-committers mailing list