Hello and welcome to 2017! Hope everyone had a great holiday and is ready to take on the new year! Over the month of December, I have been continuing on my quest to create models of the NPC’s for each level. There’ll be somewhere between 26-30 NPC’s, so still a ways to go, but I’m about 1/3 the way through. What you see up above is a concept model for a character I’ve code named Conduit. Although he appears menacing, he’ll actually be more of a neutral character. Helping out the player, albeit in a begrudging manner.
Anywho, earlier in the month I had modeled two other characters, imported them to Unity, and made a startling discovery. For those of you creating robotic characters/characters with rigid parts for your games, gather round, you may want to listen to this. The characters I had modeled were both robotic in nature, i.e., their limbs were made of separate pieces that wouldn’t deform during animation. The experimental strategy I had originally approached with was to make each body part its own mesh and attach each mesh to its corresponding bone. So for example, the arm was made up an upper arm mesh, a lower arm mesh, a hand mesh, etc, all of which being separate objects that would be parented to separate bones. The reason I attempted this approach was that it would save me a good deal of time by eliminating the need to join all the pieces into one mesh and weight paint them to their corresponding bones. This all seemed to work fine and dandy in Blender but when I brought one of these character assets, who we’ll call ‘Bob’, into Unity, I noticed that something was awry.
In the Unity editor, I entered Play mode and ran around with the player character, inspecting Bob as he was cycling through different animations. It was at this time that I noticed that some of the mesh body parts belonging to Bob were occasionally not being rendered when they really ought to have been. And so began a long and arduous process of trying to figure out just what in the … heck was going on. The other character, who we’ll call ‘Marcus’, had pretty much the same set up as Bob so I imported him as well to see if I could duplicate the issue. Alas… no dice, the issue was not duplicated. However, I did take note of the one difference between the two characters which was that Bob was significantly larger than the player while Marcus was a bit smaller. This observation would later make sense.
Since the strategy of parenting individual meshes to individual bones was new and experimental, I figured that the problem likely originated from there. So I went back to Blender, joined all the parts into a single mesh and just did a quick rig with automatic weights. When I brought this new version of Bob, who we’ll call Bob 2, back into Unity, I found that the problem was now negated… “Ah ha!” I exclaimed as I caught the eye of this most devious enigma, “A clue!”
Now that I had these two seemingly identical yet different models, with one rendering properly and the other not, it was time to start getting down to the DNA of these butthole surfers and finding where the discrepancies lay. With both models in the scene, I cracked into their hierarchies to inspect their contents. As expected, Bob was composed of his many meshes and Bob 2 composed of just the single unified mesh. As I selected these meshes within their hierarchies, I noticed that gray boxes were appearing around the meshes with which they corresponded. I had seen these boxes before but had never given much thought to them. As it turns out, these boxes are are generated by the Mesh Renderer component and are only displayed when a mesh is selected in the Hierarchy window. I felt another raging clue coming on…
In Edit mode, Bob and all of the other characters stand in T-pose. I selected all of Bob’s meshes within the Hierarchy window and all of his Mesh Renderer boxes were displayed in the Scene window in his same T-pose. With Bob 2 selected, there was just one large and encompassing Mesh Renderer box displayed. For the sake of science, I hit the play button and made the most important discovery yet. As Bob cycled through his array of animations, his Mesh Renderers remained in T-pose despite the movement of the actual meshes. The Mesh Renderer T-pose itself would wriggle around a bit, but I’m assuming that’s because of Bob’s root node swaying around during animation. As I ran up with the player for closer inspection, enlightenment took me into its embrace and held me close to its warm bosom.
While keeping an eye on the Scene view, I noticed that when one of the Mesh Renderers exited the view frustum of the main camera, the mesh that it was attached to would disappear from the Game view. So even if the mesh was directly in front of the player’s face, if that mesh’s Mesh Renderer component was outside the view frustum, then it would not be rendered. The reason why Marcus was being displayed in his entirety was because that even though he was made up of many separate meshes, his T-Pose was small enough that we would inevitably be rendered in his entirety.
VICTORY FOR SYLVANAS
So anywho, lesson learned. Stop being lazy, join your meshes together, and weight paint that shiitake. Another thing I noted is that you can actually keep the separate mesh rig and tweak the Mesh Renderer dimensions but I’m thinking that it would be best to use that method sparingly… if ever. You know what, no, just don’t.
In the meantime, I’ll be getting back to the old drawing board. Please feel free to leave a comment or question or anything else that you want to get off your chest. See you next month!