some things to think about

[ScatteredComet]

• performance during splitting - if we animate some explosion cloud, perhaps we could do the fragmentation asynchronously and hence reduce lag / stutter?

• can we get up to something like 1k fragments on screen at once?

• deloading fragments after some max number is hit?

• particle effects when queuefreeing small nodes & implement queuefreeing of nodes whose depth is less than the requested explosionDepth

• materials? how to deal with interior / exterior faces

• support for any general mesh using the algorithm by Matthew Clothier and Mike Bailey

• streamline into a plugin somehow? like just add a .blend file, set fragmentation characteristics and everything else is done for you would be nice...

• maybe larger objects should be more difficult to fragment - you could minus 1,2,3 etc from the explosionTreeDepth for objects larger than some given size ranges

[ScatteredComet]

might want to do a more meaningful check than:

Vector3 globalLeafPosition = destronoiNode.GlobalTransform * vstNode.meshInstance.GetAabb().GetCenter();

if ((globalLeafPosition - GlobalPosition).Length() < explosionDistanceMax)

for example, could use an area3d overlappingareas check (might be expensive though) or somehow store each fragments true centre (that information might be storable during Bisect / PlotSitesRandom on startup somehow? i assume that the "sites" array has something to do with it) - instead of using the centre of the aabb

[ScatteredComet]

some answers (as of commit c256d7a)

1. no need, performance is fine rn
2. yes
3. not implemented yet
4. implemented in 39deb9a
5. implemented in 7044e08 (merged branch feat/adding-basic-materials-support)
6. prolly wont be necessary until some "concave" hull method is added (for determining collisionshape of fragments that have bumps)? i think its fine for now tbh
7. yep thats basically done, setup is simple rn
8. not implemented