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

[Janne Karhu]

On Sun, 21 Jun 2009 15:19:44 +0300, Brecht Van Lommel <brecht at blender.org>  
wrote:

> I'm not sure I understand the exact cache logic now from looking at the
> code. Could you write it down somewhere, what the rules are? Here's the
> old rules, at least made it possible for me verify easily if some
> behavior was correct or not:
> http://wiki.blender.org/index.php/Dev:Source/Blender/Physics/Point_Cache

Sure, here's the main logic of the new system (some of this could/should  
probably be moved to the wiki):

User interface:
* Cache name (will become more usefull when multiple caches per system are  
possible)
* Bake/Free bake (calculates exact results for all particles)
* Current cache to bake (protect current cache from changes)
* Calculate to current frame (calculate exact results for current frame  
 from start of simulation)
* Cache start & end frames (for cloth and sb)
* toggle for storing cache in disk/memory (new default is memory)

Unlike the previous system, the new cache system can display outdated  
simulation when a setting is changed on a frame other than the first frame  
of simulation, so the new rules are:
* Changing a setting does not clear the cache, but flags the cache as  
outdated.
* The changes are resimulated from the last cached frame up to current  
frame in one simulation step.
* On positive frame changes the simulation is run forward with new  
settings.
* On negative frame changes the cache frames onwards from the new current  
frame get cleared because they're outdated.
* The only change that clears the cache is changing the amount of  
simulated points (particles/vertices) or changes in the structure of the  
emission/simulated mesh.
* For particles the cache start and end times are calculated automatically  
 from the particle emission start time and the minimum of "emission end  
time + max particle life" and "scene animation end frame".

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

> Also I do think that if we're going to show approximate results, it
> should be indicated in the UI. At least in the Cache panel, and perhaps
> also in the 3d view?

There should allready be a "Simulation is outdated" text shown in the  
cache panel when the simulation is outdated, but some indication in the 3d  
view could also be nice.

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

> One feature for the point cache that I would like to see is the ability
> to define the number of steps simulated. The old particle system had a
> fixed number of steps (8 or so by default I think), and in many cases
> that's sufficient, and faster and less memory hungry. The point cache
> system could support a similar option.

Yes this would be a nice option indeed, but I think a better option than a  
"fixed number of steps" would be a "maximum simulation step", which is  
usefull in the non-exact simulation too. I'll start experiments with such  
a value as soon as I have the time.

janne