That issue is not relevant to fracturing though, different kind of "island".
On Sat, Sep 26, 2015 at 11:56 PM, Antony Riakiotakis <[email protected]> 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 <[email protected]> > 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" <[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 > _______________________________________________ > 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
