For those who may have been following since before this blog began, you may have seen the Iceglow Gel death sequence that includes the possibility of spawning smaller Mini Iceglow Gels. This was, by and large, a stroke of sheer genius on my part (yeah yeah yeah, just let me have this one). It seemed like a cool idea and has led to some other cool ideas for deaths with other mobs. In fact, each mob has a DeathScript requirement, even if it’s just to, you know… die.
But this has also been a thorn in my side. When an Iceglow dies, there is a major stutter before the new minis are spawned in. I finally decided to toss up the profile to see what was going on, and decided to write this brief post on profiling, because damn, it’s handy!
For those new to Unity or development, the profiler is a pretty common tool used to “debug” the actual running game. It can attach to a development build for better and more accurate profiling, but if you’re simply looking for bottlenecks where the definitive time and resources aren’t as important as discovering the spike, you can also simply attach the profiler to the editor itself.
This was a capture at the time of the resource spike right when the Iceglow dies.
The details of CPU usage show that the >1s spike is caused by the PhysX core baking the mesh for the minis. I was hoping that, since this was running in a coroutine, that it wouldn’t impact the whole of the game. Maybe I’m doing it wrong (or, at least, not the best way). Maybe I can pre-bake those meshes. Maybe I can use simple colliders instead (a cube is far easier to calculate). I’m just delving into this, and I’m not sure what the best solution is yet (stay tuned for updates on that, or follow my plea for help), but for now, the profiler is my handy tool to figure out what calls are b0rking the game.
Easily as important as debugging code, and definitely more important for tuning, I can’t recommend highly enough learning to love your profiler.
As a lesson, today I taught myself that sometimes your first (several) attempts to Google a problem just don’t do the trick. For several weeks I’ve had an issue where my mobs just zoomed around like they’d been snorting magic dust, completely ignoring the values set for them with regard to speed, acceleration, et cetera. It happened fairly suddenly, I wasn’t sure why, and many attempt to fix it failed.
I Googled this issue many times over the weeks looking for an answer. Nothing relevant ever seemed to make it into my search results. It became frustrating!
Then, on a whim, I searched once more for the answer, clearly using a better phrase, and Google’s magical algorithm finally decided to lend a hand. Of course, the answer was something dumb on my part. At some point, the isKinematic boolean flag on the rigidbody component became unchecked, which meant that the rigidbody and the nav mesh agent were in a race condition, both trying to control the movement of the mob.
But, NO MORE! My gel cubes gracefully slog around the dungeon biome again, and the War on Magic has been brought to a halt.
One checkbox took weeks to resolve. Probably a n00b issue, but a good lesson all the same.
Not being an artist can seem like one of the most daunting parts of going it alone (or mostly alone) as an indie dev. I’m a fair photographer, but that’s as far as my artistic capabilities have previously taken me. Most of my stick figures look, well… disfigured, and things like straight lines are as simple for me as writing in Martian. But I’ve been really working to increase my skill set here, and be able to create things in Labyrintheer that actually LOOK pretty decent.
In light of that, I started by picking up some great models from InfinityPBR. Andrew, the awesome dude behind iPBR (as I reference it for myself) includes some great PBR materials as SBSAR files (and recently SBS files) that really helped me delve into how materials work and what was meant by all of the components: normal, roughness, metallic, height (or specular and glossiness depending on your preferred workflow); metallic/roughness versus specular/glossiness; and a bit about what all of those components can do.
But this wasn’t enough customization for me. As I’ve mentioned before I started using Archimatix to design some architectural models (which is still something I’m getting a handle on, simply due to the sheer variability of AX and its nodes). As I worked through some (very simple) wall models and such, I realized that I also wanted more control over the materials themselves. iPBR offers an INCREDIBLE amount of customization, but I’m just a pain in my own arse that way. So the next step was… Substance Designer.
For those new to the art game, Substance Designer is an amazing software package that lets you node-author your own materials and export SBSAR files that can be used to procedurally create materials in Unity (and I believe Unreal Engine).
The beauty of the node-driven design is that, while artist-type folk seem to settle into it easily enough, we logic-driven code monkey types can also create some really stunning work since everything can be reduced to parameters and inputs and outputs. But before you can do any of this, you need to grasp some of the basics. I’m not high-speed enough yet to really offer a tutorial, but I can share the wealth of tutorial love that I’ve been using. So, let’s start with normal maps.
I ran across this tutorial literally this morning, which is what brought me to create this post and share this info. More blog post, less actual tutorial, the information about normal maps here is presented concisely, tersely, and with excellent clarity. Even someone who has never heard of a material in game parlance before can probably understand what’s being explained.
The gist of normal maps is to provide interaction between the materials and light in your scenes. This is not the same as metallic/roughness aspects, but more to “pretend” that there’s dirt, smudges, small deformities or other similar features on your object. When making a material, you often preview it on a perfectly flat surface. But you still want to see the details – details that offer a 3D appearance on a completely flat 2D plane. This is where normal maps come in.
Let’s look at the image below, for instance:
This is meant to be the head of a coin I’m working on as sort of a self-tutorial. The eye can easily see this as an embossed image, but due to the normal map, moving the light around changes how and where shadows happen. Here the light is off to the left, so left of the “ridges” (it’s still just a flat plane) looks brighter, and right of them produces shadows. If I were to move the light source to the other side, the opposite would be true. This is how normal maps help reinforce the 3D appearance of an object that doesn’t have detailed modeling done. This is a HUGE benefit to game performance – it’s much easier to draw a coin that is perfectly flat on both sides, and apply this material to make it appear 3D than it is to produce a 3D model with this level of detail. Easier both in actual creation of the object as well as on your GPU for rendering it.
This video shows the coin in Unity. The scuffs and scratches are both part of the base color of the item, but the deeper scratches are also mostly in the normal map, and allow light to fall into them or be occluded from them based on the light angle. Note that in the above video, the edge of the coin are NOT flat, those are actually angled on the model itself. That would not be a great use of attempting to use normal maps to provide a 3D effect (at least not in any way I would be able to do it).
That’s what I have for normal maps, for now. But I plan to continue this as a growing series of posts on PBR materials to help demystify them for those of us new to this whole thing.
I’ve picked up Substance Designer and have started working on some better assets for the Dungeon biome. Right now what I have is a bit busy, but I thought I’d share some of what I’m doing. I started with a great tutorial on Youtube, where the presenter was kind enough to offer up his SBS file. I made a variety of modification and exposed some parameters, kicked out the SBSAR and loaded it into my staging project in Unity.
I created three separate materials and applied them to their own GameObjects that Dungeon Architect uses to generate the floor. Right off the bat, it looked like this:
Like I said… busy. But at least it’s more interesting than what I had before. I decided to up the game by adding a random rotation – each floor is randomly rotated by 0, 90, 180, or 270 degrees. That looked like this:
Still busy, but at least a little more random. Then I felt that the stones shouldn’t always be the same size, so I set each to have slightly different numbers of tiled stones per object:
Lastly, it still seemed too busy, so I lowered the overall count of each. One was 4×4, one 5×5, the last was 4×5 making some stones also not square. That looks like this:
Now it’s less busy, more random feeling, and looks decent. I think I’ll probably go back to the Substance a bit and see what I can do about breaking them up a bit more, but for my first modification of a substance I’m pretty pleased.