[Bf-committers] point cache

[Michael Fox]

On Fri, 2008-02-29 at 14:23 +0000, Brecht Van Lommel wrote:

> One of the design goals of the point cache was the user would not have to worry about it. However it appears that this approach does not extend well to more complex situations, and in trying to make it work also for complex cases some of the simplicity was sacrificed.
> 
> Auto protect from frame sort of solves part of the problem, but not fully. Perhaps we should make a clear distinction between the simple and complex cases. For example:
> 
> Simple, interactive simulation:
> - Point caches saved in .blend.
> - No user interaction needed for clearing or protecting caches. Cache can get cleared very often by physics systems, they should not be cautious about this, better clear than be out of date. Assume that's not a problem, if you want to keep your stuff use the second option.
> 
> Complex, baked simulation:
> - Point caches saved on disk.
> - Simulation must be manually baked by the user.
> - Use this option for rendering.
> 
> Then in the user interface you'd have to switch between those two modes. Not optimal, but perhaps better than the current situation?
> 
this would especially be very good, have a "save cache" button like in
scene buttons, then a new Point cache tab will appear and contains all
of the options Matt asked for, like cache path (like fluid), (i have
wrote a patch to have a file paths option for this but it seems to have
been ignored), interpolation and perhaps even level of detail options
like do you want just points saved or do you want vectors and stuff
saved as well.

this will also let the more complex user know exactly what blender is
doing with the buffers(cache).

this panel should be the same in all systems so the user doesn't have to
memorise settings for one system then memorise settings for another.

> >* At *no* point should an artist ever see data that's out of date,
> >unless the artist has specifically and explicitly asked for this (by
> >explicitly telling Blender to cache, or protect, or whatever)
> 
> This is good in principle, but it's also has some problematic consequences. It means that changing a single effector means you have to reset the whole simulation and start simulating from frame 1. One of the things that would be good to have is the ability to interact with the physics system interactively to get a feel for it's parameters and how it responds to effectors. In such a case it might be good to keep working with outdated results to some degree, but maybe that functionality should then be clearly separated somehow.
> 
> Brecht.
> 
i partially agree with Joe Eagar on this, a depsgraph would serve this
well, but as Jakha has said a modified depsgraph is need, but that's not
the main problem with this, its the fact that simulations are slow and
if you move the effector just a little bit you have to wait for ages for
a change, a less accurate but faster version of the sims is needed so we
have real-time changes and once you decided on where you want it it will
re-simulate for real
-- 
Michael Fox <mfoxdogg at gmail.com>