UBER - Standard Shader Ultra

I set sliders to multiply values coming from texture so set them to 1 to have valhe unaffected. You can play with smooth min max sliders to range smoothness.

 

Macs dont like tessellation at all. Unity should detect it is not handled and use fallback but it apparently fails. Built in HD gpus are known to cause all kind of problems. I will provide pc as well as mac standalone build soon when I implement new features. You can select gph the demo runs on for standalone. Webplayer seems to be very bugy on mac.

 

Nope...no alpha...all rgb...same as the example texture. (which is jpg)

 

Heightmaps in UBER needs alpha channel not G channel. You can configure this. Advanced POM - this is not obvious how to use it as we need baked normals & tangents in texture. Right click on the header of mesh filter there us a tool to make required textures. I need to make a vid about it.

 

Grayscale from alpha then in advaced texture settings put compression to alpha 8 which works best with pom

 

Given the limitations of Apple's OpenGL implementation the Uber shaders web demo looks good on my late 2013 mac pro (Fire Pro D500 OGL 4.1).
Some screen shots of the web demo running in Safari:


The shadow seems to be following the non-displaced geometry profile on this torus.


Texture stretching as the object is rotated.


When I get a chance I will try the web demo on an older mac pro (OGL 3.2) and see how it does.

 

Hello, I recently bought UBER and am quite happy with my purchase. while experimenting around with material setups I was wondering about an additional feature that UBER currently doesn't have at the moment for rendering acrylic metallic surfaces such as car paint in conjunction with the glitter feature, Unreal's shading model already has this but its called Clear coat. here is an example image (Offline Path-tracer, not Unity) that I prepared to show what I am referring to:

Both materials are metallic and have the same base surface roughness and a flat albedo color but note how the image on the right displays some dielectric reflective properties as there is a thin transparent coat on-top with roughness independent from the base layer roughness (which is currently not possible with the standard shader).

if you think this is worth looking into this would be a great addition to UBER shaders already diverse set of features.

Thank you for your time!

 

Ok, Got it working in the example torus...but a new issue raised...when I add a default sphere...duplicate the material from the torus...(the super advanced POM shader) and I use that right click bake trick...my object looks totally cut holed. The orginal torus is super nice, but having a hard time to get this effect on my own models. (or default models)
Only 'basic' option in POM settings seems to work, but the object / texture is getting swimmy al over. So not really useful. The baked option isn't working. It gives me holes. The torus seems to be the only object which looks correct.
The tessellation shader however works awesome...!

edit: just played around more with the tessellation stuff...why in earth name would anyone use POM over tessellation in windows DX11? It instantly looks awesome...
so awesome that I can't believe I never got this feature proper working in RTP.

So what is the different here with RTP tessellation? And does it make sense to have the ubershader features / quality implemented in RTP?

RT

 

Hi Tom,

Bought UBER as an upgrade, and as a thanks for the uber-discount on RTP when I bought it last year.

I've just tried replacing the third-party rendering system I had been using in one of my scenes, and UBER gains me a non-trivial performance improvement (predominantly using the core UBER shader). Really impressed so far, and I'd like to consider making the full conversion to UBER across my project- a large undertaking as I'd need to regenerate all the substance designer graphs to suit.

The one aspect I'm missing, and can't really do without at this point, is vertex-colour influence in the albedo. Would you consider adding a slider to allow for this?

Appreciate your time,

Nick

 

Hey Tom ,

Great asset as expected from you ! Congratulations on the release !

I was wondering if it was possible to mimic moss on the rocks in place of snow ? I just can't edit the snow diffuse texture like it was possible with RTP shaders . That way it could be anything then just dynamic snow

I know it can be done with two layers as in vertex paint but that's a lot of work if you have a lot of rocks !

Thank you in advance !

 

W

Shadow on torus - it's not Z-write enabled - shadow caster/receiver is not displaced torus geometry - that's why it looks like this. But this technique is most expensive one on GPU load. When we can and it acceptable we should avoid complex shader object to at least cast shadows and use some proxy geometry for this.

Stretching - that's the issue of the technique on the edges, I know, but I guess you could finetune UVs on borders to minimize it. Maybe I'll look again into this example before updating.

Anyway - I'm glad it works fine. I know there is problem with webplayer and skubox is dark on Macs, but that's not my shader (Unity original cubemap skybox)... Substances can be tricky a bit, too on Mac - ear wasbadly textured.

ATB, Tom

 

POM Advanced with mapped curvature can be tricky and does not work on all models. Perfectly they need to have continuous UVs that are wrapped around (the case of torus ). In other case when ray goes beyond mapped area - refer to the other POM advanced object this "corners solved" - we have artifacts there. That's why I put UV cut to range the rendering at the top and bottom of the object. I'm thinking about possible workarounds, but none of them will be 100% effective. So - think of POM Advanced for special cases. Best usage is for cylinders with basic mode.

I'll make a few tuts on it, give me some time. I'd really like to submit update ASAP first.

You can use tessellation for detail layer in RTP to extrude all these small features upclose, why not. Turn it on in LOD manager ("heightmap detail" or something like this).

UBER features in RTP means RTP4 which I don't have any schedule for this yet, but I assume I could make it special some day if only Unity won't come up with their new terrain tools before. Working too hard on new terrain shaders means monthsd of work that might be wasting of time if Unity improve their shading pipeline for terrains considerably. nobody would buy mine then I feel wen something is for free...

 

you mean RGB tint (texture x tint x 2) ? It's easy to implement, I can add it.

I'm glad UBER core means performance gain for you. I'm quite concerned about it, because adding still new features the code is growing and performance is dropping, but if this is still performant - cool . I can't even judge it that well on my built-in HD4600 which is now something like rather low-end GPU, but I don't want to change it. I would get lazy I'm afraid to worry about performance... .

Tom

 

Hi Tom, that's correct, thanks!

Regarding performance, I did further testing with a small number of the more complex UBER shaders- trying to replace like with like compared to my earlier shader implementation. The rendering actually ended up with almost identical m/s to the other suite at set viewing positions in the scene- I should reiterate I've been very non-scientific in my testing though. Another main advantage to me is that the deferred replacement shader for UBER plays nicely with RTP and some other assets.

 

RAM Issues and shader variants.

Hi Tom,

I would recommended to split the great basic shaders for it self. So developers can decide to use refraction or extrusion or snow or POM without any variants. And further, its seriously too much that the shader are using only 3GB of 5GB if you have optimized this already (but for sure we will see). In my opinion its totally over dozed currently and doesn't fit any requirement of a serious game or 3D application in this time.

Kind regards

 

@Quatum1000 I think you're misunderstanding - shaders don't use that much RAM at all and don't really differ in that regard from any other shaders like standard stock one. What hogs the RAM is the shader import process which handles branching variants poorly. This is Editor-only issue on Unity side, which has nothing to do with performance of the shaders themselves and has no impact on requirements in the saved builds.

 

@bac9-flcl
You shouldn't forget that the Editor is for sure required to create any build in this case.
So.., does that mean I have to buy +16 GB to Develop with Uber?

So tell me:
How many ppl with buy Uber and will find out that they can't run their previous project? Perhaps then they will rate it bad. This will bomb the business, and you can be assured about. Because It doesn't matter if Unity handles branching variants poorly or whatever. The workflow in the editor is also taken into account by any product of the asset store.

The best would be to sort out the problems as fast as possible and find a solution with the Unity Team. And providing the users with any basic single shaders as long as that heavy issue occur.

 

I don't like the idea of forcing users to buy 16GB to use UBER either. With update I reduced RAM consumption 4x. If core shader (POM with all core features) is enough for you - develop with this. Would require only 150MB in editor. Don't import the other shaders. The problem is that my example scene uses many different variants, essellation, 2 layers, triplanar, refracion ones - it makes number of shaders used increased. It's not however necessary in common scenario. Do you plan to build another UBER showcase ? Then you need to buy more RAM (8GB preferably) .

I'm close to submit update anyway.

Tom

 

Hi,
I bought the package after reimporting models and textures everything got fixed except the candle shader, It's not shining!



And the ice example is not included

Unity 5.1.1f1
I7-2600K
GTX 770 OC 4GB
16GB Ram
DX11, Gamma , Deferred , PC-Mac-Linux.





Thanks a lot.

 

Ice example is 3rd party model which I can't include. Just tested this again on my side - candle is working fine.
Win7, intel HD4600 GPU (built in). U5.1.1f. Works in forward and deferred.

I'm working now on the updated version of UBER though. I can't remember, but I probably didn't touch candle flame shader since initial release. It's bonus one anyway - so - no claims on it, please

Tom

 

Well,

New demos are available. When nothing wrong come up I'll submit package Monday.

Web:
http://www.stobierski.pl/unity/UBER.html

PC x64:
http://www.stobierski.pl/unity/UBER_showcase.zip

PC x32:
http://www.stobierski.pl/unity/UBER_showcase_32.zip

Mac:
http://www.stobierski.pl/unity/UBER_showcase.app.zip

Linux:
http://www.stobierski.pl/unity/UBER_showcase_Linux.zip

Some of new feaures available (introduced so many tweaks in the whole package that I can't recall them all ). Dissolve with edge emission, emisive water with "magma" switch, dynamic weather controller and a lot more small tweaks:






ATB, Tom

P.S. Added also this requested coloring diffuse texture via vertex RGB.

 

Wow, impressive update. Thank you for the dissolve! Could you apply the ice to something sharable? Its gorgeous!

 

Yeah Ice looks amazing, so does the dissolve shader! Great update!

 

I made an icicle model using Zbrush so you can put it in your package if you want.(I will send if you tell me)
Normal Map, AO, Height, baked from high poly to low one(I can bake other maps like cavity if needed).


I know it is not so good but can be useful.

The demos are really cool but it is better to make an option for turning on the Vsync.
And the rain and snow particles were not visible.(PC X64 version)

And I have a request :
I am really interested in a sand shader like we can see in Dragon Age Inquisition(check the screenshot below)
It is too much like the snow shader but I couldn't achieve it using your shader. It may need some tweak in the codes.





Thanks a lot.

 

Sand should be pretty similar to snow, just far less reflective. The soft, wrapping look of the shading is achieved with a bit of diffuse scattering, which is already supported, I think.

If you need to create a terrain like this, I'd recommend purchasing RTP, though - it has the same feature set, so you'll be able to do direction-dependent overlays like snow, diffuse scattering and other stuff there too, just with proper integration into the terrain system and with a variety of tools helping to blend your objects with that terrain.

 

@bac9-flcl
Thanks for your advice.
I already know about RTP but terrain is not what I need.
Think about other objects in a desert or imagine a dusty and old basement.
Actually I couldn't achieve a good dust or sand feel with the snow shader,mine is looking like brown cream :-\

 

For some reason when I include Uber in my unity project, it increases my build time from a few seconds to like 15 minutes most of which my computer becomes unresponsive. I litterally just import Uber, I havn't even used it on anything and it increases the build time.

 

Special niceties like diffuse scattering aside: generally, this has nothing to do with the shader and everything with properly authored PBR textures. Maybe your albedo is wrong, maybe you set smoothness wrong, or something like that. Shader won't make sand sandy or wood woody, you have to have very precise values in your maps, that's when that happens. Try Quixel DDO materials or samples from Substance Designer or find some free online library of PBR values. You should be able to get pretty convincing sand and dust with just the Standard Unity shader, not even UBER is required for that.

 

I know what's wrong on your side - check if your camera is set to HDR. Turn off MSAA in Quality settings - it disables HDR rendering which is needed for the candle flame to work.

Tom

 

It's about RAM consumption in Unity. It allocates some RAM for shader variants which are not even used. In the update ti will be decreased by 4x. Still - it's advised to have these 8GB RAM and x64 editor. 4GB might be fair enough if you use only a few shaders (unlike in my example scene which needs 7GB to make a build). Simply - don't import these which you know will be unused anyway (most of them - refraction variants except for basic "core" one) and setup that you unuse (either metallic or specular). On my strong machine (16GB RAM hi-end i7) it also took a long time to make a build now it's done in a minute. Unity probably iterates through all shader variants and handle them somehow. That's why build time increase is insanely exponential...

RTP snow/sand doesn't have glitter feature which brings a lot into micro surface "feel". In time I'll update RTP to be capable of this, but RTP4 should not be expected soon.

Tom

 

Quite awesome! So am I correct in assuming that it's written as a hull/domain shaders, and if I wanted to modify the tessellation algorithms, that's a fairly simple change (uhh, simple on the relative scale)? Or if you already have PN triangles, and a few other options like that... but if not I have the algorithms here. This would save quite a bit of time of digging through their shaders.

Already bought it, but I wanted to check as I'm finishing GPU-based flow simulation right now and won't get to play with this for a few days... and on that note, if RTP has that, too, I might pick up the RTP pack too... I could definitely merge features from my shaders with that.

 

Just curious, has the lower memory update been submitted? Thanks!

 

I have not submitted this yet. Want to check possibility to make it Alloy friendy in deferred (in forward systems are independent). Current state is:

1. We use normalmaps, if you don't need it - copy shader and turn it off manually (#define _NORMALMAP 0). I placed 4 simple shaders that not use normalmap
2. We use spec/gloss (metallic/gloss) maps. They don't introduce any considerable cost when left blank, but if you want to make shader even cheaper - copy shader needed and turn it off (#define _SPECGLOSSMAP 0)
3. I split shader with separate dynamic snow. You will not notice this when working - checkbox for snow feature does not handle shader keyword now but replace shader instead. Ease of use and workflow stay the same
4. In forward you decide which type of fog you use (default - off) and check this in config file.

This means 24x less RAM needed. My example scene where a lot of shaders are used needs around 800MB at peak when making build. In real scenario you probably won't use that many (thus - even less resources needed)

This moment UBER will become very resource friendly solution.

Tom

 

I'm very interested in this- the two shader suites are potentially quite complementary rather than competitive. The Alloy deferred replacement shader uses a bespoke lighting path which expects lights to have a far greater intensity to have the desired effect. This is a problem for me as there's then too much of a difference in lighting between forward and deferred modes on non-Alloy shaders, so things like ocean reflections look massively overbright because they are occuring in forward, but mirroring objects that are in deferred. This was particularly pronounced with terrains using non-Alloy shaders.

Anyway, if Alloy shaders somehow just worked with the UBER replacement shader, which has light intensities that are more interchangable with the default deferred system, all would be well- there's great elements in both.

 

UBER vs Alloy is not only shader output problem for standard values like diffuse color, specular color, roughness, and so on. UBER comes with parallax mapping with self-shadowing and translucency features. They both make usage of GBuffer "unused" channels. As different solution make usage o funused GBuffer channels - they start interfere...

So, I moved translucency to emission.a channel which is not used by Alloy. In fact - using this GBuffer data is awkward because we don't have direct acces for it in lighting pass. Need to play with command buffers and make temporary RTs for it. Anyway - now UBER and Alloy won't interfere and I will try to make UBEr output to fit more or less Alloy.

The problem arise when somebody would like to use UBER translucency and POM self-shadowing with Alloy using Alloy's deferred lighting. hat's a bit hardcore - you need to put UBER routines inside Alloy lighting shader then. Currently I'm investigating this option. As Gbuffer doesn't interfere it's definitely possible, but the question is -how much I need to tweak Allo's deferred to get both Alloy and UBER features working togheter. Using UBER with only forward passes is no good - esp. with translucency which is great when we have a lot of point lights in the scene.

Tom

 

OK, was pretty messy to achieve, but I put translucency data in deferred into unused channel of emission GBuffer. Working with this is awkward because Unity use it for screen output and lighting. But the problem is actually good - it is a bit prohibitive for use unless you've got a lot of patience to make it working. That's why UBER won't break with most common 3d party solutions.

So Alloy works with UBER in deferred now, actually BRDF of Alloy with POM self-shadows from UBER and translucency looks pretty nice:





However, in deferred we can't encode that much data in Gbuffers, so we've got common translucency setup for all objects - they can control translucency strengh (with mask) and color used - up to 4 colors can be used. In the example - marble will have white translucency color while ear will use red one.

Good things about rewriting code for emision is that buffer is 16bit per channel (in HDR, in LDR translucency doesn't work in deferred, but I assume people go for HDR in PBR anyway). This measn - beter resolution than before (no banding on translucency) - it looks as good as in forward.

I'm on the final stage of testing. Hopefully tomorrow UBER 1.02 will be submitted. I believe will be very good update which solve most of current problems and bugs.

ATB, Tom

 

Sounds fantastic, thanks Tom. For the non shader-savvy, when you say that UBER and Alloy work together, which replacement shader would this be using in deferred? Hoping it's the UBER one, but if not, would it be possible to also have a look at RTP playing nicely with the Alloy replacement light paths as well?

 

Tom, I just bought this asset. Fantastic work. It works great with my B2M workflow and produces some fantastic results.
Thanks, Good job.

 

With Alloy - UBER will use Unity's PBR in forward (so in transparent shaders, too) and Alloy PBR in deferred (when selected in Graphics settings). Uber simply output things neede into GBuffer and lighting is made on Alloy side. RTP in deferred is the same - it outputs "some physially based properties" into GBuffer and Alloy can get it for lighting. As far as I know some people used RTP with Alloy already.

Nice to hear . Even if it works fantastic (currently mostly on DX11) I would advise to uninstall it and install again when UBER update is ready. Fixed a lot of things and added a lot fo features. Resources are also not stressed anymore with udpate version.

Tom

 

I was using RTP with Alloy for a while, in deferred. However it does look quite washed out compared to the Unity/UBER replacement shader's light path- I'd expect to adjust RTP values to the Alloy path, but couldn't reach the earlier quality. And the deal breaker for me was the RTP terrain's reflections seen in Suimono water surfaces- while the terrain itself is rendered in deferred, the reflections are forward, and look overbright. The Alloy shaders are designed around this disparity, whereas other shaders look markedly brighter in forward with lights set to Alloy deferred values- I'm not articulating this well, see my original report on the Alloy thread.

 

Now I see your point. RTP uses own lighting, (custom lighting functions) not Unitys. With point lights set to that big value (the problem is with falloff of high hundreds meters range not intensity I guess) Unity/RTP will get huge overbright there indeed. The only solution for you would be tweaking lighting functions in RTP. Find

CustomLighting.cginc. Inside there is such function:

Code (csharp):

1. inline fixed4 LightingCustomBlinnPhong (RTPSurfaceOutput s, half3 viewDir, UnityGI gi)

using #ifdef UNITY_PASS_FORWARDADD you can determine if point light is used. The function above uses this:

Code (csharp):

1. RTPLightingCustomBlinnPhong (...)

and it relies on lighting computed by Unity by calling UnityGlobalIllumination()

so data.atten also comes from there with point light attenuation. Hacking, replacing fall off there would help you.

But this is rather question for RTP foruym thread.

Here I can inspect point lights treatment in Alloy vs. UBER. If falloff intensity is that different I'll put some #define switch in my UBER config file to match Alloy values better. This way UBER forward objects will not break when used in Alloy and this is probably you'd like to ask me for.

Tom

P.S. I'm in contact with xenius so we proably figure something out together if I can't do it alone. Not sure if for this UBER update.

 

@tomaszek
I'm happy that I always first import new packages into a blank project.
I'm encountering lots of bugs with your package unfortunately.
Now when I change your shaders mode to transparent the whole model become hidden and worse than that most of the shaders are not processing the albedo texture and it's color
Did you ever watched Terminator 2, every new material I make based on your shaders are now like the T-1000 in that movie the old materials are ok.
I re-imported the package twice and even once deleted it completely and imported the package from scratch but it became even worse because now some of your own materials are pink now.
The last thing I did was deleting all folders of the project except the Assets folder, the transparent ones are now fixed but the core shader still doesn't process the albedo
Actually I wont do this to my main projects, so I wont import the shaders into them right now.
Hope the next version is ok.


@others
For those who want to test an ice shader, You can download the very simple icicle model I made from the one of the links below :
AO, Height, Normal ,Thickness textures and both very high poly and low poly models included.

The whole zip file is only 14.9MB

http://www.mediafire.com/download/mj72m22rx80fsax/Icicle_model_for_Uber.rar
or

http://www.mediafire.com/?mj72m22rx80fsax



Sorry for my bad English.

 

those bugs that @Hotsun is refering too, I got them too. Package is not usefull for serious production. :-(

 

Let me quote xenius:

Yes, he is perfectly right. We hate do it, but I made this for you...
If you'd like UBER shaders to keep the same light falloff in FORWARD (for example transparent materials) look into UBER_StandardConfig.cginc and set #define UBER_MATCH_ALLOY_LIGHT_FALLOFF 1

Now tell me that you love me .

Tom

P.S. Works for UBER, for RTP I will look into this later, but probably it's not possible as RTp is surface shader where I've got barely access to any vertex program interpolators except for these exposed by Unity. As a workaround you can use double point light setup:

1. first set of lights should influence Alloy objects and RTP in deferred
2. second set of lights should influence RTP terrain - enable them as soon as your water is about to rendered and use light culling mask so they only influence RTP.

Tom

 

Could somebody provide me via PM with UBER order number. I need one for testing early access to UBER1.02 on my server.

Tom

 

Sent

 

I'll play Barry White as I edit those #defines..

Thanks!!!

 

I willl submit this on AssetStore tomorrow, but as we know it will take some before is going live...

So - here it is. Exclusively for my beloved users :

http://www.stobierski.pl/unity/UBERUpdate.php

Provide it with order number WITHOUT leading "OR" and purchase date in proper format (YYYY-MM-DD). They need to match.

Enjoy, Tom

EDIT: UNINSTALL current UBER folder before installing update.

 

Your constructive criticism really helps here. Have I reported all of users about progress, posted new players for test ? Haven't I ? Have I worked last 3 weeks hard to make Mac users happy ? Haven't I ? (They are in minority anyway... but often think everybody has openGL machine to work with...). How would you envision me to be more involved ?

Now I can tell it - sometimes you just miss a bit of good manners...

Tom

 

it wasn't meant to be disrespectful against all of your hard work and involvement. Just saying that the package actually just don't really behave well on a clean install. I wouldn't dare to rely on the new shaders currently on a serious production. Paging through the forum just proves my point. Only way to get decent results is to actually modify your examples. On a fresh clean scene, I cannot get results and bugs are similar to those that already has been reported. On PC btw. Not on a mac. So, I am also waiting for the next version and hope that a lot has been fixed.
Anyways; I will take care of what I am posting here in future sessions.
RT