[Bf-committers] point cache
joeedh at gmail.com
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).
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
> 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
> 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:
>>> 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
>> 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
>>> - 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
>> 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 :).
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers