[Bf-committers] point cache
some Wund
bjornmose at gmx.net
Fri Feb 29 10:58:19 CET 2008
Hi all
Well since every one seems to be happy with it
i think soft bodies should be storing the whole state in phase room for every frame. Well i did not code it so i don't know how hard is to do, but if it was done right that should not be more that say 10 lines to add.
Well i don't really like it because IMHO it is waste of disk space .. as for adding the velocity vector that doubles the amount of data and for 99% of the frames that information is not needed (provided i wanted to resume at frame 100).
But may be i am too old to see that now a days hard disks have no limit.
BM
-------- Original-Nachricht --------
> Datum: Fri, 29 Feb 2008 03:26:36 +0200
> Von: "Janne Karhu" <jhkarh at utu.fi>
> An: "bf-blender developers" <bf-committers at blender.org>
> Betreff: Re: [Bf-committers] point cache
> 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
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
More information about the Bf-committers
mailing list