[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