[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [21050] branches/blender2.5/blender: Pointcache refresh part 1:

[Brecht Van Lommel]

Hi Janne,

On Sun, 2009-06-21 at 18:35 +0300, Janne Karhu wrote:
> > One behavior which I find not so useful is that when you're at say frame
> > 10, and make a change, it seems it only goes back one frame and
> > simulates that? When changing the initial Normal speed for example
> > there's almost no effect now, while it will actually have a large
> > effect. Taking one big step from 1 to 10 may be more useful?
> 
> This depends on how you have cached the simulation up to frame 10. If you  
> run simulation for every frame then the last frame before changes is frame  
> 9 from which the new settings are simulated from. If on the other hand you  
> jump the simulation directly from frame 1 to 10 the changes are simulated  
>  from frame 1 with a single step to frame 10. This behavior could be  
> changed with a "max simulation step" setting for which the cache could be  
> cleared backwards and resimulated on changes.

For simple particle systems I think taking a big step from the first
frame will typically be more accurate, so I would make that the
default. 

> > About the continue physics option, that could indeed be part of the
> > cache settings. But I do think this should be a global option, setting
> > it per system is tedious. Also the options in the ctrl+B menu which are
> > also global could have buttons in the cache panel perhaps, they are a
> > bit hidden now.
> 
> The new system is kind of a hybrid between the old cache and continue  
> physics by default, so no global option is needed imho. And yes I aggree  
> there could be "cache all" etc buttons in the cache panel too.

I'm not sure they are the same thing? Continue physics will keep on
simulating when the time wraps around in animation playback, which I
don't think is the behavior you want normally.

> > I would not call "autocaching" that in the UI, an Exact/Approximate
> > toggle or so seems more clear, because a lot of what is going on is
> > already "automatic". The place to implement it, that's probably in
> > wm_event_system.c, wm_event_do_notifiers. Then all dependency graph
> > calculations are done centralized before drawing. The code there is just
> > a few lines now, but as it becomes more complicated, it probably
> > deserves its own file.
> 
> I allready had it in wm_event_system.c, but as Ton thinks that even  
> ND_FRAME handling is not done in the best possible way I thought it best  
> not to complicate things too much at this point. And yes ofcourse the  
> naming can be changed to what ever suits best.

I'm not saying it should be based on listening to ND_FRAME, the
object_handle_update code happens to be in the notifier function,
running after all updates, but it's not part of the notifier system (it
should really be a separate function).

Brecht.