The nails can now be shot off and the lid will pop open when all nails have been removed. 

The physics force for the nails is provided by a ShotCollisionResponse script that was not my doing; although, I did make these changes so as to only utilize the physics force on the nails when it is needed (and not before). I'd guess this isn't the ideal way to do this, but I'm not a programmer so I can only guess. 

The lid itself is handled through a uscript which contrasts the total number of nails against those that have been shot off and takes the appropriate action.

It's a start. 

Side note: the video shows my mouse tracking maybe 1/4" higher than its actual position...weird.

The player shoots n number of nails off the crate one by one; once all nails have been shot, the lid animates off the crate, and....something emerges. 

Gold (coin/nugget/bar/pile) is the first thing that comes to mind and would suite the environment. It also fits within the context of the various GoldMiner targets. Perhaps that connection could also be capitalized somehow. 

Regarding the function of the gold (or whatever) that emerges, I'm not sure. The first thing that comes to mind is an allotment of points when shooting the gold, but I can't say I really care for that. I'd rather it be something more interesting, more...engaging. I'll give it more thought; for now I know enough to get started.

Ran into a few issues when combining all of the duplicate instances that comprised the CrateA mesh and had to do the following:

1. Make each instanced mesh unique via the MakeSingleUser (object+data) function
2. Ensure all of the UV maps from each mesh that would be joined together were the same. Apparently, Blender defaults to giving unique objects unique UV map names, which can cause the previously packed UVs to get unpacked and/or potentially in need of complete UVing all over again...though I can't speak to the latter part as I didn't look into it. 
3. Clear the custom split normal data on certain objects. Again, I don't know why this would be necessary, but prior to doing this I was seeing previously flat shaded corners areas become smooth...as if they were completely ignoring the autosmooth (30º) despite it being enabled. 

I suppose the lesson here is that each mesh contains a bunch of its own data that must be taken into account when joining objects together. I expect I'll be running into this a lot as join is a common function. 

I think I'm calling this crate complete (at least, for now). Crate contains D, M/S, N, & AO. Unfortunately, simple images are a cheap solution for presentation. What is really needed is a model viewer. I'm guessing there are solutions to be had, but I should also consider another solution apart from blogspot. For obvious reasons, ArtStation is the first thing that comes to mind.

As a side note, using heavily compressed RGBA Crunched DXT5 has reduced the file size of the M/S texture; seemingly without sacrificing image quality. 

 Nearly done with the diffuse. Took a 30 min detour making the washed out plank in a more realistic style; knowing full well I wouldn't intend on the final looking as such. Still, it's an interesting result and process. With such muted colors and values it's more difficult for my eyes to see the work that needs to be done in order to achieve the desired result and is instead a more intuitive abstract process relying on the fundamental process I'm using to paint all the wood in general. When this crate is finally complete, I should probably make an effort to review, consolidate, and document my painting process.

 After several attempts, I've finally arrived at a style which pleases me--one which isn't too detailed, but also not too flat & one that approximates the look of beaten up wood. I've considered a result that's a bit cleaner; with less wear and tear, but I've spent enough time on this and am eager to see the entire result; otherwise, I feel as if I'll be in texture painting limbo.

 All of this was painted on a single layer, which is less ideal for making any edits prior creating the various other maps in Materialize, but all previous attempts painting on multiple layers felt too cumbersome and perhaps it will be good to see what I can squeeze out of Materialize without the benefit of tweaking individual layers. 

 A Practical Approach to Physically Based Shading in Unity -- This link contains some basic information and value charts for metallic, specular, & diffuse properties of various materials. The last half of the article demonstrates the importance of such things on a crane asset in the Viking demo scene; particularly the importance of SecondaryMaps to add detail at a relatively low cost.

Regarding the CrateA asset, a specular smoothness/roughness map may not be required and a simple value may suffice, but that remains to be seen depending on the nails/spikes & perhaps other unforeseen added details in the diffuse.

There were a few issues with the UVs that required some manual stitching, and in doing so, I did a manual repacking. UVPackMaster still has it's place, and I think with a more detailed grouping the UVs could be grouped a bit better. 

Despite not doing any traditional texture baking, it's always good to remember how normals will be rendered. This video demonstrates problems and solutions when baking normal maps as it pertains to UV layout and smoothing groups.

First Pass & Problems

Solutions

CrateA is currently adopting the first solution, which is to say it uses face weighted normals and split UVs accordingly. It'll be interesting (and perhaps problematic) to see how a painted and/or diffuse-generated height map can be used to create the normal map in Materialize.

More Normal map info

Types of Normal Maps & Common Problems

Toolbag Baking Tutorial -- The last 25% has some advice for tips, tricks, & solutions to common problems.

 Initially, I had started painting the diffuse, but it seems more prudent to first paint a height map to get a better understanding of the normal map

 It occurs to me that perhaps I should allocate some empty space on the UV sheet to account for the possibility that I may later discover a need for more crate-related objects. I suppose that illustrates the importance of the pre-production phase, which I've more or less bypassed in the interest of making some new art. 

With minimal effort, I was able to find a better packing. UVs are grouped by face numberings whose faces are colored accordingly for illustrative purposes. 

 I think I've found a solution in UVPackmaster. It is a 3rd party UV packing tool that allows the grouping of UV islands based on a varying number of parameters. Notice in the image below how each integer is grouped. There is more wasted space than I would like, but I think with a bit more tweaking I can probably resolve this. Thus far, the plugin is fast and easy to use. I spent the bulk of my time looking for solutions, finding this one, purchasing, downloading, & installing it, and going through the documentation. Actual time spent using the tool has been minimal, which was what I wanted--a tool that would minimize UV hand holding. I imagine this tool will save me quite a bit of time in the long run.

 Crate has also been UVed using instanced duplicates. However, Blender's pack function doesn't appear to cluster the UVs of any given object together. The front column is highlighted and notice the placement of the UVs for that object in the image editor. I wonder if there's a way to cluster UVs by object, or by material IDs, or maybe some other way that's less...random?

 Crate assembled using the handful of pieces shown in the previous post. Considering it's a simple crate, the silhouette is fairly unique, which I like. Each side of the crate is also unique in some way, with the top being the most unique. There are large nails and railroad spikes meshes used to seal the top portion of the crate. Maybe the nails could be shot off the crate, causing the lid to open and its contents (whatever they may be) exposed? 

The plan is to create at least 1 unique box using the pieces shown in the image below. Each unique piece is color coded in the middle image and texture preplanning is color coded in the right most image. I'm still unsure of where to draw the line regarding the modularity and uniqueness in the texture, but that's always a struggle of sorts, and will hopefully be revealed as I move forward. If it's wrong, I can always make adjustments.

I'm going to rework the crate asset as the first step towards improving the visual aesthetic of the SS environment. The art style will remain hand painted, but will be pushed a bit further by utilizing a PBR workflow via Materialize. The base assets themselves are painfully low poly, so some additional modeling & UVing will be in order.

The top left is the original crate cube and to the right is a quick, but incomplete paint over, to help me visualize the construction & basic layout of the crate. Below that are various references containing certain elements I wish to incorporate into the new crate design--be it the overall construction of the crate, the wood material itself, decals, etc. 

 Couldn't quite get what I wanted from uscript, or rather, it could be done; except there are already scripts in place that handle ray casting so handling decal normal-based orientation via uscript would cause duplicate ray casting, which, is not ideal. 

After some digging into the ShotCollisionResponse script I was able to cobble something together to solve the problem. See the areas highlighted in green

The results are shown below, although the decals themselves still require some work

 Would be nice if the decals oriented based on the mesh normals. I wonder if there's a way to do this in uscript?

Working with Materialize. The original decals were sprites and I wanted to create ones that could take advantage of normals, spec, etc. Materialize seems like it will work. From left to right these are the 3 decals that were created for the tiling wood texture. These initial tests were to gauge how large I wanted to the details to be, and given the hand-painted, exaggerated nature of all the textures in the scene, I think decal 3 is probably the best. The decal itself needs some proper work, but I'd say it's a good, rough approximation. 

Also, I've made the necessary edits to the DecalCustomizer uscript in order to appropriately assign the color (the previous version accounted for sprite decals, which these are not).

Another side now: I also made a quick pass at adding normals to the wooden texture on the saloon (also used on the jail) just to see what that would look like. This was more or less me playing with Materialize to get a better handle on it. Not very impressed with the results, but then again, I didn't spend much time, so that's to be expected a suppose. The normals themselves are clean enough though...considering.