I came across this post on the Reddit sub r/Generative the other day and thought that u/ivanfleon had done something both relatively simple and also very cool. I had some ideas for generative glyphs and started by mimicking his sample there, thus was born the RectGlyph:
The interface came shortly after RectGlyph was done as I was trying to troubleshoot work on the PolarGlyph. It made it easier to see what sort of variations could be had, but also allowed debugging to be more visual (which really helps me a lot).
I’ve always been fascinated with languages, both real and imagined. As I was working toward my PolarGlyph idea, I stumbled upon a few happy accidents, such as the RunicGlyph.
And also the AngularGlyph:
And eventually worked out the kinks for the PolarGlyph:
I have a few others bring worked on, as well as some ideas regarding an editor so you can take your randomly generated glyphs and add line segments to or remove them from any of the glyphs in the set.
My pie-in-the-sky idea is to also be able to save them as a TrueType font so that they can be used in Unity (or anywhere), and possibly to save them as an SVG or vector sheet for use in various vector-based software.
I’m planning a series of very brief micro-optimization notes, both for my own records and to help anyone else who may be looking at some optimizations. I plan to provide minimal code, results, and brief explanations.
In this case, I came across a bitwise |= for setting a done flag in one of Penny de Byl’s Udemy courses. I was curious and decided to see if it was an optimization. It felt like it would be, but I didn’t expect by much. Sure enough, it is, but not by much. Still, if it’s a function that you have a lot of while-loops in your code checking against a boolean value, it could be handy.
static void Main(string args)
for (int i = 0; i < 10; i++)
static void DoneTest1()
bool done = false;
int x = 0;
int xSize = 100_000_000;
done |= (x < 0 || x >= xSize);
static void DoneTest2()
bool done = false;
int x = 0;
int xSize = 100_000_000;
if (x < 0 || x >= xSize)
done = true;
Using done |= : 112ms (1122354 ticks).
Using if : 151ms (1518356 ticks).
Using done |= : 107ms (1073112 ticks).
Using if : 129ms (1298421 ticks).
Using done |= : 127ms (1275415 ticks).
Using if : 141ms (1414998 ticks).
Using done |= : 111ms (1112100 ticks).
Using if : 127ms (1273705 ticks).
Using done |= : 108ms (1086612 ticks).
Using if : 140ms (1400030 ticks).
Using done |= : 127ms (1271739 ticks).
Using if : 128ms (1282120 ticks).
Using done |= : 108ms (1089749 ticks).
Using if : 111ms (1118823 ticks).
Using done |= : 108ms (1086191 ticks).
Using if : 110ms (1100477 ticks).
Using done |= : 100ms (1002949 ticks).
Using if : 113ms (1131274 ticks).
Using done |= : 104ms (1040928 ticks).
Using if : 110ms (1101986 ticks).
Each iteration shows a better performance using the bitwise |= compare and set rather than the if-statement. Across the ten iterations, the bitwise averaged 111.2ms while the if-statement averaged 126.0ms which amounts to a ~11.75% increase in performance. The bulk of the time in each set is, of course, the computer counting to 100,000,000, but given that the only difference in the two methods is the check for setting the flag, the variance is accounted for by that difference.
Bitwise operations on most architectures are almost always faster than other calculations, and branching statements are typically computationally heavier. When bitwise operations are an option, they usually result in more performant if less readable code.
For those of you not familiar with benchmarking in C#, I typically use the .NET Stopwatch class (System.Diagnostics.Stopwatch). I’ve removed the Stopwatch() code for brevity in the code example above. So long as you Start, Stop, read, and Reset your stopwatch in appropriate locations, you don’t need to worry about setup and other functionality as the only portion times is what is wrapped between Start and Stop.
I also run the program (usually a .NET Core console application) as a release executable rather than a debug executable to ensure performance isn’t being bogged down by the debugger for any reason.
Lastly, I try to run ten (or more) iterations of each thing that I’m testing. As you can see in the results, timing can vary for all manner of reasons. Sometimes the first execution of a code block is slower than subsequent executions. I also try to interleave each method or function being tested (e.g.: 1, 2, 1, 2, 1, 2, 1, 2 rather than 1, 1, 1, 1, 2, 2, 2, 2) to help ensure the code block isn’t being cached and repeated. Running only a single iteration is often misleading. In this case, all ten iterations of the bitwise comparison were faster, but it’s often the case the the slower of two methods might have a small percentage of faster executions and running single iteration may provide incorrect information about which is typically faster.
Back to working on Labyrintheer. But it’s Unity 2020, and I’ve been interested in playing with ray-tracing (RTX), so I started a new project, brought in some old assets and started toying with it.
The first entry is the trusty Gel Cube (from InfinityPBR) with RTX materials applied. This one is only lit by the internal point light that dies off when it dies. This is both of the attack animations and the death animation without scene lighting:
The next is with scene lighting. This is where RTX really shines with colored shadows cast through the transparent material of the GelCube:
The video quality isn’t as good as I’d hoped – need to work on that a bit.
Really, working with RTX in Unity’s HDRP isn’t terribly difficult, but there are a variety of gotchas that make it a bit of a headache, and materials are set up significantly differently (as are lights and scene volumes and…) That said, I plan to work on a few creatures first, just to get a feel for it all, then move on to bringing in the dungeons under RTX. Should be fun!
For those new to coding, or folk who want to exercise their brain cells a bit, check out this year’s Advent of Coding 2018. Each day offers two puzzles to flex your coding skills, build new skills, or just generally put into practice your code-fu. They are language agnostic, and often quite interesting.
If you want to join a private leaderboard, my code is: 427712-b8e50570 . Feel free to join.
I also have been posting my own code to GitHub here. It’s not pretty, and definitely not always the best approach, but I’ve been tackling each day with an idea for how to solve it rather than trying to find the quickest solution – usually with some robustness in mind that would make the code more flexible and allow for it to be used in other circumstances. Not sure why… just how I roll. I also haven’t been cleaning up after myself. If I go down a path that leads to failure, it’s usually still there and either commented out or just not executed. Since this is sort of a sandbox event for me, take any code I have in that repo with a grain of salt. All days are currently in C# and for Visual Studio for Windows, though I may slowly put together some Mac console apps and Unity stuff in C# as well.
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.
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.
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.