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

[Brecht Van Lommel]

That issue is not relevant to fracturing though, different kind of "island".

On Sat, Sep 26, 2015 at 11:56 PM, Antony Riakiotakis <kalast at gmail.com> wrote:
> Because in OpenGL one vertex can only correspond to one unique set of
> vertex attributes while in blender one vertex can have many different
> data values per loop. Having data islands, allows OpenGL to detect and
> reuse those vertices whose vertex attributes are shared across many
> triangles.
>
> On 26 September 2015 at 21:34, Jacob Merrill <blueprintrandom1 at gmail.com> wrote:
>> 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
>>>
>> _______________________________________________
>> 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