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" <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
