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

[Jacob Merrill]

I remember PsiFi stating the only reason the new viewport render code would
not make a good game render had to do with these islands, but I never
understood the why, can someone enlighten me as to what this means? what
are data islands for?
On Sep 26, 2015 11:26 AM, "Brecht Van Lommel" <brechtvanlommel at pandora.be>
wrote:

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