I was all set to leave the environment pack for a while. I’d been working on it for so long I needed a break.
While working on, and enjoying, the character design process for the synth security droids (see posts below) I began to grow uneasy.
It felt bad to release the environment pack but not follow up, as soon as possible, with an update. Great, the assets may be, but they can always do with improvement. I have a roadmap for where I want the pack to be in a few months. I will be increasing the price accordingly, as I add value to reward the early adopters.
One area I felt was lacking was support for Unity 5’s shiny new PBR standard material.
I’d started work on the pack way before PBR had gained such traction in game engines as it does now. Back then it seemed best to develop and write my own custom shaders – which I duly did, and they ship with the pack.
As good as those shaders are, they are old tech and Unity 5 has been out a while now. Other developers on the Asset Store are converting their assets to U5 so mine will look a bit dated (already!) if I don’t move quickly.
Happily this move to update to PBR dovetails nicely with something I’d planned to do all along: Substance support.
I’ve used Substance Designer from the start of this project (since version 3, in fact) and I love it. I love the node-based workflow and how solid and non-destructive it is. The learning curve is steep but the rewards are great.
So the textures that I develop for all my assets are usually baked (normals) then assembled into Photoshop. I link the Photoshop file to Substance Designer and start a graph to develop the texture maps I’ll assign in the game engine. The only thing missing is to allow my users to teak those textures.
This requires unleashing the full power of SD, not just as a texture map tool but as a conduit to allow artists and designers to tweak and customise game assets – in the game editor itself.
The pictures here reveal some of the process and the difficulties I’ve been encountering. It turns out that my way of working when I was merely using it to make textures is quite inefficient when it comes to exposing parameters to end users for tweaking.
All of the screen grabs shown here use my space barrel prop as an example. My early graph shows the stepped left-hand side to the graph showing my ‘layering’ approach to building up my texture.
It worked wonderfully well but restricts the workflow a bit when it comes to integrating weathering effects, which I’d like to offer to users. Changing the colour and roughness/smoothness of materials is quite straightforward. See the shot of the new barrel variants lined up in Unity.
That didn’t take very long. The custom decals took the most time.
The other graph show a messy work-in-progress version of the barrel that is easier to manage and, surprise surprise, mimics Allegorithmic’s own workflow pattern.
Not everything is shown in the one graph, however. There are other, simpler, nested graphs unseen. So the node count will possibly be comparable with my earlier effort but, I hope, it’ll be easier to work with.
The end result of all this will be that end users will have assets that can easily switch between using my custom traditional shaders, the new PBR standard shader PLUS! the ability to customise the look of the assets to an almost infinite degree. A fairly substantial update, I’m sure you’ll agree.
The droids will take a back seat until this update is released.
Soon I hope.