[Bf-committers] point cache

[bjornmose]

Yo, Brecht a few thoughts on that ( me thunderbird has lost spell 
checking for reasons i don't know .. so have mercy )
Brecht Van Lommel schrieb:
> 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.
>   
Well, worst of all for any simulaton is a sudden change in the number of 
'free variables' ... translates to number of atomar objects to keep track.
Since soft bodies and particles 'now' keep track on more information 
than provided by the general animation system as well as they to a 
private sub frame interpolation they can (will) not handle any 
resolution changes. Possible though i don't see any benifit but 
increasing processing load.
So IMHO there need to be a well defined set of situations where to hook 
a 'physics modifier' in the stack .. once you hooked in you should not 
change the number of 'particles to watch' or their 'edge relations' ... 
tadum di dum .. a lot more to think about .. well.
On the other hand i do not see any obstacles to have a subsurf later on 
any level .. besides there might be some 'funny' results.
> - 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?
>   
Deps graph is working fine  as long as it is notified correctly ... i think.

> - 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.
>   
Well actually the way point cache is used by cloth pretends a feature 
that is NOT available
"resuming "
That would mean i could stop the cache building process at any time and 
resume lossless from there.
With the current point cache implementation that won't work.
Simpy because all solvers implemented are ODE solvers are  forward with 
initial conditions.
Since point cache does not provide any information on the current 
velocity a vertex had on break it all the systems would need to do some 
rather bad guess work to reconstruct vertex velocity. .. Just think of a 
particle with vz =1 at frame n and having vz=-1 at frame n+1 because of 
being bounced back .. what i would see from point cache is no change in 
position at all .. while the particle in fact switched diretcion ..
Janne and me did discuss that detail a bit ... well we argued on 
solutions on that .. so i think we both have something in the sleeve .. 
but the way it is, it is simply a no go.


Well i know you are clever enough to see that all that 'nice to have' 
options in cloth module need a little more work  to make 'em work in a 
sense of  'fits flawless'


> - Global control for protecting and clearing all caches, do we need this?
>   
Yes ! if you play with the system with more than one dynamic object to 
find out good settings you need to be sure all other 'players' are reset
> 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
>
>
>