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

[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
more frames. So that makes a single Alembic file not a great fit.

I think the main motivation to use Alembic is that the data structures are
more complicated than we had before, and our custom point cache format is
quite basic. Previously we just had to store vertex position/velocity/..
for every frame. With fracture we need to store the fractured mesh and its
topology, as well as the transforms per island. As I understand such
islands can be dynamically fractured off, so the mesh topology and active
islands can change over time. Combine that with the requirement of fast
random access for a given frame, things get quite complicated.

So I'm not sure what the right solution is to be honest. For fast random
read/write something like this could work:
* For every frame, write a point cache file in the same format we already
use. This would contain an array of island index, island transform, and any
other time varying data about active islands.
* In a separate file, store list of islands, their topology and any other
static data. When reading a frame, we'd read just the active islands. When
new islands are created during the sim, we could append to this file.

It would be better if we could a standard file format though, but which
ones support appending? Alternatively we could just say, fracture modifiers
is not something that works realtime anyway, so if we have to accept the
overhead of rewriting the same Alembic file many times it might not be that
bad.


On Tue, Jun 12, 2018 at 6:00 PM dr. Sybren A. Stüvel <sybren at stuvel.eu>
wrote:

> 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 very helpful if this kind of functionality was submitted for
> > review and integration in smaller parts. For example:
> > [...]
> > * Add Alembic support to point caches for physics systems. (could even
> > replace custom point cache format)
>
> Alembic is stricly a write-once file format [1]. This means that we
> cannot update a part of a file; say the file contains frame range 1-250,
> we won't be able to re-simulate frames 150-250 and update the file for
> that. It can only be "updated" by reading the old file, updating its
> contents where necessary, and writing to another file. Furthermore, an
> Alembic file cannot be read until it is properly written *and closed*.
>
> With this info about Alembic, what do you think about using Alembic
> files for such caches? I'm not yet all that familiar with the current
> physics caching system, but I do know it creates a file for every frame,
> making it trivial to update frames. Is this actually used, though? Or
> are we always sequentially writing to the cache?
>
> We could work around these limitations of Alembic by writing continuous
> frame sequences to a single file (so if you simulate 1-100 and then
> press ESC, it would write to sim-001-100.abc), which can then be read
> when replaying those frames. Simulating other ranges would then save to
> other Alembic files (e.g. sim-101-140.abc). This could potentially
> produce many small files, though, or cause problems where objects exists
> in one file but not the other. Then again, we could have code to merge
> sequences of Alembic files.
>
> If not Alembic, what would be a good cache file format? Ideally I'd like
> to use something that's already proven technology, rather than thinking
> up something ourselves.
>
> [1]
> https://groups.google.com/d/msg/alembic-discussion/X-2ue86pw5g/Z2fZpW1eAgAJ
>
>
> --
> Sybren A. Stüvel
>
> https://stuvelfoto.nl/
> https://stuvel.eu/
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>