Fractured enemy mostly works as expected, but the objectpooling creates a problem where already fractured targets will spawn. This either needs to be solved, or the fractured targets scrapped altogether.

 Let's see what happens when attempting to integrate a fractured target. The target itself has both a mesh collider and a rigidbody, which are typically not on the initial mesh, so I'm unsure whether or not that will create problems or even if those components will be necessary when all is said and done. Also, the cell fracturing may not play nicely with this complex of a mesh; typically it likes quads, and quading out this mesh could be a headache. Oh well, here goes...

I recently made a few different variations of a painting that I created in Corel Painter last year. The variations are more conceptual rather than finished product. Primarily they were created using the channel mixer tool in combination with adjusting the HSB of various selections. 

Here is the original

Here are the variations

 Going to set the convex flag for all fragments, maybe even replace the mesh collider with a box collider. See if performance is noticeably better.

 Box colliders instead of mesh colliders on the windows was apparently a not great thing as the BreakableObjects script specifically looks for a MeshCollider when disabling it on shot. I could probably fix this without breaking anything, but to be safe I'm not going to bother with it; at least, not yet. Anyways, as I said before, I imagine the performance benefits (if any) are negligible compared to the physics hit I'm getting on the fragmented objects. 

 Running into frame rate issues, which doesn't exactly come as a surprise. Spamming the P2 shotgun (the equivalent of 9 shots) & the sheer number of fractured objects on screen at any given time both seem to impact performance more than anything. 

I've already made a couple of adjustments--namely reducing the time until the CombineInstance function fires & drastically reducing the life time of the particle fragments--which seems to have helped, but the performance is still not where it should be. I've also replaced the mesh colliders on the window panes with box colliders, which I would assume is also less expensive, if only barely. Other than that, I'm not yet entirely sure how I'm going to handle this...

 Going back to the fence, which was one of the first, if not the first object that had UV distortion issues, and after a bit more reading and trial and error, I have come to 2 conclusions

1. there's something about tiling UVs that fracturing does not like. This can be solved by manually applying the boolean modifiers; however
2. doing so somehow affects the maximum # of fragments that the CombineInstance function can handle.

I know I've gone over this at least 1 or 2 other times, but I am increasingly convinced there may not be another practical solution without programmer aide. This also presents problems for larger objects, such as the entire facade(s) of buildings, which rely heavily on tileable textures. 

 Another window that will only be 250 fragments instead of the usual 400. It'll be interesting to see if this behavior continues on other objects. As of now it's only been the windows.

 Nevermind, Solidify changed nothing in that regard

 Trying something a bit different with this window, which also distorts the UVs at the corners. Instead of building the geo from scratch, I'm using the Solidify modifier. Can't see how that would make any difference, but I guess I'll know soon enough.

I'm still unsure where the problem is and I'm a bit tired of experimenting with this process, so for now I'm going to move on. On the bright side, I no longer need to convert all fragmented pieces into editable meshes in order to apply the boolean modifier; instead, I can use the Blender "Modifier Tools" addon which allows the simultaneous application of modifiers across multiple objects. However, this doesn't appear to fix the problem. While the CombineInstance function does work as expected, I can (for some reason) only use ~250 fragments. From previous testing I know that I should be able to use near 400 so there's something going on that I don't yet quite understand. 

Regardless, as I said before, I'm going to implement this window_med mesh using only 250 pieces. Perhaps the problem will reveal itself as I continue working? If not, I suspect 250 pieces/fragments will suffice.

~390 fragments works as expected, which means the DebugBoolean process is somehow mucking up the works... :/

Using the fragments with the UV errors (e.g. without DebugBoolean) and with only ~100 pieces, the in-game performance was as expected. Let's narrow this down

 In addition to the UV errors in the corners of the window mesh, I am still experiencing this error.

There are < 400 fragments, so I do not know why this would be, but I'm now wondering if the UV issues is somehow related and/or the cause. I attempted a whole new set of UVs, but that didn't appear to change anything, so now I'm wondering if the DebugBoolean -> AutoSmooth -> ConverToMesh (e.g. collapse boolean modifier) is somehow mucking things up? 

 Now working on the large window and despite the UVs all seeming to be in order, for some reason the cell fracture was still distorting the UVs at these corner points. I would suspect that it is likely this is due to those points being poles, but if so, why did this not happen before? ...regardless, setting the debug boolean, manually setting the auto smooth of each piece and then converting to a mesh appeared to solve the problem. Nevertheless, WTF. This process still seems to have some kinks I don't fully understand.

The 2nd floor window shutters definitely went smoother. One of the two still had UV issues that needed correcting. It's weird that only one wasn't entirely UVed...it was the same with the swinging saloon doors...weird.

...now for the window shutters. Should be roughly the same as the swinging doors, but hopefully without the hiccups.

Saloon front doors/shutters are working (e.g. fragmenting in game). Halleluiah 

Well, it looks like the bottom portion of this object didn't have UVs, and after making that correction it seemed to export just fine. Though, it's curious why it was sometimes working before. I would have expected the export to fail every time if this were the case. Maybe the fracturing does its best, but sometimes that's not good enough? Maybe it's something else? IDK, at this point half my day feels wasted so whatever...

 

The fracture in my previous post was quick and dirty, so I decided to go back and do it like my other meshes, but again, I ran into export issues. I narrowed it down to a single fractured object that apparently the exporter hangs up on because of a UV issue. Why this is the case, I have no idea, because at a glance the UVs look just fine. Also, why have I not had this issue before? Why on this object? I really do not understand. :(*

 Started over from scratch. Normals are now properly oriented although I still have no idea what happened because while they appeared as expected in Blender, in Unity they were reversed. Something with the import/export process...perhaps related to the errors I was getting?

The CombineInstance material issue was due to misc objects created by the CellFracturing. These misc objects contain no geometry and no material reference. I can only assume this is an error and although I have seen it, it hasn't been since the very first object I fractured. Not sure why it's resurfacing now, but deleting those objects solves the problem.

 Now normals are inverted for some reason??!?!?

 Should have expected this would be more difficult after saying what I said in my previous post, aaaaand blogspot has trouble uploading snippet via copy/paste...again. I suppose I should consider myself lucky my monitor doesn't explode and lodge shrapnel into my face.

Somehow, an additional blank/default material is being generated on CombineInstance. I have no idea why this is happening.

I'm also experiencing export issues in Blender, but only on one of the two saloon doors and only when I attempt to export it together with the fragments. Again, I have no idea. Working in 3D is so cumbersome

 Now I'm going to tackle the swinging saloon doors. I expect it'll be roughly the same as the previous door

 After some doing, I finally got this working!

Fracturing and setting up the non animated door went as expected, but getting it to animate properly while also being destructible required finding and setting a reference I wasn't previously aware of as well as orienting the pivot in a specific way, which, while annoying, I'm not entirely surprised. 

Side note, every 5 or so seconds the game suffers massive hitch. The profiler seems to indicate it has something to do with the "Scripts" and while I think the P2 shotgun fragmentation makes this somewhat worse, I cannot be sure exactly what impact it has. I'm not surprised, as the shotgun fires 9 shots simultaneously, which is ~9x the fracturing (depending on shot spread & objects hit), but the hitching may not be an issue were this initial hitching eliminated. I've also noticed that shooting the hitching post tends to more greatly impact the performance, which would indicate the interior (non-destructible mesh) is part of the problem as it is currently the only asset that is setup that way. For now, I'm moving on, because worse case scenario the interior portion is removed; although, I can probably find a more elegant solution.

 ...now time to tackle something that's animated--this door on the second floor of the saloon, which is also used in a few other places, seems like a good candidate. 

All of the fractured pieces are marked kinematic until they break off, so I think this will still function as expected.

 437 fragments is too many for the CombineInstance function. Without further testing, I'm going to move forward assuming 400 is the limit. I may have to go back and re-fracture a couple (three?) assets once this is all said and done, but for now I'm moving forward because perhaps that won't even be necessary if performance is still good.

 Minor caveat regarding this solution: all of the boolean modifiers must be applied prior to making any transform changes. I suspected this might happen, but was hoping due to all of the fragments being parented to the original mesh that I might be able to circumvent this. Well, apparently not. Couldn't quite figure out how to apply the modifier to all ~430 objects simultaneously and there was no way I was going to do this one-by-one. Apparently there are a few methods of doing this and the first one I landed on that worked was converting all of the fragments to a mesh, which technically they already were, but doing so collapses the modifier...simply to 3DS Max. Great

I think I've found a different, definitely less cumbersome method, and probably better method. The Cell Fracture tool has a debug boolean flag which leaves all the boolean modifiers intact, which produces this

...and while the previous UV texture distortion is gone, the entire mesh has a certain stone wall look to it due to each fragment having smooth normals (this must be the default prior to collapsing/applying the booleans). So it seems I've traded one problem for another, except now I can apply the angle based AutoSmooth on each fragment, and voilà.

 Based on the even division of the error, I figured it must have something to do with tiling UVs.

The error always occurs where there are seams in the UVs. The UVs were previously stacked, but I have moved them +/- 1 unit to better show the tiling.

I think I'm simply going to separate the mesh into 3 separate meshes, fracture each mesh, and then rejoin them. If the issue is as I suspect, this should fix it.

Well this is strange. I'm getting botched UVs on the fractured pieces. Not sure of the cause, but perhaps it is somehow related to me having removed all of the unnecessary materials used by the other pieces of the saloon? Can't see how that would cause this, but who knows

Now that I think I have fair grasp on both fracturing and integrating the result into Unity, it is time to try something a bit more complex. The Saloon

Aside from the highlighted items, the saloon is one entire mesh, which means various pieces will have to be separated and then placed accordingly, in Unity. The fencing seems like an easy enough, good starting point, and multiple buildings (not just the saloon) use it, so it will have significant impact on the game as a whole. I'm thinking I'll fracture a section of fencing--maybe one of the 1st floor sections. 

Also, side note, snipping from Photoshop doesn't even work with copy/paste into the blog; I always have to manually save and upload the image from desktop?!?!? Weird. I wonder why that is?

 The barrel is working with the metal banding being separate and ~500 fragments. A couple of things to note:

1. The metal bands do not yet have a backface, so those should be added as they could be visible.
2. The CombineInstance function fails at ~500 fragments (as you can below to the right). The left portion of the image is prior to the CombineInstance.

The barrel is a bit more complicated, or at least, it should be. The metal banding will be extruded and exist as a separate GO(s), because they should not be destructible; only the wooden planks should be. I'm also thinking everything below the top metal band should be sticky so that only the top 20% (ish) could crumble away.

Now on to this crate

Would be interesting to fracture the frame separate from the interior paneling and for the crate to also contain contents of some sort. There are still many more (& more complex meshes) that still require fracturing though, so for now will leave it as is.

These settings are a bit better, but I don't think it will ever be perfect due to how the system operates and the outcome will always display one of two (if not both) behaviors. 

1. The GO in question will be a bit too crumbly (as in the example below), or
2. The GO will be too stiff and will result in floating fragments. 

These could be mitigated somewhat if all of the fragments were roughly the same size, but this isn't particularly achievable using the CellFracturing in Blender--there's always a bit of variance to the pieces...and even if all the pieces were the exact same size (volume?), their differing shapes also pose a bit of a dilemma due to the connectivity of each piece being related through the ConnectOverlapSphere property. And while I'm not entirely sure what that is, I suspect (based on the nomenclature) that it is a sphere collider of sorts with a certain float radius/diameter placed at the center (pivot?) of the object, and that the overlap between fragments/spheres is indicative of a connection. 

Anyways, here's the current result

Seems to be working roughly as desired. There are nearly 400 fragments and the CombineInstances isn't throwing the error I referenced a few posts ago, so whatever that limit is, it is more than 400. 

There is still some refinement required as sometimes pieces will float in place due to the current settings in the connections panel. 

Fracture the trough

So far so good. Assigned a few more hotkeys in the process, capped & UVed the bottom. 

 Next up is a trough. 

Would be cool to have water in this thing and have water leak from all the holes when this thing is shot, but that will likely have to be saved for another time. 

Side note: Why does the copy/paste from the snipping tool sometimes not work? I had to save this image and manually link it instead of simply copy/paste from the snipping tool. WTF?!?! 

 Found the problem! Here is the error that is thrown regarding the mesh combining. 

At first I thought that perhaps the string length of the GOs was the problem, as many of my frag GOs has very long names, but it turns out that it is the sheer number of GOs that is causing the problem. I exported only a fraction of the # of fragments, and violá, no more error && no more visual abominations when the CombineInstance function executes. While this doesn't necessarily solve the problem--I would still like a lot of fragments as it helps more specifically identify where the shot has landed; in fact, I would prefer even more--but at least now I am aware of the specific cause. 

I could break up the object into multiple prefabs. In this particular instance, 3 prefabs would be ideal--1 for the crossbar and 1 for each support, but that definitely makes the process more cumbersome as it is more GOs to manage, and perhaps more importantly, it doesn't solve the problem; it only sidesteps it. Lacking engineer support it may be a necessary evil.

From the looks of it, there's nothing in the Fragmented Objects scripts that hints at a limited # of fragments, so I suspect it is something native to Unity itself. I wonder if it is something that can be adjusted in the project settings, or if it is hard coded into the engine? I suspect the latter. I could, and still may, do some digging, but I have already spent much more time than intended orienting myself with this package. I guess you get what you pay for :

Cont from previous post

Perhaps it is naming issue? The fractured pieces do not all share the same base name due to the fact that I fractured the mesh not as a whole, but as 3 separate pieces that inherent make up the mesh.

Image failed to upload?!??! Dumb, but whatever. The base name of objects don't match, which should be easy enough to understand even without visual reference.

 Soooo...this bullshit is happening when the CombineInstance function executes

Athough an error is being thrown, my limited knowledge of code is preventing me from truly understanding why this is happening. I suspect it has something to do with material IDs and the fact that they are sometimes swapped on any given fractured piece. Visually, each individual fractured piece looks as it should, which you can see in the image below; however, upon running the CombineInstance function, the artifacting happens. 

I thought that disabling CombineFrags would solve this particular issue, but it does not. I can instead increase the value of the CombineMeshesDelay to an integer that is greater than the amount of game time, and while that would technically solve this particular problem, I would be surprised to encounter performance related issues as a result of this particular "solution."

Regarding the swapped material IDs, I think that this is somehow the result of the Cell Fracturing process, and that somehow when assigning the secondary material ID, the nature (concave vs convex) of the fractured shape might be responsible. For example, previously the entire mesh was fractured. Notice how in the image below the 3 removed pieces reveal that the interior of the mesh is completely solid, which makes every fracture piece convex and ensures the entire mesh can be fractured apart.

However, in this instance, I do not want the entire mesh to break apart, but instead I wanted there to be an underlying piece of geometry that would recognize shot collision, but would not itself break apart, and to do this, the Cell Fracturing can account for interior (child) geometry and will fracture accordingly, giving the following results

Notice how the fractured piece is now concave due to the fact that the fracturing algorithm has conformed to the interior mesh. You can also see examples of this in the 2nd image of this post (the one that displays the actual fracturing). 

Still, this is all just a hypothesis and I currently do not have an adequate solution.

The documentation of the Fragmented Objects system leaves a lot to be desired. TLDR at the bottom of this post.

                                  

StickyTop & StickyBottom are used as anchors for either objects that are hanging (StickyTop) or sitting on the ground (StickyBottom), thought I'm not exactly sure how it distinguishes top from bottom. Maybe via transform, pivot, or other? ...but even then, what about meshes that are horizontally oriented with a central pivot? I should probably look into this. 

From what I have observed, setting these values to 0 effectively disables them. When > 0, the StickyTop/Bottom will include that many pieces in the StickyTop/Bottom definition. For example, if the entire column is comprised of a total of 50 pieces and I set the StickyBottom value to 50, then technically speaking the FraggedController would consider the entire column to be the bottom of the mesh. If the StickyBottom is set to 25, then only the bottom half of the column would be considered the sticky bottom.

The ConnectedFragments value serves as a threshold beyond which everything except the StickyTop/Bottom will crumble. The value of this threshold appears to define the minimum # of adjacent non-fractured pieces that are required for the structure to maintain its integrity. For example, were you to do a full accounting and discover that the maximum # of adjacent pieces in the column were...say 5, then setting the ConnectedFragments value to 5 would ensure that the destruction of a single non-bottom/top fragment would cause the entire mesh to fracture and crumble (again, notwithstanding the bottom/top). If however, you want to be able to destroy nearly the entire mesh prior to the remainder crumbling, then you would set this to a lower value of...say 1 or 2.

                                  

While each mesh is different and will contain a unique # of fractured pieces, here are a few rules of thumb.

1. A value of 0 is equivalent to disabling that property.
2. The larger the StickyTop/Bottom value, the more pieces will be considered to be top/bottom.
3. The larger the ConnectedFragments value, the more easily the mesh will crumble.

In the process of using Fragmented Objects for destruction purposes. None of the games currently support or have implemented tech such as this and it is very much a missed opportunity to make the user feel as if they exist, and have impact, on the game world. The proof of concept in PL2-Outdoor was a success and now it is time to apply it to a more relevant games.

First, the Fragmented Objects package is not responsible for dynamically fracturing the mesh; the fractured meshes must be user-generated. To do this, I am using Cell Fracture plugin in Blender v2.82, which while not perfect, does generate useable results that don't require breaking up the mesh by hand. 

Second, while not new to 3D software, I am new to Blender so there has been (& will be) a bit of learning curve. However, the setup & the major hurdles of the process have already been addressed, so outside of working out the kinks in Blender, I don't foresee any major hurdles and expect in time this to be a relatively straightforward, streamlined process. Perhaps it could even be entirely automated given an engineer's touch, but that's a bit out of my current reach.