It’s been a while since we’ve done a blog update, and with the Unity 5.1 release entering Release Canditate status, we felt now would be a good time to talk about the Alloy roadmap, our upcoming versions and changes, and tease some fun stuff.
Alloy 3 Crash Course
To start things out, I wanted to put a reminder here that if you didn’t catch the announcement on the forum thread or twitter, we’ve done a 90 Minute Alloy 3 Crash Course video.
Alloy 3.1 Final update
With version 3.2 of Alloy, we will be moving the minimum Unity version required up to 5.1. With that in mind, we’re doing one final 3.1 update (pending right this moment) with a bunch of handy bug fixes. This package will remain available for download to Unity 5.0x users for the foreseeable future. With the way the asset store functions, if you attempt to download an Alloy update with 5.0x, you will be served the Alloy 3.1.2. If (when its released) you do so with the 5.1x, you will receive the Alloy 3.2 package.
Alloy 3.2 Details
The first thing to be aware of about Alloy 3.2 is that there will be a few breaking changes. Unity has (oh thank goodness finally) added a true HDR color picker. So with 3.2 onward, all Alloy emissive effects (emission, rim, dissolve, etc.) will be using this as an input, instead of our AlloyUtils.IntensityGain setup. The weight parameter will remain, but be moved to an in-shader multiplication so that you can set it via script, and no longer have to manage ‘cooking’ your final HDR color yourself. As some of you likely have fairly complex projects that have carefully authored emission/tint levels, we will provide a migration editor tool that will attempt to read the prior data stored in your materials and migrate it to the new HDR color system (should hopefully be a single button click per project).
We will also be cleaning out some legacy Alloy 3.0 code, namely the old carpaint formulation, old eye code, old ibl brdf, etc. If you haven’t been manually overriding config flags in order to access these (no-one has mentioned to me they are doing so) this shouldn’t effect you at all. If for some reason you are relying on the legacy flags I would recommend you complete that project using the current version of Alloy you have if aesthetic constancy is a priority.
We will also be renaming and condensing a few shaders that you may need to reconfigure/reassign. The hair shaders are being renamed and condensed. Shaders that have a single/double-sided split by shader type will become a single shader with a drop-down. As the set expands, we are always looking for way to eliminate unnecessary redundancy for the sake of clarity and fast workflow.
New Features in 3.2
Now that the nitty gritty is done, lets talk about the fun toys coming in 3.2. I’m happy to announce that (after many requests) Alloy 3.2 will contain a full set of Triplanar Shaders. We’ve fought with these for a while to ensure that things like normal map representation and value blending are the best they can possibly be, and that we’re creating something that functions in a sane perf. window (Triplanar gets expensive due to the sheer number of texture samples).
So with that, we’re working on 4 shader types for the set, each designed for different input sets and performance windows.
Triplanar Full [18 tex samples, 3-9 tex samplers]: This shader is the one pictured above. It has up to 3 different toggleable material zones (Top, Sides, Bottom) which each use a Base Color, Alloy Packed Map, and Normal Map.
Triplanar Light [12 tex samples, 2-8 tex samplers]: Similar to the above shader, but instead uses our Terrain Packed Map formulation (BaseColor+Roughness, Normal Map), to lower the amount of samples per side. As a result, it has up to 4 unique material zones (Top, Bottom, Xaxis, Zaxis). Note these too are toggleable, so if you just want the same texture on all sides or just sides and top surface, you can choose what’s enabled.
Triplanar Vertex [24/48 tex samples, 4/8 tex samplers]: Functions with the Terrain Packed Map style inputs as the shader above, but instead of defining material zones, you define the blending between sub-materials through vertex color. There will be a 2-splat version that uses VertexColor Alpha, and 4-splat version that uses RGBA Vertex Color.
Triplanar Terrain [20/40 tex samples, 4/8 tex samplers]: Build for Unity’s terrain system, this will be in a 2 and 4 splat config. using the Terrain Packed Map setup as above.
Now to talk for a moment about triplanar, there are a few things I think that are worth covering as I’ve seen a bit of confusion, misinformation, and frankly some bad design present in other triplanar shaders.
Triplanar Shaders Are Expensive
There is no way around this. Due to the way shaders function, all ‘sides’ are being sampled uniquely. So on say the Triplanar shader, we have 3 texture samples times 6 sides. 18 texture samples total. This is the rough equivalent of having POM on slightly-above-default settings, and POM is the most expensive property group you can add to an Alloy shader. Some folks try to lower this amount by allowing a texture to project ‘through’ an object, but the results in a backwards texture, and weird symmetry on thin forms, so we’ve opted not to do so.
Triplanar Shaders Should NEVER be used in Forward Rendering Mode
In forward mode, the entire object, and as such shader, is being redrawn for every pass/light. This can easily be disastrous perf wise. This is also why we will not be supplying translucent or transmittive triplanar variants.
Triplanar Shaders Are A Situational Tool
The prime benefit of triplanar shading is situations where seamless, distortion-free UVing of a surface is impossible or impractical. Examples of this include marching-cubes voxel objects, weird demoscene meta-balls, height-field based terrain, and monstrous unfixable Revit models. It’s also an IMMENSELY useful prototyping tool. One can easily view and test with textured versions of modelling block-outs and sketches without having to go through the whole uving process.
Triplanar Shaders Must Be Used Carefully
By this I mean, they must be accounted for consciously within whatever performance window you’re working in. With many materials/shaders, their performance diverges from the mean so minor that we don’t really have to think about it much. We don’t have to audit our usage of say.. materials with rim lighting carefully. Triplanar is fundamentally in a different category (one it shares with things like POM, tessellation, HQ Glass, Transition). With effects in this category, one must always ensure that one truly _needs_ the effect, and that one is getting sufficient return in the form of aesthetic impact, workflow expediency, and general utility relative to the effect’s cost. In short, just always make sure its worth it, and that you aren’t smattering things around uncritically.
Alloy 3.3 and Beyond
We don’t have a fully crystallized strike list beyond 3.2, at least in terms of the priority order of things on the wish list. We do however have a list of things we want to add to Alloy in the future in a general sense, and they are as follows:
- Wetness/Rain System
- Speed Tree shader set (cutout, transparent, transmittive opaque, etc.)
- Some official solution for object-highlight depth occlusion (character behind a wall stuff)
I should mention at this point that if you’re interested in any of these things happening, do let us know (and if you’re interesting in funding their production they might happen a whole lot faster).
Either way, we’re reaching the point where Alloy is becoming a truly filled out set, and there is a pleasingly small list of things that remain to do (that would be of non-purpose-built utility). We’ll also be working over the coming months on building some API documentation that will aid the mad few of you who would like to extend the Alloy framework for your own purposes.
Lastly, when 3.2 drops, we’ll have another (shorter) video out akin to the crash course where we cover the finalized changes and new shaders. Keep an eye out for it!