Alloy Physical Shader Framework by RUST LTD.

FINAL UPDATE - THIS THREAD IS CLOSED
updated info can be found at:
ALLOY VERSION 3 THREAD






ALLOY PHYSICAL SHADER FRAMEWORK V1


[Asset Store Link] | [Documentation] | [Walk-through Video]

[Demo Scene PC Standalone] | [Demo Scene OSX Standalone]

Alloy Physical Shader Framework is the complete solution for bringing Physically-Based Shading to your PC, webplayer and Next-Gen Console Unity projects! Alloy comes with over two dozen shaders, and an epic Sci-fi Demoscene with 30 complete textured materials designed to get you up and running fast!

The Alloy Framework is the latest evolution of our in-house toolset, which many of saw this past January in the DX11 Contest winning Museum of the Microstar. Though the set we're releasing this week is purely the DX9/SM 3.0 shaders, we'll be patching in out DX11 set sometime in December, free to everyone who's purchased Alloy.

As longtime users of Beast/Turtle, and light-mapping obsessees, we've built our technology around getting the maximum fidelity out of a Beast-centric workflow. Alloy has been designed to get the most out of Unity's advanced graphical feature-set including:

• Linear HDR Lighting
  [*]Deferred Rendering
  [*]Directional Lightmaps
  [*]Light Probes

The shader set that comes with Alloy has been designed to cover as many of the common permutations of features you might want as possible. Additionally, we've structured our shaders such to maximize the convienence of building your own variants on top of the Alloy core. So if you need to add in an extra fx map, or need your texture transforms rooted differently, you can do so without messing with the functional core of the set.

Included Shader Variants:

• 
  
  
  • Cubemap and RSRM Reflectance
  • Rim Lighting
  • Detail Mapping
  • Self-Illuminated
  • Masked Incandescence
  • Transluscence w. Distortion
  • Alpha Cutout
  • Terrain w. Up to 4 Splats
  • And various permutations of the above.

Other Demos you can Download Right now!

Download Museum of the Microstar | Note this is a GPU-killer! GTX 560TI and up only! NO REALLY THIS IS THE MINIMUM SPEC!


Download Warehouse Scene | This is an early baked lighting test. You will need to Alt+F4 to exit this, Sorry!


Download The Hold | A game demo we produced last year that was our first use of Alloy!

Technical Details and FAQ:
What Versions of Unity does this support?
Alloy currently supports Unity Pro 4.2.1 and up on Windows and OSX.

What sort of performance should I expect?
As cheap as Physically-based Shaders can get. Most of the cost you'll incur will be through having deferred mode engaged (if you use it), and having normal-mapping on every surface.

Does Alloy work on Mobile?
No, as Alloy requires linear lighting (and a pretty fat memory bandwidth), Alloy is not yet supported for mobile. We're still waiting for the hardware to catch up.

How are you handling reflections?
All Alloy shaders have two variants: RSRM and Cube-mapped. An RSRM is our in-house look-up texture for a sort of generalized horizon-style reflectance, that is pre-computer for 256 specular powers. What this means is that even if you don't want to manage unique cube-maps for your scene, reflective materials will still look shiny and distinct with only baked light (Museum of the Microstar used no cubemaps whatsoever). If however, you have a metal material that you want to have use a specific reflection, you can use our Cube variant, that lerps between the RSRM and you cubemap based on the material's smoothness. Thus you get the best of both worlds in terms of workflow/data management, while maintaining a coherent aesthetic!

What BRDF are you using?
We've chosen the Normalized Blinn-Phong BRDF for Alloy for several reasons. The first of which is that it plays nicely with a Light Pre-Pass renderer. As our projects have made almost exclusive usage of Deferred mode in Unity, we built our tech around this constraint from the beginning. Secondly, Normalized Blinn-Phong is cheaper than Cook-Torrance by a ridiculous margin, and having a Physically-Based model that could scale to much large scenes was of greater importance to us. We tried out Simplified Cook-Torrance, but found that it has a nasty tendency to blow out luminance values at grazing angles, and as such was inappropriate for scenes making heavy use of HDR, and visual effects reliant upon it. Though Normalized Blinn-Phong isn't as accurate as more expensive models, we've found that one gets most of the characteristic visual traits and benefits from physically based shading using it, at a marginal cost.

 

So awesome!
How much will it cost? I really want this but I cant afford a to high price. ;(

Edit:
I havent purchased alloy. ;P

-GamehubDev

 

Will there be a evalution version or trial for this? Because I dont have 125 dollars.
Awesome product! I'll try out the demo/ project's from the bottom of this http://blogs.unity3d.com/2013/11/21/cutting-edge-aaa-shading-technology-for-all/ page.


-GamehubDev (I forget that I post with two different accounts. I have to stop using my mrjose342 account)

 

@GamehubDev Sadly, there won't be a trial for this (no way to do that sort of thing unless its an editor extension). We'll be releasing more videos though over the next two months, showing the workflow, tons more examples so you can see how Alloy fits into smaller products (and how clean it is to work with). We might even do a live-cast workshop so folks can ask questions directly.

We'll also be posting our roadmap to the site and this thread soon, as we have big plans for continuing to develop Alloy, especially for DX11/SM 5.0 users.

 

HI EVERYONE !


Im thinking on getting this Shader Framework Before cristmas ...


.. But i Have to make sure that i can get Integration of it INSIDE RELIEF TERRAIN v3 SHADER.
http://forum.unity3d.com/threads/206516-Relief-Terrain-Pack-(RTP)-v3-on-AssetStore



Can you guys Port your Terrain Shader to be compatible / working Physical Inside RTPv3 Shaders ?

Here is one of Relief terraiN Shader Parameters Example:


http://imageshack.com/a/img716/1241/uryd.jpg

What we would need is to integrate your physical based shading parameters within RTPv3 shaders.


As a Customer i can act as Bridge between the two products - Integration...
Or you Can Also contact Relief Terrain Author...


If you Guys Can Add Your Shader Methods Integration
( or at least teach us how t make your shader Methods ) from this Framework work Inside RTPV3 Shaders

/ I will buy it for sure ! If you guys can do that !


PS: Why using relief Terrain pack And not your provided terrain ?


Relief terrain pack got Blending Meshes / triplanar 16 texture layers and Hundreds Features That are needed to my levels ...


Unfortunately RTP doesnt Have phisical based shader or so soon wil have and i realy need the integration betwen This Shader Framework Methods and Relief terrain pack ful features.


Can you guys Help this Integration of ALLOY RTPv3 happening ?


If you think you can ! You Possible have here a customer !


BEST REGARDS



SOULS

 

I didn't even know that there was shader model 5.... :O
And Xenius can you tell me if I need shader model 3 to use the shaders or am I fine without sm3?
I will definetely buy it if I can use it without sm3.


-GamehubDev

 

@Gamehub Dev: Oh no! The set here isn't SM5, its SM3.0/DX9. We're GOING to be adding MORE shaders to the pack next month that are SM5.0 (tessellation stuff mostly).

@Soulssaga: At the moment, we probably wont try any integration for terrain (terrain is fairly low on our priority list as we have 3 more content releases for this set planned first). However, the framework is setup to be as mutable as possible, so if you wanted to modify the Alloy terrain shaders yourself to add in the RTP stuff (if you can fit it in the DX9 register limit), you can do so. We've tried to keep the Physical-shading code and the surface-shader setup code as separately-organized as possible to make that sorta thing easier for people who need to merge systems.

 

Well I need a new computer then. My video card doesn't support SM 3 even though I bought this PC post 2013.
I only have a laptop so changing the video card is way to difficult....

-GamehubDev

 

It is nice tech, a bit expensive. Since this is physical it would greatly benefit from some sort of realtime GI when light change often. For a static lightmaping GI i stick with skyhop when i can control reflectivity by fresnel parameter.

 

I paid about 1.000 dollars for the laptop. And the people in the store said that it was great for video editing and gaming.
It's a Samsung laptop with a amd processor and video card.
I'll find the specs later.

-GamehubDev

 

Greetings fellow developers. This shader pack looks great but I have a question that is the big yay or nay for me. Do these shaders have a tri-planar option? My game uses procedural terrain and also allows for voxel building so we need tri-planar shaders. Either way great job on this awesome package!

 

@Tethys: At the moment we don't have a tri-planar option, but would be open to having them in a set. The only problem is that doing triplanar texturing tends to use up a ton of registers (and we're limited to 39 I think in DX9), so it might be possible, but not necessarily alongside some of the shaders that already have a ton of input channels. What sorts of channels would you need in that situation? How many of those would have to be different based on direction (like, is this a tri-planar using the same texture set per direction, or different textures for the top/bottom/etc.). Twould be a messy shader for sure with all the inputs, but I can ask our resident ninja about it specific challenges of doing it later today.

@GamehubDev: Have you tried running the downloadable demo scene listed above? (the main one) If not, run it, and send us a screenshot or two at Alloy@rustltd.com. Feel free to include the specs on your laptop as well.

 

@Xenius - Hey thanks for the quick reply! I can't be too specific on the technical aspects of it (I have asked our terrain programmer to take a look at the thread) - however I can comment on what I know Our current tri-planar shaders have options for 1-3 sides (a 1 sided, a 2 sided top and side, and a 3 sided top, side and bottom). In addition, our 3 side tri-planars take a normal map for each side and two diffuse maps with a noise option for variety, for each side. Gratitude for taking a look and responding!

 

It actually worked on my computer.
It's really awesome but I just cant afford it at the moment.

-GamehubDev

 

@Tethys - Just got done talking with our ninja n00body and it looks like the tri-planar stuff is very much possible. We'll add it to our list for stuff to add in the future. If you want to contact us directly at Alloy@rustltd.com I can take a closer look at what sort of geo and setup you're working with to make sure you could cleanly convert over to using Alloy in your project.

 

Finally we got PBS into Unity. Thanks a lot for that! What a pity that your shaders can't do IBL like Skyshop. I also miss the Fresnel term.

It's really tragic that the great shader packages for Unity only provide subsets of functionality needed for photorealism and can't communicate with each other. The one shader package provides IBL, the other POM and now we get PBS. But no shader package that does PBS + IBL + POM.
I hope this will come once Unity completes their ubershading system with state-of-the-art monolithic shaders.

 

@SeanM3D Glad you're happy to see it! I wanted to mention two things. First, the Alloy shaders do have a Fresnel term, which in our case is mathematically correct (which does make it subtle on many rougher materials). If you walk around in the main demo scene and especially look at the terrain, you can see the added luminescence at grazing angles.

In terms of IBL stuff, we do want to eventually add skyshop support, as we absolutely love the stuff their tool outputs.

As for parallax occlusion mapping, while gorgeous in certain circumstances, I've always felt that its something that fairly special case, and is already being replaced wholesale with Tessellation/other displacement techniques. Cone-step maps can be wonderful too, but they're a nightmare from a generation/workflow standpoint. Granted I think there's room for all of these techniques. Also, if you wanted to use POM with Alloy, the structure of our framework is such that you could make your own variant without having to mess with any of the Physically-based lighting code.

 

HAHA, awesome!
I just saw this and funnily, this thread is just above "Jove: Next Generation Physically Based Shading Asset Pipeline".

SO I gotta ask, what's the difference between the 2 products? What do you offer the other doesn't?

Also, UT seems to be advertising this a lot more than Jove, does that mean this one gets the official endorsement which means its better in some way?

 

@Bawss-man I haven't used Jove, so I wouldn't want to presume anything about what it can and can't do. We're each using different BRDFs from what I see, but I don't know the technical details of any of the other lighting math they're using.

There are a plurality of shaders and related systems on the asset store, each covering various use-cases and combinations of requirements. I also don't think its going to benefit anyone to start a Shader-boxing-match on the forum.

I'd be happy to answer any questions you have though about Alloy if there's anything unclear about the product that isn't covered by our walk-through video and documentation.

 

I bought it and I can confirm this package is well polished.

This is most certainly the best physics based shading solution on unity.

Highly recommended for every shining shader fans out there.

 

Not sure I understand what you said about the Fresnel term. I can see that there is increased reflectivity at grazing angles, but if there is no Fresnel slider then I can't adjust Fresnel reflection variably.
Care to explain how you derive the Fresnel value? Is it automatically derived from the amount of smoothness?
I've done quite a bit of offline rendering with mental ray, V-ray, Maxwell etc and you could always adjust the Fresnel reflectivity manually. Somtimes it would be based on IOR, but I don't see an option to set the IOR in your shaders.

Can you approximately say when you plan to integrate Skyshop support?

It's true that POM is not for every situation, in particular because it's not the cheapest algorithm, but it would be great to at least have the option to use it. Like a checkbox in each shader which enables or disables POM. I think that's also the way Unity is going with their upcoming ubershading system.

 

@ Bigzer Thanks for the bump, and for reminding us of some VFX variants yesterday that should totally be in the set!
(To everyone else, we're going to have some cool dissolve shaders in the next update!)

@ SeanM3D We start with an input to the fresnel called f0, which is the specular reflective constant that interpolates to white at grazing angles. This is 0.04 for dielectric materials and higher for metalloids. A combination of Base color and Smoothness then determine the visibility of this term. The reason for this is because we've tried to keep the controls for Alloy such that combinations of input always result in physically-plausible output.

Mental Ray, V-ray, etc. materials tend to follow a design-model of allowing you to change any value to any input, when there are simply tremendous ranges of values that no longer map to reality. The way many folks use fresnel (trying to blow out the specular rim), while pretty, isn't accurate to physical reality, and such manual tweaking tends to destabilize getting consistent results from the same material in very different lighting environments.

As for Skyshop integration all I can say is that it's on the roadmap, but we're going to be rounding out a few holes in the set in terms of variants first (some double-sided options for vegetation, some more fx shaders, and a tri-planar option). We're also going to get out our DX11-specific set first as we have those about 80% done, we just need to clean them up, and make a few examples for their use.

I will add POM to our growing wish-list though, as I do find that for ground-surfaces it does sometimes really pay off (if you can afford its cost).

I'm very much excited about the upcoming ubershader functionality (who, really, enjoys managing dozens of shader files? not us!) and I'm sure as long as there's not some curve-ball limitation that comes with it, that we'll reconfigure Alloy to that model the moment its available.

 

Did I understand it right that you hardcore all dieletric materials have an F0 of 0.04? If yes, isn't that an unnecessary oversimplification that robs the user of a considerable amount of flexibility? Maybe I just don't get it :-D

The mental ray A&D material is physically plausable, same with the V-ray material. Just because you can set the IOR or F0 and F90 manually, doesn't necessarily break physically plausibility. Even the Maxwell renderer, which probably comes closest to being physically correct, allows manually setting an IOR.

Fantastic!

 

@SeanM3D

In regards to F0: Yes you're correct that for dielectric materials that have a metalness value of '0', the F0 is 0.04 internally. This is a design-pattern was established by Epic in the new Unreal engine, as they found that a wide variety of materials ended up using this value, and it allows dropping a whole per-pixel texture channel (something that much of our pre-release feedback from Devs pushing webplayer games pointed to being incredible important). Yes, it does mean that the set here is less flexible than a Mental-ray shader (which are always designed with a kitchen-sink/maximalist manner because they carry a different set of performance constraints).

Our primary concern in designing this set has always been about establishing a fast workflow that scales nicely, and doesn't present the user with tons of parameters that will only be used in very special cases, or require tons of tweaking.

Importantly, the f0 DOES change as you ramp metalness up, as the Albedo/F0 each exchange the stored 0.04 for the base color. So if you want something with a higher f0, you can raise this to a value in-between 0 and 1. We're still very much weighing different options on the axis between control and cleanness. Having greater variance might be something better served with specialized shader-variants (glass, clear-coat, etc.) rather than dumping a ton of extra parameters into the core. Our earlier internal versions of these had many more parameters and maps, and when we demo'd these to folks working in production environments, the universal feedback was that it was too much. A tool that costs you time is a tool that costs you money.

Question for you and everyone else: One of the things we're considering is using the Blue channel of our current per-pixel (Metalness, OCC, Smoothness map) to set an f0 range within Disney's f0 range (0.00 to 0.08) so a middle-127 grey would set things to 0.04, which is far and away the most common value. This would add a marginal amount more data to things, and no extra maps.

If you've purchased Alloy and want to be part of a beta program for trying out features like this before they get built into the main pack, just send us a copy of your asset store receipt (as it doesn't give us your user names/emails), at alloy@rustltd.com and we can begin a conversation!

 

I reviewed the documentation and noticed color space has to be set to linear. So this won't work with gamma color space at all?

 

@Krileon Yes the set does only officially support Linear Space. While some may be attached to how Gamma-space looks in games, it results in irrevocably incorrect lighting, and would defeat the purpose of having a Physically-based system. As far as Alloy concerned, I just knocked the demoscene down to gamma, and what results is an incredibly over-dark scene (with only incandescent areas and surfaces being blasted by direct light showing up as very bright). I guess one could use this as a stylistic choice, but it would no longer be at all physically-accurate.

May I ask why you're asking about this? Did you have a specific thing that needs to be in gamma space for some reason?

P.S. At the risk of linking to something you may be super familiar with, this article lays out gamma vs. linear wonderfully: http://filmicgames.com/archives/299

P.S.S. I should also add that the only reason gamma-space lighting still exists (from a purely technical/pragmatic standpoint), is that the automatic conversion/sampling into and out of it for doing proper linear-space computation has to be supported by the hardware. This is why we don't yet have linear-space options on mobile, but likely will in the next year or so.

 

I've a few issues with my game in Linear color space at the moment and had already adjusted my colors and lighting for Gamma. So was curious how this would behave in Gamma, but as you've confirmed not so well I'm going to begin making all the needed adjustments for my game to look correct in Linear.

Great read, thank you!

I don't develop for mobile so that won't be an issue.

 

Looks really good and polished. Will definitely buy and test this out on my next project.

 

Hello xenius,

How would I use roughness in this asset?

Would roughness be the same as smoothness? I know it sounds obvious but is the end result the same?

I was messing with Substance designer 4 new PBR feature and was able to put the roughness into the defuse alpha channel, I then tested it with Jove's free shader and it worked like a charm. I was watching your video and I couldn't see anything on UI about roughness input.

I'm very new to all this stuff so please excuse my ignorance.

Skyshop +1 vote too

PS are there any issue with using this with substances?

Keep up the great work

 

@MoHoe: Allo!

Roughness and Smoothness can be thought of as opposite ends of the same parameter. In fact, a lot of shaders I've seen that use "roughness" have their max/1.0 be 100% smooth, even though they call it a 'roughness'. I haven't looked at Substance Designer's output to see where they have 1.0/0.0 aligned towards (either 100% rough or 100% smooth), but the data should be able to go in fine, and in the worst case you might have to invert the channel.

We use 'Smoothness' as the name of the parameter because the input maps looks the most like an old 'specular gloss' map tends to look, so its more conceptually clean to think about an increase in smoothness (ie sharper specular intensity) occurring with higher values.

When using substance, you should pipe the roughness from Substance Designer into the Alpha channel of the combined Metalness/Occlusion/Smoothness map that all Alloy shaders use.

I haven't gotten any feedback from folks using substance saying anything is broken, so I'm assuming things work cleanly within the bounds of the map-types Alloy takes in. Over the winter holiday I'm going to grab a copy of Substance Designer and see if there's a way for me to put together some clean substance presets that are already tied to the channel setup of the shader, to make things a bit less cryptic for folks working across systems.

Feel free to shoot us an email if you need anymore direct help with things!

 

Thanks for the quick reply xenius.

I don't like to ask this sort of question but I must. Are you planning on implementing some sort of GI solution in the future?

Thanks again

 

@MoHoe

Most certainly not, and for a number of reasons. I've seen some impressive endeavors here on the asset store forums, but thus far I've yet to see a system that can at all scale beyond the confines of small interior spaces without either a huge quality downgrade, or crushing performance implications.

There are the voxel-cone methods, that are (purely in my view) doomed to failure at this moment, mainly due to performance issues. Epic dropped VCT from UE4 for this reason. Not to knock the incredibly talented folks working in this community, but if Epic (with all of their direct access to GPU manufacturers) couldn't get it running at a reasonable clip when image-fidelity is so high on their priority list, I would take any claims made by equivalent systems for Unity with a grain of salt. I'd of course love to be proved wrong.

There are some other forms I've seen with radiance transfer and other techniques, but the results I've seen thus far (at reasonable perf. settings) are really still quite muddy/imprecise, break energy-conservation, and I'm a touch to OCD in terms of lighting results to really enjoy their output.

I hope this doesn't come across as too dour, as I really am enjoying seeing folks attack the problem. This is the engine-generation of seeing a plurality of approaches attack real-time GI. But for something as performance intensive, and utterly central in the lighting engine, and the baking process as GI, I'm personally waiting til a native solution presents itself. We've focussed our efforts with Alloy on integrating as tightly as we can with the core Unity systems, and I think with smart scene management, the directional lightmap plus light-probe approach to lighting still can provide stunning results, and at current is going to allow for _dramatically_ larger scenes with more content than anything running the current realtime GI systems.

 

First of all thank you for being honest and being OCD it's this sort of thinking I admire most.

"There are the voxel-cone methods, that are (purely in my view) doomed to failure at this moment, mainly due to performance issues. Epic dropped VCT from UE4 for this reason. Not to knock the incredibly talented folks working in this community, but if Epic (with all of their direct access to GPU manufacturers) couldn't get it running at a reasonable clip when image-fidelity is so high on their priority list, I would take any claims made by equivalent systems for Unity with a grain of salt. I'd of course love to be proved wrong."

I totally agree with you here and I too love to be proven wrong .. which happens often

"I hope this doesn't come across as too dour"

Not at all xenius, I need to hear "real opinions" from professionals that know what their talking about and are OCD

"I'm personally waiting til a native solution presents itself."

I purchased an GI asset but I had my doubts (it's still a WIP), I kind of looked at it as a little investment and at the same time a financial gift to the guy for taking such a bold task, which could end up driving him mad.

Well I think it's time to purchase your asset, not only because it's a fantastic product, it's also your way of thinking that instills confidence in me that you will develop this product further in the right direction.

Thanks for your time xenius.

EDIT:

Purchased!

Downloaded

Had a proper look at demoscene

Amazed!! WOW truly amazing!!

Exceeded my expectations

 

Hello xenius,

Are you going to release a shader that allows us to control the reflection amount?

Also what was your reasoning for not having this feature? Is it because you wanted to avoid people creating unrealistic metals?

 

Hi MoHoe,

Basically yes, there's no global 'raise reflection amount' variable specifically because to do so would break things in a physically-based model, by essentially adding light energy out of nowhere. Doing such a thing in a production environment is a pretty bad habit, as that extra reflection magnification is not going to give you predictable final results on your material when you pull said materials into various lighting environments. One of the whole points of Physically-based shading (aside from the sweet visual results) is consistency and predictability, so that manual tweaking of assets isn't needed every time the lighting environment changes.

Now currently in Alloy, we are using the cubemaps fairly primitively (until we add skyshop integration). If you want to maximize the mirror-like quality of a material in alloy (when using a Cube variant), its Metalness and Smoothness should be maxed, or nearly maxed out. I know this can be a somewhat frustrating/counter-intuitive thing to adjust to, when we're all used to blinn-phong shaders that just slap channels over things (resulting in materials that are simply impossible in RL). I feel its worth it though, as it saves so much labor time the moment you scale beyond a small project, and start having to manage hundreds-to-thousands of assets.

But yeah, we're sticking to the physically-plausible side of things with our set, both due to the sort of work we do internally, and because I'm seeing a number of the large studios going whole-hog into PBR (epic, crytek, disney, etc.) doing it, and they present really strong arguments for why its a discipline worth sticking to. Lastly, due to the way we've structured Alloy's code base, if you do want to go in and tinker/smash things apart, and mult. things together for special case exotic materials that don't have a realistic referent, we've set things up to make that as easy as possible, without compromising the integrity of the core.

We just pushed our 1.01 update (that's still in review), with an API overhaul internally that we have some tight documentation for. So once that lands, it should be even easier to copy one of the included shaders into your own variant, and mess with it mercilessly if there's something non-standard you'd like to do with it. This is also why we've built Alloy stringently around Unity's surface shader design pattern, with calls out to a separate file for the lighting functions. Feel free to email us if you need specific help tinkering with a parameter!

 

This looks grand! Theres a bunch of buzzwordy assets atm doing much the same thing, i ended up investing in jove as i was interested in where the very enthusiastic developer might take it, there's something nicely personal watching an asset grow like that, but in an ideal world i'd have all the pbr shading thingers and be able to match a suitable solution to my needs

Well, i suppose the fun thing is my use of physically based materials has been very limited so far, but it's looking exciting, especially in conjunction with a few of my other interests for composing scenes, and this looks like a very nice package - One magic day i'll have the money to spend but until then i'll keep following and hope the asset is maintained. Enjoying your very well stated and knowledgable responses to inquiries too, often sadly lacking in asset devs and reflects on your software extremely well

 

.....

 

Hi Mohoe,

Hit me up on skype (i pm'd you my sn). I'm up right now. It looks like one of the map inputs you're putting in is inverted or missing. It also looks like a couple project/object settings might be off. Don'tcha worry we'll get everything working.

 

Thanks xenius !!

Sorry I'm such a noob.. You've been so helpful.

 

@MoHoe:
Any chance you can post an image with the corrections? I am curious to see how your model looks with Alloy.

 

Hello n00body

The picture below is is kind of the look I want.

Old Victorian copper







It's probably not right for me to post a screen shot as yet, because I have to recreate the asset textures and setup the environment correctly.

Alloy is doing everything correctly, it's down to my asset textures.

I will post something soon.

I can tell you this much, i'm over the moon with Alloy. I recommend you purchase this asset, you won't be disappointed.

 

Hi everyone,

I wanted to make a quick announcement, as we've now had a little over 2 weeks of awesome feedback from you guys, and I decided that I want to be a little more open and comprehensive about our road map, and what we plan to be doing with releases over the next couple months, so those of you already using Alloy in longer term projects can best plan around it!

1.01: We've already submitted this update. It's primarily an API cleanup, with commented de-obfuscated headers, to make your lives easier extending the set to do whatever you need! I'll post here again as soon as it drops.

1.02: Parameter Re-design: One thing we've really seen these past two weeks is that you guys are HUNGRY for systems from the other talented folks here on the asset store working together. We've also been SUPER excited at seeing the new Substance Designer's workflow, and are going to be tweaking some channels around to make it easier for those of you using that workflow to use it (as well as making some sample graph layouts for it).

What this means is that 'smoothness' will be turning into 'roughness', and that channel will be inverted from what it is now. I still think *grump grump* that smoothness is conceptually cleaner, but the industry is standardizing around roughness, so we're going in that direction so the common asset pipelines interact more seamlessly with Alloy.

We're also going to be changing the way our cube-map variants are blending in the cube-map as a convenient stop-gap until we get full sky-shop integration done!

1.1: We've got this partially underway, and its mainly an update to drop in another half-dozen or so shader types, stuff I overlooked, and some funky ideas that we couldn't resist. We'll have a double-sided alpha cutout shader for vegetation (we'll see if there's something we can about back-lighting while keeping it deferred compatible). We've got some cool dissolve/transition shaders for all of you making power-armor, spell effects, 'splosions and the like. And beyond that we want to get a few more fx-oriented shaders in there, that will be trickled out with other updates, as we do them. Stuff like tri-planar, flow map water, and filling out some of the stranger variants for your convenience.

And Beyond: We've got DX-11 toys, Skyshop integration, and an Ubershader setup to tackle as our larger projects for Alloy. The ordering of all of this isn't set in stone, as we like to work the canvas, and often get side tracked by impulsive ideas that we HAVE to try now. We'll be continuing to update what we're working on in a loose roadmap as we work on this stuff.

Hope you're all having fun with Alloy so far. Try not to mind our dust.

 

You know, MoHoe, copper is kind of a tricky one. I gave it go, since that seemed like a cool test using Alloy.

 

@nervouschimp
Stunning results. I can't wait to see more.

 

Nice going nervouschimp.

old Victorian Copper is not dark brown, it has a tint of orange/brown... So there you have it, lol all I needed to do is make sure the color in the diffuse was as accurate as possible to a copper color.

This is great to know that Alloy is as accurate as it is. Now I'm just trying to find the most accurate color to match old Victorian copper.

I will post a picture soon

 

Looks great NervousChimp! The copper should be maybe a hair redder in its base color.

I just realized, I totally forgot to post a handy graph we have for RGB BaseColor values for various metalloids in Alloy that we've been using/testing through the whole process. I'll drop it into the next update/on the website, but until then, here's a quick ref sheet:

Note these are for Alloy materials with their Metalness parameter set to '1'

[TABLE="class: grid, width: 200, align: left"]
[TR]
[TD]Metal[/TD]
[TD]RGB BaseColor[/TD]
[/TR]
[TR]
[TD]Silicon[/TD]
[TD]<157, 163, 187>[/TD]
[/TR]
[TR]
[TD]Titanium[/TD]
[TD]<194, 186, 179>[/TD]
[/TR]
[TR]
[TD]Chromium[/TD]
[TD]<194, 194, 194>[/TD]
[/TR]
[TR]
[TD]Iron[/TD]
[TD]<194, 196, 199>[/TD]
[/TR]
[TR]
[TD]Nickel[/TD]
[TD]<212, 204, 191>[/TD]
[/TR]
[TR]
[TD]Platinum[/TD]
[TD]<212, 209, 201>[/TD]
[/TR]
[TR]
[TD]Copper[/TD]
[TD]<250, 209, 194>[/TD]
[/TR]
[TR]
[TD]Gold[/TD]
[TD]<255, 219, 145>[/TD]
[/TR]
[TR]
[TD]Aluminum[/TD]
[TD]<245, 245, 247>[/TD]
[/TR]
[TR]
[TD]Silver[/TD]
[TD]<250, 247, 240>[/TD]
[/TR]
[/TABLE]

 

Thanks xenius

 

Really nice!

 

Cheers Nervouschimp!

I call a toast to specular highlights (had to try one myself quick)



Really does need a cubemap though, didn't have one handy on this machine though.