Alloy Physical Shader Framework by RUST LTD.

Wow thats kinda unexpected, never would have thought that unity uses the "old" way of handling static branching, without the ability to override this for current hardware. I guess unity's focus on mobile space is showing, but even there the branching speed is fine and we also have kinda SM3+.

I can understand that special fx shader may hit the interpolants limit, if u route lots of texture lookup coords from the VS, but can't u move those to the PS? The advantage for sampling loops is that u can scale the texture lookup loop better in the PS.

In the end if u have no control over how unity is compiling or not compiling static branches, than u can do very little.

Thx
Andy

 

Having some issues... Error in console here:

No inspector definition file! Contact alloy support
UnityEngine.Debug:LogError(Object)
AlloyBaseShaderEditor:OnAlloyShaderGUI() (at Assets/Extentions/Alloy/Editor/AlloyBaseShaderEditor.cs:70)
Alloy.AlloyInspectorBase:OnInspectorGUI() (at Assets/Extentions/Alloy/Editor/AlloyInspectorBase.cs:85)
UnityEditor.DockArea:OnGUI()

Won't let me see exposed settings for Shader. Can select shader but all shader attributes below the pop down are not there.
Thanks for your time.

Gary

 

Hi Gary, Its not finding the inspector definition file for some reason. Try importing the ShadersAndEditors Package again (which has a copy of the editor definition file in it). PM me if this doesnt fix the problem.

 

I think that fixed it. Thanks.

Regards,

Gary

 

Hi;
Though updating process took tremendous amount of time (and on each of computers I am working with - lol) it updated and I saw that none of the materials was able to find a suitable shader from Alloy. It took much less time to fix those than it took to import though

However, when I choose Cube Reflection, I cannot assign a cubemap to it. It denies every single cubemap I created, and it always shows None even if I do it in real time. (No SkyShop, just a cubemap I baked before runtime)

Secondly, in Self-Illum, cutout glow renders the parts that were supposed to be transparent. For example, a 512x512 texture with a circle in it should just render the circle, but it does render the box with circle using correct colors and rest with a distortion.

 

@Tanshaydar: There's two ways you can fix the cube issue. One is to look a couple pages back from the file I linked that fixes the editor. The other is that you can update from the asset store (we just pushed 2.0.2 that contains the fix as well). It'll be in the ShadersAndEdtitors sub-package (only 1 file changed).

@Gary: Glad to hear it!!

 

When I move Alloy to a subfolder in the project is when this happens. If I leave it at the default install location its fine. FYI.

Gary

 

Oh yeah, under nooooo circumstances should you ever move the Alloy folders. Apologies to those with organizational ocd

 

I still don't see the cube reflection. With the update I was able to set my custom cubemap, but no reflectivity yet.
This is Unity built-in Reflective Shader:


This is Alloy Core/Base Bumped RsrmCube

 

@Tanshaydar: What do you have the roughness set to on your material? If its the default (1.0), you have a 100% matte material, meaning you will get no cube reflection. You need to make the material smoother and then manipulate the Exposure Boost parameter under the cube to get the final look you want.

 

Two things:

- Can you please make the AO use the 2nd UV channel, please? Skyshop also does that and to my knowlegde that's how it's typically done becausethe first UV channel can typically have overlapping UVs. The AO UV Layout on the other hand shouldn't have any overlapping UVs, so it goes into the second UV channel where all UVs are unique.

- At the moment the SH workflow for assigning custom cubemaps (or rather skies) is still very cumbersome and even Skyshop has the spherical harmonics shaders in its "Beta" category. In contrast you require all Alloy user to go this cubersome way without giving us the option to use good old robust custom cubemaps (at least Skyshop leaves us this option). I would like to see you implementing the old cubemap driven workflow (with custom diffuse and custom specular cubemaps) until Skyshop has refined the workflow with their spherical harmonics shaders. At that point you are more than welcome to change the workflow in Alloy, too. I know Marmoset told you diffuse cubemaps will be completely replaced in the near future, but as of now they are still used by the majority.

Thanks!

Sean

 

@SeanM3D:

1. At the moment, there's no way for us to get UV2 into the shader. In SM 3.0 there's a limited amount of data that can be passed from the vertex into the fragment shader, and we've hit an immutable ceiling as far as we can tell. We're still trying to get around this limitation somehow without dropping features, but until we do, there's no way to use the 2nd UV channel. I know this is a major difficulty for some, and its something we've been fighting with for a while now.

I should also put forward that baked-AO in 2nd UV channel is becoming a less and less common workflow. Typically the AO defined in the material is for the micro-cavity detail of the material itself, with macro-occlusion being provided in screen-space, and/or on lightmaps baked in engine.

2. I will speak with them again, as you're not the only one to question this. Their explanation to me is that binding skies to renderers makes more sense than binding them to materials, so that you don't have to worry about duplicating your materials manually when you have the same object existing in multiple sky zones. From what I've been told, even if you don't like this workflow, you should probably get used to it as it will be the norm for Skyshop going forward (and dropping a cube-sample for diffuse ends up being a nontrivial perf-gain).

Apologies if this all inconveniences you, it is a difficult balancing act making this set ideal for the largest set of use-cases.

 

Hi, I've just buy your product, but I get an error message sometimes and I can't do anything, nothing appears in the shader inspector.
How can I fix it ?

Code (csharp):

1.  
2. ArgumentException: An element with the same key already exists in the dictionary.
3. System.Collections.Generic.Dictionary`2[System.String,UnityEditor.SerializedProperty].Add (System.String key, UnityEditor.SerializedProperty value) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:404)
4. Alloy.AlloyInspectorBase.AddPropsFromArray (UnityEditor.SerializedProperty props) (at Assets/Alloy/Editor/AlloyInspectorBase.cs:141)
5. Alloy.AlloyInspectorBase.InitAllProps () (at Assets/Alloy/Editor/AlloyInspectorBase.cs:129)
6. Alloy.AlloyInspectorBase.OnInspectorGUI () (at Assets/Alloy/Editor/AlloyInspectorBase.cs:79)
7. UnityEditor.InspectorWindow.DrawEditors (Boolean isRepaintEvent, UnityEditor.Editor[] editors, Boolean eyeDropperDirty) (at C:/BuildAgent/work/d3d49558e4d408f4/Editor/Mono/Inspector/InspectorWindow.cs:850)
8. UnityEditor.DockArea:OnGUI()
9.  

 

@Unity_sg: What order did you import the sub-packages in?

Please first trying to re-import the ShadersAndEditors Package first again. The inspector definition file might have gotten fragged.

Secondly, did you take an old material, and turn it into an Alloy material (say like taking a bumped reflective spec and changed it to be an Alloy material?) Basically, Unity hangs on to every state of every variable a material has EVER been. This can cause problems with our custom inspector (as there's no way to filter them out. Do me a favor, create a completely fresh material, set it to Alloy->Core->Base Bumped. Tell me if you still get that chain of errors.

 

Anyone actually tried using the marmoset generated specular cube map with the Alloy Shader? I tried today and i can't get any of the alloy shaders to accept the specular cube map from marmoset, just stays as none. Anyone experiencing this problem?

Am i doing something fundamentally wrong here?

The other aspect i'm confused about is the difference between SkyshopSH and SkyshopBox as they both seem like beta things in marmoset under the shader section?

 

@GXMark: The cube problem was posted about in earlier pages. Redownload Alloy from the asset store, there's a bugfix to the inspector code that should allow you put in a custom one now .

SkyshopSH mode uses the Spherical Harmonics diffuse of the active/bound skyshop sky, and its specular cube.
SkyshopBox does the same thing, but with the box-projection bounds options.

Though these are both beta features in Skyshop, they will be the standard in the next skyshop version, so we were told to implement around them, to save us having to redo everything once the final switch over is made in skyshop.

 

It's really frutrating. From version to version there is always some caveat that forces me to ditch Alloy alltogether. With every new release I hope for the best only to find out something vital is missing again.

Skyshop is also full of channels and yet they manage to provide an Occlusion channel for UV2. Why can't you just use a UV2 AO instead of a Detail channel in one of your shader permutations? There sure must be a way to include it if other plugin developers managed to get it working. Please be a bit more flexible here.

Concerning the baked AO workflow: As long as you offer an occlusion channel it should be UV2. That offers most flexibility. The AO channel is there because lots of people demanded it and thus it is still a commonly used workflow. SSAO is probably the worst kind of AO I can think off and full blown lightbaking does not work for every project whereas a baked AO-only solution is most of the time a good in-between compromise.

I concur. Binding skies to renderers makes more sense, BUT as of now the workflow is way too cumbersome and not user-friendly at all. Without a fair amount of scripting users won't be able to employ this new workflow which in turn excludes a huge part of the user base. As long as Skyshop doesn't provide an easy, user friendly workflow you should employ the old way of doing it. After all this is still a BETA solution and you expose it as if it was production ready for years.

Thanks for offering your apologies, but right now I don't need apologies but rather a working plugin. You said you try to provide a plugin suited for the largest set of use-cases, but with every version you FAIL to do exactely that. For instance with the current version you decided to make AO use UV1 when in fact the more conservative and safe approach would have been to use UV2. The same goes for employing the immature sky binding workflow instead of simply using the old and proven way. These are decision I can't quite understand and I hope you will act quickly and revert to conservative workflows.


Sean

 

@SeanM3D:

I think you might have misinterpreted my response. We don't have UV2 support, not because we don't think its important, or because we don't have any texture inputs left. We can't do it because of data we _need_ for our shading model that's passed from the vertex to the fragment shader. Marmoset does not have this problem because they are not doing the form of shading we are. This isn't a matter of 'just spinning off a variant'. The framework itself won't compile currently when we try to add it. By supporting our shading mode, and skyshop's features (including box projection which many folks requested), we have hit a hard wall. We are however, investigating workarounds, hoping to find some way around this problem.

As for the skyshop stuff, I spoke with them again. The next update of skyshop (which will drop next month) is going to be improving the SH workflow, which will not require scripting (and instead functions based on a volumes/zones that you lay out. I reconfirmed that this is how things are going to work, and diffuse cubes will be gone. As you might imagine, it makes no sense for us to spend the time it would take to re-engineer the framework back to using them, when they will be deprecated very soon. Please understand that if you are dissatisfied with this, you should speak with them. We have simply done our integration under the guidance and terms that they have laid out.

 

Guys I think that a developer at a game studio where I'm taking a course has broken a record here. He started importing Alloy 29 hours ago in his laptop and it's still here:

 

@Venom: What on earth..? Do you by chance know what cpu/ram that machine has. In the terminal case, that package shouldn't take longer than 2 hours to import, unless the machine has waaaaaaay too little ram in it.

Also, I notice that the screenshot there is showing the indie Unity skin instead of the Pro one. Are you sure that machine is running Unity Pro? If not, Alloy is not going to work on it (though I don't know if that would interfere with import at all).

 

He is using an HP Probook 4520s. CPU: Intel® Core™ i3-380M Processor (3M Cache, 2.53 GHz) and 6 GB RAM. Also he has Unity pro but likes the grey interface.
And believe me that it has been that long.

 

@VenomUnity: What on earth.. You're the 2nd or 3rd person to report unusually long import times, but I've been unable to repro on machine available to me. We've imported Alloy hundreds of times collectively, and in some cases on slower cpus that what you mention. Hopefully this will all be a non-issue when Unity 4.5 drops due to the shader compilation tweaks coming (testing we've done shows the whole set only taking like 10-15 mins to fresh-import).

Tell your friend that I'm quite sorry its taking so long for him. If it continues to labor, it might be worth killing it, rebooting, and seeing if a fresh boot/load of unity improves the import time. Best of luck!

 

Just to let you know, it finished importing after 43h. It's not showing any errors and we are checking out the demos.

 

A second unity instance running in background did that to me.

 

Hi Everyone,

Just wanted to mention that I'm here in San Fran for GDC all week, so if any of you are going to be here as well, and would like to see a live Alloy demo, ask any in-depth workflow questions, or just talk shop, shoot me a PM here and I'll try to hook up with you.

I'm also going to be giving a quick talk at Allegorithmic's booth (booth 1910) at 11:30am on Friday on PBR substances and Alloy if ya feel like swinging by.

-Anton

 

That is awesome dude... I wish I could attend these events... would be a very enlightening experience.

 

Hi guys,

perhaps you could answer me some very basic PBR questions. Am I right that the spec channel is only used for the non-metallic parts of an object (masked as black in the metallic channel) ? A metal object is no longer a "metal" object if it has some paint covered over it, right? For example a painted radiator. Only bare metals are considered as "metal" objects or am I wrong?

Thanks,
Michael

 

@FogGobbler:

You're right on the money. A painted metal is no longer a metal, as in almost all cases, you want to be representing the top-most material of any aggregate when setting up a shader. So if you say have a painted radiator, with Steel, Dirt, Rust and Paint. The sort of thing you'd be having is:

Paint: Metallic=0, Spec=.5-.7, Roughness=Quite Smooth, maybe .3-.4
Steel: Metallic=1, Spec=0, Roughness = .3-.6, maybe a bit noisy
Rust: Metallic=Noisy range of 0-.3, Spec = .5ish, Roughness = Super Noisy, play with what looks right.
Dirt: Metallic=0, Spec=.2-.3ish, Roughness=Noisy range .8-1.0

If you're not using substance designer yet, I HEARTILY Recommend it for doing PBR texturing. It allows you to define a set of common materials you're using (paint, metals, dirts, whatever), and blend them together based on a color-mask map. It makes it so that you can worry about setting up your physically-accurate parameters ONCE, and just worry about blending logic afterwards. Its already saved me buckets of time. Plus, we have a preview shader for it, and a little tutorial on the Alloy site on how to set it up in SD4

 

It is definitely a time saver

 

Thanks, xenius! I´ve just downloaded the Substance Painter Trial and it also looks quite interesting. Substance Designer is on my shopping list ;-) .

 

hey, i like the look of this, that's some cool stuff, i have a question, how do you feel about Unity 5 including physically based shading?, i can't imagine that being good for you.

 

@SVGK: I'll respond at greater length to topic to this soon (probably in an article on the Alloy website), but in short, I don't mind it in least.

Right now there are a plurality of approaches to PBR. What BRDF one uses, what visibility function/approximation, what channel setup, what support/filtering tools, etc. etc. etc. With each of these combinations of comes a tool design philosophy, a set of content production strategies that are favored, and a performance window being targeted.

Unity is releasing something in line with their philosophy of supporting as many build-targets as possible. As you may have noticed from the screenshots they've released, their channel/parameter setup is the traditional full-color diffuse + full-color spec plus supporting maps. I would wager that this choice was made (vs. say following the design pattern used by Disney, Epic, and us) in part to better allow for folks to author a single set of assets, that can say run in a high-end PBR mode for say consoles/desktop, but also 'scale down' to high-end mobile in some capacity, and use mostly the same maps. Granted this has its own conceptual problems, as assets authored for simpler shading models tend to only look good because they have manually-painted in shading that would look super-wrong in a PBR shader, but we'll see. This channel setup is also the most familiar to the largest percentage of their user base. I imagine to do anything _but_ this would be_hugely_ confusing to a nontrivial number of users. Unity remains (imho) the best game engine precisely for how amazingly accessible it is.

Beyond that, I think there's a philosophical debate, which we are on the other side of, in terms of shader channel setup, as to what is the conceptually cleanest way of handling the data inputs for PBR. The channel setup Unity is using is the one we started out with in our internal version of Alloy that predates our Museum of the Microstar project. We found that using a manually-defined Albedo and Spec color ended up being a touch data-wasteful (as non-metals all have black and white specular colors), and it was _very_ easy to accidentally create combinations of values between the two maps that didn't map to any realistic surface. In fact, in a number of games that use this approach, the given dev team actually had to implement a tool to show artists when they had erred and produced a material that strayed outside to boundaries of realism (Remember Me, Ryse).

Going with the Disney-style BaseColor-Metallic-Spec-Roughness channel approach, in our view, takes a lot of the guess-and-reference work out of authoring PBR materials, and, due to the way our material map works, allows us to pack the _maximum_ amount of data into three textures, which both saves a texture sample over the other approach, and becomes one less final texture to keep track of. There were a slew of other reasons we adopted this setup, but I'll simply say that we haven't looked back since.

In the end though, we care most about people finding the right tool to their needs, their workflow, and their desired aesthetic. If you work primarily in photoshop, and/or with DDO, and find it more comfortable conceptually to work with the older channel setup, then Unity's native solution for 5.0 will probably work wonderfully for you. If you work with Substance Designer/Painter, or are a convert from Unreal4, or just find working with Metallic, Spec, Roughness data channels to be more conceptually clean, then Alloy is here for you. Neither of these options is 'more or less' physically based. They are different approaches to a common goal with their own merits and limitations.

To sum things up, I think its_great_ that Unity 5.0 is getting a native Physically Based option. Its about damn time that we stopped using non-energy-conserving-20-year-old shading models that make headaches for artists! This feature in Unity will only speed the adoption of these models, and help users new to them to learn a new set of asset production processes, and make more vibrant work. The improvements coming in 5.0 (the new fat-gbuffer deferred shading, the 'smart' shader architecture, etc.,) will also enable us to provide a much boarder and deeper feature-set for Alloy, as well as likely improve its shading fidelity. We're committed to covering as many bases as possible for those you prefer our tool and workflow, and we'll be continuing to add features and permutations as you guys ask for them!

-Anton

 

ola,

i have difficulties utilizing Directional Lightmaps in Unity 4.3.4f1 Pro on Windows.
It might be a lack of knowledge on my side, so i am asking for help
Simple Scenario:
1. Create a Plane Gameobject
2. create directional light (Render mode and Lightmapping on Auto)
3. Bake Directional Lightmaps just plain with no AO or GI

with a Unity bumped specular shader i see the normal and Specular highlights. With alloy/core/base bumped i cant see normals and Highlights.
What did i wrong ?

Damir

 

@DamirS: Apologies for coming typos, writing on phone. You're not going to get a 1:1 effect. The way unity setup its bumped specular shaders to work with directional lightmaps is.. how to put this.. hacky. Its taking a bunch of the ambient light information in the map and trying to.. reconstruct a specular term, but frankly, its doing so in a strange way that doesn't in any way map to RL light. In Alloy (and any other PBR setup), a directional lightmap is only going to provide ambient lighting to the diffuse term. For your specular hit, your specular 'hit' is only going to come from real-time lights (I often use small real-time-only point lights in deferred mode with my directional lightmaps), and from whatever reflection mode you're using. Also, when using directional lightmaps, its best to only have lights set to 'realtime only or baked only', as the 'auto' mode only makes sense for dual lightmaps.

 

Has Unity 5.0 with its support for Physical Based Shaders Pissed on Alloy's Fire?

I'd like to know the benefits of using Alloy moving into future unity game development.

I guess the same question is for Candela Livenda since Enlighten Real Time Global Illumination is likely to be integrated native therefore
will be faster and more optimised.

 

hm, right, i have a question though, how do physically based shaders work, the benefits aren't really all that clear and obvious to be, does it mean fancy eye candy like this or this?, cause that's really cool stuff they've got going on there.

 

Main reasons are 1) Works better in most lighting environments 2) Don't have to create specular maps 3) Uses a pre calculated reflectance map not requiring cube maps although you can hook them up to standard cube maps or marmoset cube specular map.

 

@GXMark: First off, you really should scroll up slightly to see that I already wrote a fairly lengthy post on my feelings on Unity 5's PBR system (which I still think is great).

Regarding the specific benefits of using Alloy over the native system, a lot of what the possible comparisons flatly fall into the too-early-to-tell. After seeing the presentation on their system at GDC, a lot stuff in their new deferred path(which is toootally going to be the mode to run in for PBR) is still up in the air/TBD, and 5.0 is only in its earliest alpha.

In abstract, and to restate what I said prior, its going to be about what you need as a developer, and what content tool-chain you primarily use. Alloy will directly benefit from nearly all of the new features in 5.0, from the new smart-shader compilation engine, new deferred path with fat g-buffer, 64-bit editor, real-time GI system, etc. By the time 5.0 actually releases, we'll easily be at feature-parity, but with all of our Alloy-specific features such as our Roughness Correction, Workflow tools, Specular Occlusion, and a wider set of options for extra channels and inputs than what I've thus seen out of Unity's new uber-shader.

Either way, with all the pings I've been getting it feels like everyone expects us to be screaming that the sky is falling or something . Nothing could be further from the truth. If you haven't yet, please read my earlier post detailing how I feel about the comparison as I know it now. If you have specific work-flow or long-term development concerns specific to your project, feel free to PM me. We may sell Alloy, but I'm not here to tell folks to use it when something else will suit their needs. We do this first and foremost because we love working on Physically Based rendering. Alloy started as our in-house toolset that we use for all of our work, and will continue to be for the forseeable future. I'm sure some folks will prefer the native solution, others will find that our offering suits their needs more.

 

Thank you for reassuring me and i would expect a lot of curious minded people that the Alloy toolset will remain at the forefront of shader technology moving into version 5.0 of unity.

Many thanks

 

Alloy for life!!

 

@xenius
Thanks for the heads up. I feel like this would be something worth mentioning in the docs or elsewhere because "works with Direction Lightmaps" assumes you would have at least the same "hacky wacky" Spec term then None (No Offence here).
I get exploring Deffered Rendering path now to see where that is going.

Damir

 

i was actually asking what the benefits are compared to what we have right now in Unity 4.

alo, i'm guessing that this would be one way to do the textures and Alloy would be for letting this functionality exist in Unity, right?.

 

Does anyone know how to import the alloy example normal maps at runtime. It seems the alloy shaders are very sensitive to normal map format which seems only available editor based unity texture importer. Does alloy have the gray scale texture to normal map conversion script to work with their shaders?

 

Hi guys,

I´m just diving into SD4 and I´m not getting the substance to work with the physically based shader. I´ve got everything set up in SD4 (preview shader and example substances). Can I only export the generated images from SD4 and plug those into the shader at the moment? I can´t change anything on the fly, right?

Best regards,
Michael

 

At the moment, you can only export images for now... I can't wait though to get the substances fully functioning

 

Thanks for your reply. Thought I was doing something wrong ;-) .

 

I did the same thing myself... I am actually learning how to do the substance programming... it's interesting... I can add wounds to my characters dynamically now... so much to be done

 

Yes, I'm also fazinated by the way you can tweak textures and materials in the editor. Great time saver. Looking forward to the full implantation for the Alloy shaders.

 

I also purchased Bitmap2Material which I think the Alloy shaders work in there too... still waiting for a confirmation

 

@DamirS: I totally see where you're coming from. I honestly didn't even think of it, as those janky-fake-spec highlights aren't actually a 'part' of directional lightmapping. They're just the result of some weird choices made in how Unity's default shaders interpret them. Mirrors Edge (the masterpiece of that lightmapping technique) just used generic cube-map reflections instead (which I think looks better frankly).

@GXMark/FogGobbler: Right now, the substance integration is in-progress. There's a bug in 4.3.X that's a conflict between multi-compile (which we use) and substances, that prevents you from using a naked substance. You CAN however, publish/import a substance with your given maps (BaseColor, Normal, Material Map, whatever), and then drag the texture reference from inside the substance onto an Alloy material. We just did this in a demo we were working on with Allegorithmic this week. Just be aware that the normal-maps passed through substance should almost always be set to maxed quality/as little compression as possible, or just be used right out of your modelling app, as jpg-compressed normal maps can do nasty things in PBR (especially with hard-surface models).

@Everyone Else: Phewwwww, just got back from GDC. Had some awesome convos with folks about future collaborations/features for Alloy. Going to have some exciting stuff for you guys in the coming months. As a heads up, we're going to do 1-2 more updates in the 4.x release cycle (terrain, skin and possibly other SSS variants). After this, we're going to go ahead and start working on our Unity-5 version of Alloy, as there are some tremendous internal changes, and its going to take a great deal of dev work to make the most of what will be possible in the next version of the engine. We'll still of course be supporting the product in every way we can in the interim

We'll still be continuing our work with Allegorithmic (who are just awesome fellows), to get the Alloy-substance connections as solid as possible. As we do that, I'll likely be posting some sample graphs here, and some tutorial support material as we figure out the best-practices for that workflow.

More cool stuffs soon!