Re: [Bf-committers] FM 2.8 Proposal : Fracturing, Cache, Rigidbody

2018-06-12 Thread dr . Sybren A . Stüvel
This is a response to https://lists.blender.org/pipermail/bf-committers/2018-February/049157.html (I removed it from my mail server, so I can't hit 'reply' directly) On 26-02-2018 22:54, Brecht van Lommel wrote: > Thanks for the explanation. Overall I agree with the approach. > > It would be

Re: [Bf-committers] FM 2.8 Proposal : Fracturing, Cache, Rigidbody

2018-06-12 Thread Jacob Merrill
what about caching a volume ? use round / position to get the volume adress that ownes the thing this way we have a fixed size array of lists of chunks each space ownes? On Tue, Jun 12, 2018, 10:29 AM Brecht Van Lommel wrote: > For baking we normally simulate all frames, and even when we

Re: [Bf-committers] FM 2.8 Proposal : Fracturing, Cache, Rigidbody

2018-06-12 Thread Brecht Van Lommel
For baking we normally simulate all frames, and even when we don't the cost of merging two Alembic files is probably acceptable. However for caching while doing animation playback this is not the case. We can simulate some frames, play back the frames simulated so far, and then continue simulating