[Bf-committers] Requirements list for the Fracture Modifier in Blender

[Martin Felke]

Yes, in theory each face could have a custom data layer with a simple
integer index which denotes to which island a face could belong. This
way you could access the faces and verts per island index and build the
shard and mesh island structures as runtime structures at file load,
instead of storing them in the blend as it currently happens (to cache
the fracture result in the modifier)
For this purpose you need to keep a "copy" of the shattered mesh as
regular mesh ID Datablock. You might need to hold another copy of the
unshattered mesh too, if you quickly want to revert to the original
object.

Some time ago i wrote down a fracture modifier redesign proposal
here:

https://developer.blender.org/T42306#323150

which mentions this as one list point among others.
Other points there mention coarsely how the rigidbody and cache system
could be done.

I also have started and half-finished a fracture modifier rewrite which
goes into that direction, the link to the code is at the bottom of the
proposal.


Am Samstag, den 26.09.2015, 20:25 +0200 schrieb Brecht Van Lommel:
> Could the mesh islands be implemented as a data layer, like an integer
> island ID per vertex or face? Is there a reason they must be a core
> part of the mesh like vertices, edges or faces?
> 
> Making islands a fundamental part of a mesh like it would complicate
> all mesh operators and modifiers, while a custom data layer would
> ideally only require changes to the fracture modifier and the rigid
> body system. It seems like that would simplify 1) a lot, though either
> way you'll need significant changes to the rigid body system to
> support such islands.
> 
> 
> On Sat, Sep 26, 2015 at 7:32 PM, Kai Kostack <kaikostack at gmx.net> wrote:
> > Hello folks,
> >
> > A few weeks ago I have announced that we would provide a requirements list for the Fracture Modifier (FM) and here is it now. Please feel free to comment or share your thoughts on it.
> >
> > http://kostackstudio.de/dl/docs/Requirements_List_FM.pdf
> >
> > -- Kai
> >
> >
> > 1. Subgeometry system:
> >
> > Object shard management in the FM happens currently in form of shards for fracturing, and mesh islands for simulation. Desirable would be an integration of a mesh island concept (as fourth element in addition to vertices, edges, faces) into Mesh, DerivedMesh and Bmesh / BMEditMesh, so no special DNA structures like shard and mesh island would be necessary any more. This would be a better integration into existing data structures.
> >
> > Shards should all be part of one single object, so that the depsgraph doesn't need to manage thousands of individual objects. This would lead to higher performance at cache playback and easier to handle by the user. Also it wouldn't clutter the Blender database with ID blocks and would keep the outliner clean.
> >
> > Mesh islands would have direct references to the vertices which build up the shape of their rigid body. This is necessary for fast access when the vertices need to be transformed after the simulation step has occurred to update the visual render mesh.
> >
> >
> > 2. Multi rigid body system:
> >
> > When we have multiple independent rigid bodies per object, each rigid body shape can be constructed by the individual shard / mesh island it is assigned to. “Multi rigid body” could become a new rigid body type and should be the default. Single rigid bodies would be covered by just having only one mesh island.
> >
> > However having two rigid body systems is not optimal. There would be a mapping step necessary between regular rigid bodies and shard rigid bodies across the simulation object group.
> >
> >
> > 3. Caching:
> >
> > For prefracturing there is a shard / mesh island cache necessary, so you don't need to refracture the object in each modifier evaluation step, even if no changes are being made to the mesh. This is currently implemented as special DNA structs and stored within the .blend file.
> >
> > For dynamic fracturing either a dynamic cache which supports a growing count of elements and changes in mesh topology would be necessary, or a sequence of shard / mesh island lists, which would denote the mesh state at keyframes where fracturing events happen.
> >
> > For simulation data currently a fixed point cache is used, which stores motion data (loc, rot) on per frame basis. However this is only sufficient for prefracture.
> >
> > On a dynamic fracture simulation the cache needs to be dynamically extensible as well, to be able to store more and more elements as the simulation goes on. One idea for the FM was to distribute the cache among all participating objects (so each object has its own cache).
> >
> >
> > 4. Storage:
> >
> > Both mesh and simulation cache should be storable in the .blend file, or alternatively in an external file so the simulation is ready to start after loading the file. No additional fracture step or first uncached (slow) simulation step should be mandatory in case the cache is valid.
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers