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

Lukas Tönne lukas.toenne at gmail.com
Sun Sep 27 10:31:38 CEST 2015


About mesh islands: It's been a long time ago, but i think i suggested
something along the lines of a vertex/face attribute originally. Even if
caching mesh topology for the modifier would be needed, i don't think
creating shards as an element like verts/edges/polys would be necessary.
Like Brecht said, it would likely add a lot of complexity for other code
too. The modifier could efficiently calculate a sorted "shard index ->
face/vertex index" map when needed.

About rigid body sim: I think it's important to note that the Bullet rigid
bodies don't have to be synonymous with Blender objects! This is just a
convention that makes writing a C-API easier, and it would open a whole
range of interesting features if the API could be used by other parts of
Blender for "plugging in" rigid bodies.

There is a feature branch [1] which substantially extends the Bullet
rigid_body API for Blender. This was originally created to improve hair
collision, by adding "ghost objects" (btGhostObject [2]) and more direct
collision shape control. I would consider this master-ready (pending
review), and probably helpful for simulating mesh islands as well.

An unsolved issue is the interaction of modifier update calls with the
Bullet time stepping on the scene level. A pre and a post step are needed
for each participant of the rigid body sim: to update the RB world, perform
the step, and then apply the results. This all happens on the scene update
level currently and is irrelevant to modifiers. A true API for the RB world
would avoid looping through the object group and instead leave it to
modifiers to register rigid bodies and then read out simulation results
after the step. Without a refined depsgraph that allows splitting the
object/modifier update calls into pre/post parts this will be quite
difficult and ugly.

And yes, caching is still largely unsolved ...

[1] https://github.com/lukastoenne/blender/tree/temp_bullet_ghosts
[2] http://bulletphysics.org/Bullet/BulletFull/classbtGhostObject.html

On Sun, Sep 27, 2015 at 7:58 AM, Martin Felke <martin.felke at t-online.de>
wrote:

> 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
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list