[Bf-committers] Requirements list for the Fracture Modifier in Blender
kalast at gmail.com
Sat Sep 26 23:56:10 CEST 2015
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
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>
>> 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
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers