As I mentioned on my Patreon, as part of my materials studies in Substance Designer and Blender, I really want to work on crystals and gemstones. I’ve been collecting quite a few reference images on this Pinterest board over the last few months, and have decided that the first one I’m going after is the strawberry quartz.
I have a few ideas for how to best do this. I’m initially working in Substance3D to create the surface material, but I’m also planning to use a volumetric shader combined with the surface shader in Blender to create an effect that looks more like the quartz. Those red veins are not just on the surface!
So, for my first iterations of both surface materials and volumetric shaders, I have the following first six WIP attempts:
#1 was just the first run at the surface shader. It’s a little too busy, and both the quartz and the veins are running a little too much toward pink.
#2 added a multidirectional blur to calm down the veining a bit.
#3 added the roughness and metallic channels to the texture and drove the veins more toward red.
#4 was a touchup to all of the channels, but the UVs on the model were also not right on two sides (visible on the left side in the image). It also added the initial volumetric pass inside the crystal.
#5 minor touchups.
#6 fixed UVs, fixed up some coloring and the density of the volumetric pass.
So, during these steps, widescale changes were made in Substance to the material textures themselves. In Blender, after getting Cycles setup the way I wanted, I made some minor detail changes to both the volumetric and surface shaders. There’s still a lot of work to be done, but not bad for a little bit of time in the morning.
FWIW, the blue cube in the background of the renders is there simply to verify the level of transparency. I’ll probably change the setup some so that there’s a white/50%/black background with some frosted lighting coming in from underneath and slightly to the front. The surface itself looks pretty decent, though I’m sure there will be some fine-tuning. The major changes I think still need to be made are in the volumetric shader aspect.
Something I’ve been wanting to work on for ages, and one of the key reasons I’ve started playing with Blender, is a great, fully-modeled alchemy lab or wizard’s lab. I wanted to model and skin every component from scratch, create appropriate lighting, and eventually animate a small scene.
That effort has begun…
In some cases, there are currently placeholder materials – currently just the walls and the ground. And everything is iterative in that I will likely go back to each piece over time to tweak models and materials as the scene (and my skillset) grows.
The very first thing I started modeling was a small double-bubble glass container for liquids. It turned out pretty nicely so far – standing at 0.299m tall (~11.75″), not including the cork. Doesn’t every alchemy bottle need a cork?
Double Bubble Container
The red coming through is just a red cube I was using to get the alpha, transmission, and IOR dialed in. In this case the container has water in it. I also wanted to play around with some odd glowing liquids, so I just threw together green and red options as more of a quick placeholder.
Double Bubble with glowing liquids
I figured the next step was that I needed to make a table to start putting stuff on. Since reference images are an amazing tool, this is the reference I was using for the table.
Alchemy Lab Simple Table Reference
Pretty simple, but it looks sturdy and timeless. I still plan to add the braces along the bottom and top of the legs, but for now I’ve got this:
Alchemy Lab Simple Table
I had a lot of fun with this one. While it adds complexity (and render time), I wanted the planks of the table top to be slightly different. Each one got a light level of deformation – small chunks removed, larger gouges, and other things that were better modeled than added via normal maps. Then using a single wood grain texture, I unwrapped the UVs for each plank and each leg and applied those unwrappings to slightly shifted areas of the texture. So one texture, but nine different results for how they appear. This adds to the feeling of a real table – all made from the same type of wood, but not with identical grain, which would be an odd thing to see.
Alchemy Lab Simple Table
Not a particularly great render, but definitely give the idea of what I was going for.
Next on my list was a coil candle, sometimes called an hour candle since you can control how long a segment burns before going out. My mom had one or two of these in her antique collection when I was a kid, and I remember thinking that it was just a really cool way to have a light source and a very rough timer at hand. Reference image:
Coil Candle
This has been what I’ve worked on the last couple of days. I ended up using Blender Rookie‘s tutorial on making a coil as the jumping off point.
Coil Candle with Brass Dish
I was able to get a rough shape for the candle, and added a brass dish for the start. I actually still have that little tail at the bottom to fix up, and a variety of details to add, but progress was still made. I added the brass spindle and the mechanism used to “stop” the candle, as well as bending the top of the candle upwards, adding a wick, and a small flame… a flame that also still desperately needs some work.
Coil Candle
There’s still some work to be done on this. Probably adding small bits of wax to the dish, definitely adding feet to the dish, and possibly a small handle. I’m also considering adding a glass baffle.
So far, there isn’t much. Given that this is all a learn-as-I-go process, it’s slow. I’m sure it’ll pick up quite a bit as I move forward. At least I really hope so lol. Right now, the scene as far as objects go looks like this:
Coil Candle and Double Bubble on Simple Table
Some things I plan to add:
A variety of jars and containers, glass, leaded glass, clay and ceramic.
A “lab” setup – small distiller and other chemistry/alchemy equipment.
Additional light sources – I’d like the entire scene to be lit via ray-tracing with Cycles, all from actual light sources: candles, sconces, torches, weird glowing objects, et cetera.
Various furnishings: tables, wall-mounted items, chests, shelving.
A hearth/fireplace of some sort, possibly with some basic cooking items
A banner or two, as I definitely want to also work with cloth
Animations – currently the candle flame is animated, but it sucks. I’d also like to have the light source for flames flicker and move with the flames themselves. I had done this for wall sconces in Labyrintheer programmatically, but am still trying to find the best way to go about this in Blender.
Packaging: If this actually works out well, and a good collection comes into being, I’d like to possibly sell this as a package, ready to go for Unity and Unreal as a sort of kitbash type of deal. Who knows how long it will take, but a production-ready kit is definitely a goal.
So, I’ve been working on a game idea (yeah, I know, I haven’t actually completed any games thus far… my bad!), and have created some place-holder graphics for testing a few game mechanics. In other words, the visuals are not a permanent sort of thing. However, one of the mechanics will require some programmatically generated sprites to come into being as directed by a UI window the player will be presented with.
The basic setup is like this: The main game visuals are using Unity’s Tileset feature. The grid has (currently) three overlaid tilemaps: ground, ground shadows, ground clutter; the clutter being grass and flowers and other non-interactable bits for visual effect. Each tilemap moves up one in the z-sort order and all but the ground layer are using alpha transparency.
The programmatic sprites will be one z-sort layer above those (and below the player/NPCs) and is displayed at a target transform called CircleTarget. The initial code looked like this:
if (tex == null)
{
tex = new Texture2D(256, 256);
tex.alphaIsTransparency = true;
Color c = Color.red;
for (int x = 120; x <= 130; x++)
for (int y = 120; y <= 130; y++)
tex.SetPixel(x, y, c);
s = Sprite.Create(tex, new Rect(0, 0, 256, 256), new Vector2(0.5f, 0.5f), 32f);
CircleTarget.GetComponent<SpriteRenderer>().sprite = s;
}
This was intended just to put a small red square down where the CircleTarget lives, but instead I was just presented with this:
Ah, you need to apply changes – but also need to set things up for transparency. So, let’s try this:
if (tex == null)
{
tex = new Texture2D(256, 256);
tex.alphaIsTransparency = true;
Color c = Color.red;
Color a = new Color(1f, 1f, 1f, 0f);
for (int x = 0; x < tex.width; x++)
for (int y = 0; y < tex.height; y++)
tex.SetPixel(x, y, a);
tex.Apply();
for (int x = 120; x <= 130; x++)
for (int y = 120; y <= 130; y++)
tex.SetPixel(x, y, c);
tex.Apply();
s = Sprite.Create(tex, new Rect(0, 0, 256, 256), new Vector2(0.5f, 0.5f), 32f);
CircleTarget.GetComponent<SpriteRenderer>().sprite = s;
}
Ah, much better, however the red pixels are surrounded by a buffer of whiteish/alphaish pixels. Of course, if you have existing sprites that you’re importing into Unity that use alpha and you want pixels to look precise, we need to change how they’re filtered. For programmatic sprites, you need to do the same thing.
tex = new Texture2D(256, 256);
tex.alphaIsTransparency = true;
tex.filterMode = FilterMode.Point; // Add this line
...
And now we have a properly transparent background red square placed at our target location.
I’m a big fan of programmatic generation of meshes, sprites, and really everything. It makes the overall footprint of the game smaller and often consumes no more memory or processing power than what you’d have anyway – not always, but often. In this case, the programmatic option is actually significantly better than having a bunch of predesigned objects as sizes can be calculated on the fly and the variations that I plan for won’t require any palette-swapping, or even any palettes at all since it’ll just be stored in code. Generation of pixel art on the fly really opens up how this game mechanic can be used. I’m sure there will be more posts on it down the road – keep an eye out.
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!
It’s been several months since my last post. That isn’t to say I haven’t been slinging code, but as I’m sure you all are feeling as well, this pandemic has really put a damper on mental clarity. Over the past several months I’ve come to a few conclusions: Labyrintheer is not mothballed, but is also on the backburner; this will become my devblog more generally for game dev and other code-related (or even tech-related) posts; and I need to post a lot more.
I’ve been considering creating some tutorials, both here and on YouTube, possibly with a Patreon backing options for additional content. I’ve also considered some small courses for Udemy. I might test the waters of all of the above to see what “feels” right for me.
All of that said, there should be more regular content being pushed out here, and I hope to see you all around. Thanks!
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.
So, I know I said “my bad” last time, and that was six months ago. But, Labyrintheer development has actually kicked back off and progress is being made. Prior to giving it a break, I had two nagging issues that I couldn’t overcome.
#1 – the small one. All chests that could be looted (advanced props) have a model and animation path that starts with them open (sort of in their T-pose). The first thing that happens on instantiation was that they close, and in doing so, play the appropriate sounds. It was a loud and obnoxious thing – small, but annoying. Anyway, that’s been dealt with.
#2 – the big one. Both the player and mobs have evolved over my time with Labyrintheer. They started with CharacterControllers because, well… they’re easier in a lot of ways. But, despite literally weeks of effort, I couldn’t prevent the player from climbing atop the gelatinous cubes when they pushed against one another. It was frustrating. And it appears, in part, to have been caused by having both a CC and a Rigidbody.
I started using the Rigidbody because with only CCs, the mobs would push the player around too easily. The fix, at least so far as planned, is to remove the CharacterController components, wire all the player controls to appropriate Rigidbody physics, and probably just not use CCs anymore. It’s not a huge amount of work, just need to get physics movement working (and feeling) right.
All of this is coupled with trying out Unity’s Collaborate rather than my existing git repo. I’ll probably maintain git, at least for a while, but Collaborate really does seem pretty nice, and I don’t have to worry about git vs git-LFS. Let’s see how that ride goes.
Otherwise, I plan to maybe use another platform for bug/issue/work item tracking. Anyone have any tips? I’ve been toying with #Slack, and trying to find a plugin, perhaps, that would work for such a thing. Conclude would be okay if I didn’t mind eight million channels (one for each issue). Maybe there’s a better way.
Anyway, for what it’s worth, I should be posting here much more often. Thanks for hanging around!
A lot of core work on the project has been done over the past couple of weeks – and by core I mean behind the scenes. Yeah, I say that a lot and rarely have something new to show, and this is one of those times.
However, as an independent developer, that’s how a lot of this process goes. I fixed the helium filled GelCube issue, and they seem to be functioning fairly well on their NavMesh. Part of this was competing systems causing race conditions. I toyed with the idea of using physics to drive them, disabling some of the Unity AI stuff, but that led me into a rabbit hole that I wasn’t in the mood to contend with. Instead, I resolved the conflicts and they are now pathing along as they should.
I also added a physics material for them. They’re made out of ice, and should slide around a bit more than other GelCubes and mobs in the game. I’m also testing a fun bit where they may have items from their biome shoved inside them… I mean, they’re likely to pick things up as they move about and grow, right? I’m hoping this is a small detail that is cool in the long run. We shall see.
I’ve started setting realistic masses for Rigidbodies as well. The player has a mass of 81kg, and a full sized GelCube has a mass of 5444kg (who knew they were so heavy, but it does make sense).
Otherwise it’s been more boring: some maintenance to remove old assets that are no longer in play, some scripting for torches, creating static materials from SBSARs now that I have the walls and floors in a good place. Oh, and modifying the Dungeon Architect DungeonRuntimeNavigation.cs file to support multiple meshes for multiple agents. If you use DA and are interested, you can grab that here.
DungeonRuntimeNavigation Inspector
Basically you use an int[] to specify the NavAgentIDs that all your mobs will use and it builds all of their meshes and navigation data at the same time. I know I’m not the only one who wondered for a while why I couldn’t use other NavMeshAgents in my Unity project.
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.
Ice Glow Death Profile 1
This was a capture at the time of the resource spike right when the Iceglow dies.
Ice Glow Death Profile 2
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.
You must be logged in to post a comment.