[Bf-committers] point cache

Brecht Van Lommel brechtvanlommel at pandora.be
Fri Feb 29 12:35:06 CET 2008


>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  

I agree we should have a global clear, protect and bake. However, I think we could do better automatically clearing the cache on user interaction. Right now it happens very often that you need to go and clear the cache because the system was not updated when settings or an effector changed. I thought the intention of the point cache was to have this working automatic, or should we give up that idea?

Specifically this problem I mentioned hasn't been commented on as far as I know:

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

Are we missing the proper update events when effectors change, is this a limitation of the code that we can fix? There's the whole issue of setting flags on various events as Daniel mentioned. It doesn't sound like the most complicated thing to implement, but figuring out a good design for it is probably trick.

Also, is the idea of continuing simulation with the outdated state a good idea? I said keep it until you reach frame 1, but it should drop the outdated state in more cases, basically whenever you're not staying at the same frame or advancing one. At least it would allow for direct interaction with effectors.


More information about the Bf-committers mailing list