[Bf-committers] point cache

Fri Feb 29 07:56:23 CET 2008

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).

Joe

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