Making Materials and Models! Mmmmmmmm (M)Normal Maps?

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.

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:

Demon Head Emboss - Coin Face
Demon Head Emboss – Coin Face

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.

Substances, Dungeon Floors, New Workflow

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:

Attempt 1
Attempt 1

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:

Attempt 2
Attempt 2

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:

Attempt 3
Attempt 3

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:

Attempt 4
Attempt 4

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.

Random Class, Singletons, and the “Big Debate”™ (does this sound familiar?)

A few weeks ago I wrote a VERY similar post about my Logger class and the debate over the use of Singletons.

I’ve done the same with my new randomization class, LRandom().  LRandom does several things under the hood, and is a singleton for a very specific reason.  First, I wanted to use it to replace the random class that Dungeon Architect uses during initialization of a dungeon or map.  In part because I wanted more control over randomization, and in part because I wanted all aspects to produce the same values with the same seed.  Previously, at least in earlier versions, DA would produce the same dungeon layout, but things like decorations and extras would not always be the same.

Additionally, I wanted the same random class to be able to control other randomizations during play: loot, die rolls, et cetera.  The current implementation uses a single System.Random instance, though I may extend this to have several – one for dungeon building, one for loot, one for mob AI, and so forth.

Also, the state of the System.Random is stored in a serialized file on exit.  This should, in theory and after a lot more work, allow one to pick up where they left off with the state of the randomizer where it was before.  The main goal here is to prevent “known randoms” with the given seed.  The first chest you run across won’t always have the same stuff.

The class also contains the original DA methods for NextGaussianFloat() and GetNextUniformFloat() to integrate without changing a lot of the DA code.  And lastly, it contains methods that allow the instance to be reseeded if need be, which is mostly good for debugging, but may have benefits during runtime as well.

So, currently, LRandom() and LLogger() are two singletons that I’m using that have proven very beneficial.  If you missed my last post, or want to hear more about Singletons (the good, the bad, and the ugly, so to speak), check out this great podcast from The Debug Log- Episode 73: Design Patterns: Singleton.

How To See Your Player… Making Walls Transparent

Over the past several months working on the Dungeon theme for Labyrintheer, I’ve changed my camera angle several times.  I keep moving it higher to prevent walls and such from occluding the player, but I’m never happy with such an oblique view.  So, over the past few days I’ve been looking at options to make walls transparent when they are between the player and the camera.

Some solutions simply disable the geometry.  This isn’t acceptable for my game, and I suspect for many.  You could accidentally walk backwards out of the playable area, or an errant AI could take a bad turn during it’s pathing and fall off the world.  Plus, disabling geometry just doesn’t seem like an elegant solution.  My primary goal (and I’m still working on it) is to use a shader for this directly, though that seems like it has some major pitfalls (how do you tell a shader about an object other than the one that it’s drawing?).

So, for now I’m cheating with a very small amount of code and an extra material for objects that I want to hide.

Basically, I’ve duplicated the four wall materials I have, and the duplicate materials use transparency with an alpha value of 100.

My player controller script now calculates it’s distance from the camera every frame (though I think this might be able to be done once in Awake() since the distance should be fairly static), like this:

     void Update ()
     {
         GetInput();
         ProcessInput();
 
         distanceSquared = (transform.position - Camera.main.transform.position).sqrMagnitude;
     }
 
     public float Dist()
     {
         return distanceSquared
     }

Then created a script to go on the walls (or any object that needs to be transparent to prevent occlusion), as such:

TransMaterialSwap.cs

 using UnityEngine;
 
 public class TransMaterialSwap : MonoBehaviour {
 
     public Material _original;
     public Material _transparent;
     private GameObject player;
     private playerController pC;
     private Renderer rend;
 
     void Start()
     {
         player = GameObject.FindWithTag("Player");
         pC = player.GetComponent<playerController>();
         rend = this.GetComponent<Renderer>();
     }
 
     void Update()
     {
         if ((transform.position - Camera.main.transform.position).sqrMagnitude < pC.Dist())
         {
             rend.material = _transparent;
         }
         else
         {
             rend.material = _original;
         }
     }
 }

In the inspector I set both the original material and the transparent material.  If the object is between the camera and the player, it switches the object’s material to the transparent material.  It looks like this:

There are a few issues here.  First, I still need to profile this to see if the solution gives my runtime performance a hit.  I don’t suspect it’ll be TOO bad, but it doesn’t hurt to check, especially with larger maps.  I may look into options to only run the check if the object is visible to the camera rather than always checking on Update(), every frame for every wall.  The other issue is that by making it transparent, light comes through.  I’m not sure how big an issue this will be – it’ll require some play testing.  But it may be an issue in some situations.

Lastly, as I said, I really do want to attempt this in a shader.  I figure it’s a good method to learn shader programming, even if exactly what I want isn’t possible.

Logger Class, Singletons, and the “Big Debate”™

So I’ve spent a bit of time working on getting a logger class setup, which is rudimentarily complete.  This class currently just writes out to a file and also to the debug console in Unity.  It takes in a message, a module, and a severity.  I wanted to easily have access to this class from anywhere, but since it writes to a file, I also needed to ensure that there was ever only one instance trying to access the file at a time.  This, of course, led to the singleton pattern.

Now, even a cursory glance through newbie programming blogs and books can cause one to question why this is even a pattern to begin with – it seems that everyone says to stay away from them, and I kind of understand why you don’t want to overuse them.  The Debug Log has a pretty good episode about them here.

So, singleton was the answer, and it was setup nicely enough and it works, though I still need to make it threadsafe.  But… logging:

LOG!
LOG!

So, now it’s back to work on the game itself.  I have most of the systems in place to get a sample level up and running soon.  Yay!

Dungeon Layout Metrics

So, for the current branch of changes, I’m working on level layout, design metrics, and baseline functionality.  What does all of that mean?

Layout Metrics and Design
Layout Metrics and Design

In the above photo, I have a nearly perfect layout.  The spanning tree options have kept the start (blue dot – bottom right) and end (red dot – center) pretty far apart.  The blue dot is the actual portal where the player would enter the level.  The red dot is just a red colored portal, but that portal is a marker for where the boss room will eventually be.

Of course, since everything is randomly generated, no two levels will be completely alike.  Unfortunately, that means as I change things up or even hit a seed I don’t like, things can go south.

Too Much Spanning Tree
Too Much Spanning Tree

The above shot is with a bit more weight on the spanning tree node.  There’s still a nice long path between start and end, but there are also long hallways that loop too far around (for my taste, at least).  Actually, the above example isn’t awful, but these images are the same seed, the first with 0.05 spanning and the second with 0.15.  While the spanning value may be static on all levels, there may be some small fuzziness around those as well.  Trying to find boundaries is more of a balance than I expected.

Other than basic parameters, I’m trying to prevent barrels from spawning inside of walls:

Barrel Wall
Barrel Wall

Or in large groups that get in the way:

Too Many Barrels
Too Many Barrels

I’ll be working on better “torch flicker” – right now it’s a bit stuttery looking, and I’d like it to be smoother and look more like an actual torch.  Then a few more mobs, the boss spawn, and some more decoration for the level.

Archimatix: A New Tool and Some Thoughts on Labyrintheer

So… how’s things?  Yeah, that’s cool.  I’m over here playing with Archimatix (AX) and it’s pretty much the best thing ever.  I’ve been watching this great tool develop over the past several months (though the dev has been working on it for much, much longer than that), and I have to say that I am incredibly impressed.  I’ve been fooling around with tutorials and random stuff for the past day to see how things can fit into Labyrintheer.

If you recall my earlier posts on the topic, I am not an artist.  I am especially not a 3D modeler.  Much of what I’ve been able to accomplish thus far has been thanks to the incredibly awesome 3D assets provided by InfinityPBR.  I’ve seriously considered how I’d ever get those sweet, custom models for some of the things I’ve considered in Labyrintheer over the past few years, and AX is the answer (I hope).

I’ve been messing with some of the node types just to get a feel for it, and one of the things I wanted to be able to do was some oddly modern, organic shapes as structures and “art” statues in some areas – mostly towns and wilderness, but not so much dungeons and caves.  This was my first attempt at using the FreeCurve node to knock out from a block and have a very open and extremely simple thing.

Ignore the robot – I don’t think that Labyrintheer is going to have robots.  But Robot Kyle is the AX spokesbot and it here just for scale.

While this won’t make it into the game, I don’t think, I plan to use this concept to create monoliths that showcase the twelve elements in the game.  This was actually an attempt at using something like a freehand drawn Fibonacci spiral as a cutout.  It didn’t do quite what I expected it to, but that’s part of the true fun with AX…  the things that don’t work the way you expect, but give you interesting new ideas.

At any rate, I’m sure I’ll be posting about AX now and then and maybe even showing off some assets that could end up in the game.  But for now I cannot recommend Archimatix highly enough for any Unity developer or artist.  It’s an utterly fantastic tool.

Shout Out – Kingsway OSRPG

I’m a sucker for unique ideas and people bucking the status quo.  Today, I read about Kingsway for the first time.  The idea of an OSRPG (Operating System Role-Playing Game) is definitely unusual.  I’ve played an RPG built entirely in Excel.  That was pretty unique.  But a game that mimics an operating system makes me smirk.  Of course, how enjoyable it will be is yet to be seen, but kudos to Andrew Morrish for a new twist in gaming.  I’ll be keeping an eye on this.

Sidestepping

It’s been a bit since I posted last, but that doesn’t mean nothing has been happening.  There’s been some good progress on controls (which is actually kind of a pain in Unity), some work on mob AI (they attack now, animate properly, and even have sound), and some various fixes and clean ups in the code and the project base.

Additionally, I’ve started a second project that I hope will eventually be used in Labyrintheer, as well as be available for anyone to use on the Unity Asset Store.  More details to follow, but I’m hoping to have a really complete and useful package.  Only time will tell, I guess.

Lastly, the second project won’t consume all of my development time, so there should still be (semi-)regular updates on the blog about what’s going on.