You are correct in that there is no pooling support in the toolkit, when a shatter occurs the pieces are instantiated as new game objects (clones of the original to carry over components etc) and the original game object is destroyed. This is something I'll keep in mind for future versions of the toolkit.

Thank you for a thorough review! I will try to answer your concerns the best I can. "- No support for audio on collision (though that's easy to add)." "- No inherent support for triggering particles, other object disabling, or similar on cuts. Though those are not bad to add yourself later." I decided to not handle this in the toolkit since different games will handle this in different ways. That said, it should be easy to add this functionality yourself since the toolkit calls the PreSplit() and PostSplit() methods before and after a split/shatter occurs. A custom script can implement these methods in order to change or extend the behaviour, for example by adding sound/particle effects effects before something is shattered or by removing some undesired pieces after something is shattered. "- Auto removal after time is based solely on generation (which isn't incrementing anyway), rather than something more useful like the size of the resultant mesh." "- The generation count is never increasing, leading to the generation limit being pointless. Easy enough to fix, though." "- If you have other kinds of colliders other than mesh colliders on your original object, you'll have to update the script to remove them manually. Otherwise you'll get very funky results with double colliders." The toolkit clones the object being shattered so all the components of the original will be carried over to the pieces. No components are added. If the original game object was of Generation 1, the pieces will be of Generation 2. I double-checked that this still works and it indeed does, so it is not a bug. If you have other colliders than mesh colliders, they too will be carried over to the pieces (and updated according to the new geometry). You will not have double colliders on the piece game objects but since a box collider does not usually approximate a piece very well, multiple pieces will intersect after a split and be thrown away violently by the physics engine. This might be undesirable but it is not a bug. If you want to use e.g. box colliders it might be a good idea to create a custom script that either scales down the collider of a piece game object after a split has occured (implement the PostSplit() method) as this will mitigate the problem. You can also try disabling inter-collisions between pieces for a limited time after a split has occurred (again using a custom script). "- No pooling for objects." I don't understand what you mean by pooling. Since the shattering is dynamic, no two pieces will be the same after a split, so I can't see in what sense they should be pooled. "- No cling logic for things like glass." "- No joint transfer for hinges." "- Collision shatters are based simply on velocity, not force." Good suggestions, I will add these to my todo list for the next version! "- No support for skinned meshes (not that that's common)." I decided early on to not support skinned meshes, mostly because of ethical considerations. "- The constructor for FastHull that looks like it would clone an existing hull copies the size of the arrays but doesn't fill them!" This is probably a perforamnce consideration. I haven't looked at the code in a while so I'm not 100% sure, but I will look into this for the next version as well. Even if it is for performance reasons, it might be better to have a separate function for allocating the space only, instead of having it as a constructor as it would be less confusing. However, I did not really intend for people to change the code. "- It's possible (and frequent) to "fracture" the object with not enough force to really cause a cut, so instead it just makes a copy of the one object and destroys the original. ..." This happens when no splitting plane intersects the mesh and should be practically impossible if the shatter point is on the surface of the mesh. However, it can happen quite frequently if the point sent to the Shatter() function is not on the surface or inside the mesh. To avoid it, make sure that you always supply a point close to or inside the mesh when using the Shatter() method and supply planes that intersect the mesh when using the Split() method. The ShatterOnCollision helper script supplies the point of impact to the Shatter() method and should avoid this problem most of the time. However, it might be that the point of impact for a convex collider is outside the cancave mesh itself, causing the problem. I will look into ways of fixing this for the next version as well. "Overall would I recommend this? ...yes, kind of. ..." Thank you for your honest review. My plan for the toolkit was to provide fast, easy-to-use mesh splitting/shattering and do it really well. Overall, I think it is successfull in doing its job. That said, I agree that there are some features that would make it even better and I hope to add them in future updates. I'm planning some big additions for version 2 of the toolkit. Please see the roadmap here: gustavolsson.com/roadmap If I understand your feature requests correctly, you want clinging, joint transfer and pooling to be part of the core toolkit. I will evaluate these for the next update. Could you maybe ellaborate on your request for pooling by sending an email to me directly? Best regards, Gustav

I've encountered these issues recently as well (I haven't used static GOs before really), and I've added your points to my todo-list. I will hopefully have some time in July to work on a nice update for the toolkit and I will improve the documentation then as well. Thank you for the feedback!

I've added the PieceRemover helper script in version 1.5 of the toolkit in order to help reduce the amount of resource comsuming debris in larger scenes. Thanks for the feedback!

Thanks for taking the time to write a review, I'm happy that you like the toolkit!