[Bf-committers] point cache

[Joe Eagar]

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.

Joe

Brecht Van Lommel wrote:
> Hi,
>
> The state of the physics point cache is pretty bad at the moment. There's various issues. Part of those are bugs that need to be fixed, but a part of the problem is also that in the design some issues seem to have been overlooked or not defined well.
>
> We should solve these problems before the next release, and it's important that we agree on how to solve them. I think some problems have no ideal solution, but we should then decide that we use a solution that is not ideal, but at least decided on and documented.
>
> - Viewport/render levels: the point cache makes no distinction between viewport and render levels, and so when rendering with a different subsurf level, the point cache is reset. Also the physics modifier might have been disabled for the viewport in which case there is no data to use at all. This most obviously a problem for particles, but can affect any physics system.
> - An approach to this could be to have a separate render point cache. When rendering it would automatically simulate all previous frames. That might however be very slow. In principle you could also only do this in case it is really needed and the render mesh result is actually different from the viewport mesh. Also for renderfarms you would need a way to generate such a render point cache for all frames.
>
> - Interaction with effectors: currently it appears none of the physics systems are resetting the point cache when changing effectors. Having to resimulate from frame 1 when changing an effector is bad too, so just resetting is not a great solution either. Also to allow a kind of continuous interaction with the timeline play button turned on this needs a better solution.
> - One approach could be to invalidate the point cache, but keep simulating with the outdated results that are there, without writing to the point cache. Only when you reach frame 1 it should then start writing to the point cache again.
>
> - Dependency graph issues. I read some talk about needing a physics depgraph or some changes to the way it works anyway. But I don't know which dependency graph problems there are for point caching (just haven't looked into it deep enough probably). Anyone can explain this?
>
> - Point cache and linking: right now it will generate a point cache for every .blend an object is linked in. I think it is necessary to allow different point caches for every time it is linked in, because you want to be able to do simulation of a character interacting with it's environment. However in the old system you could use baked results from the original file, is that a feature we need to restore?
>
> - Currently cloth has a different point cache user interface and different features than particles and softbody. Autoprotect cache from frame, clear cache from next frame, ... We could make all physics system consistent here.
>
> - Global control for protecting and clearing all caches, do we need this?
>
> It would be good if other developers could comment on this and mention other issues they have. There's still enough time before the next release to get this fixed, so let's try to do it :).
>
> Brecht.
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>