[Bf-committers] point cache

[Janne Karhu]

I mostly agree with bjornmose,

but actually the "resuming" is working perfectly at least for particles  
although it's not specially mentioned anywhere. You can test this by  
running a particle simulation halfway and esc-ing out of the animation  
loop. Now you can see that the calculated point cache files are not  
cleared or overwritten when you start animation again and the simulation  
continues smoothly writing more cache files once there are new dynamics to  
simulate after the halfway where the calculations were cut last time.

Instead of storing just the 3d points atleast for particles the point  
cache is filled with phase space points (location & velocity) + rotation  
and angular momentum for every frame. I don't see any reason that would  
prevent softbody also including velocity data to be written to it's point  
cache, since the sb body points store the current velocity at simulation  
time.

I think what's at some places refered to as "geometry caching" is just  
pure 3d locations of vertices, but I thought that from the start "point  
cache" was intended for storing points in what ever multidimensional space  
needed by the dynamic systems.


Still on other things to do with point cache: one thing that's badly  
needed is an "automatic event driven frame advancer" a.k.a. a baking  
system :) to re-calculate the point caches for each system effected by a  
change (yes imho too the depsgraph should be able to handle this  
perfectly). Ofcourse this should be a per system option but on by default.  
This baking would hopefully get rid of the current "make a change -> go to  
frame 1 -> clear cache for all systems you think are effected by the  
change -> run simulations -> hope for the best" -monster that we've  
created.

janne


On Fri, 29 Feb 2008 02:44:05 +0200, bjornmose <bjornmose at gmx.net> wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers