[Released] Lux URP Essentials

Thanks for the response. After looking in the render feature script, It seems like I manage to fix it by changing 'renderPassEvent' from 'BeforeRenderingShadows' to 'AfterRenderingShadows'. It's work on single pass. (I didn't use single pass instanced so just ignore that there are still problems.)

 

oh, that is very fine! thanks for sharing!

 

Hi,
The water works fine on Oculus Quest single-pass but the same build has some issues on Gear VR. As shown in the video: https://s3.eu-central-1.amazonaws.c...ty+2019.3.9+URP+7.3.1+Lux+Water+on+GearVR.mp4
Some parts, such as the foam, rotate with the camera.
Could there be any fix?

 

i have no gear, and lux water has no official support for vr or gear.
i am sorry about this but that is how it is.

 

I have two questions:

First, I like the Kajiya-Kay for certain hair, but have you seen the Scheuermann model for hair? -- It seems like it could be a great option to get that final touch of realism. Seems like you could maybe offset based on luminosity or perhaps tangents via some voronoi noise to get a similar effect? -- This could be especially handy for anime/cartoon style hair as much as it could be for real hair.



Second question:

I don't know if you've seen the Star Wars Battlefront terrain blending, but see this video at timestep 38:18 -- it's magic:
https://www.gdcvault.com/play/1023272/Photogrammetry-and-Star-Wars-Battlefront



They use a world-space detail map to allow kit-based meshes to be dropped-in, blending in with terrains/tesselation displacement and the terrain's own world-space detail map. Can Lux do this, and if so, does it support tessellation?

In my opinion, something like this is essential to blending terrain with things like overhanging cliffs, etc. I could seriously use something like this in URP.

 

i did. it is based upon Kajiya-Kay. so no reason to go nuts

i know this of course. lux urp essentails does not support tessellation. and it does mesh/terrain blending quite some different as we do not have a deferred shader here: it blends meshes in the frame bufer.

 

Haha, no problem. I had a sneaking suspicion this looked eerily close to what you have already.
That being said, is there an option to get that Scheuermann look with Lux currently?
I can see many cases where this look is preferable to Kajiya-Kay in my own artwork.

Oh well...
At least you're familiar with it!
That said, isn't URP planning to offer deferred at some point? -- If so, this is a must-have when that happens.

For now, how does Lux handle its different kinds of blending? -- I don't recall seeing any good examples of it on the Asset Store page (and I may have missed it somewhere in this thread), plus I'm curious what methods are used for the different kinds of blending -- i.e. mesh, rock, and terrain blending -- and I'd also like to know if they're compatible with one another to use simultaneously.

 

I didn't bother asking much I just bought it before the sale even, I mean it's so cheap, right?

 

so.... what?

 

So I would recommend people just buy the asset, it is low risk and quicker.

 

Great package, well put together. I am wondering if you can help me with something with regards to your Decal shader. I am trying to create unit selection circles as used in an RTS. At the moment the behavior of the Decal is that if the terrain falls outside the extents of the decal volume then no pixels are shaded. I was wondering if it is possible for me to somehow customize the shader so that if there is no terrain below the base of the projection cube it would still draw the circle with the base of the projection somehow behaving as surface. See the attached image for an example of the behavior I'm looking to replicate.

https://ibb.co/7JXR0SN

 

thanks.

right out of my head:
the shader uses "clip" to discard pixels outside of its volume. as you want to shade pixels which would be clipped we somehow have to limit positionOS to stay inside the bounds of the decal volume.
you could try to use the "IntersectRayBox" function from the BoxVolume shader to intersect the the viewRay with the box volume to get "far"
then something like:
positionOS = input.camPosOS + input.viewRayOS.xyz * min(far*0.999,depth);
might do the trick.

another possibility: add a plane at the bottom of the decal volume that uses a shader that only writes into depth.

 

Hey lars,

Im finding the custom nodes very helpful but was wondering how you created the transmission maps for the foliage. I know the stems are painted darker for less transmission but where did you get the finer details? Also, with a SSS map do you have any workflow ideas to get the transmission map? Just looking for some insight.

 

photoshop.

xnormals or substance painter e.g. lets you bake such maps. some people also invert the normals and bake out ambient occlusion.

 

Ah excellent, i never thought about using xnormals but it makes sense, i will also look at substance painter. Thanks for the insight!

 

I have a question before purchasing the asset: We intend to use the skin shader in an AR application with ARCore/ARKit. The description mentions asset compatibility with Vulkan, but Vulkan is not supported by ARCore. Will Lux skin shader work with OpenGLES3?

 

as far as i can say: yes.

 

@larsbertram1 Love the work done for your Toon Graph Shader!

I was wondering if there is a baked lighting equivalent for them? I am facing an issue where if I were to change my directional light from 'Realtime' to 'Baked' the objects will be rendered dark (not receiving lighting) compared to keeping the setting 'Realtime'.

Attached are my lighting and Lux Toon Graph material settings for reference.

 

unfortunately there is not afaik.
when it comes to lightmaps the lightmapper calculates NdotL and combines it with the light color and the ambient lighting already. id o not know any good or cheap solution to split the single color value you get from a lightmap into attenuation based on slope (NdotL), color and ambient lighting.
so i doubt that you a) can properly reconstruct the needed inputs from a lightmap and b) in case you could that it was significantly faster then using real time lighting.

 

As of May 25, 2020, Lux URP / LWRP Essentials is the latest version 1.44, but the version in its binary shows 1.38. Which version is correct?

 

version 1.44 should be the latest.

 

@larsbertram1 Thanks for the reply. In that case, would you advice to use realtime lighting instead of baked lighting?

 

well, that works. so yes.

 

Is there a way to adjust the back lighting?,I mean it gets to dark sometimes

 

this depends on the ambient lighting as far as i can say.

 

Is there no way to adjust that ambient light power or to replace it with a solid color(or combine both)?. I looked in the code but is over me to understand what happening there atm.

 

Hey there. I'm having troubles with the unlit decal shader. It works very good and exactly how I needed except for one tiny little issue - there's always a very tiny line at the edge of an object that is not affected by the decal projector.

I tried different gradient textures but regardless of them, this effect always occurs.
Any idea what might have gone wrong?

 

Alright so I tried different shader that I found on github and it's doing the same thing, so it's probably not shader related

 

first of all you could try to tweak your billboard 's Normal Direction (in the renderer component of the particle system). set it to something like 0.1 - 0.5.

then you can tweak ambient lighting. you fill find it in: Lux UR Particles Simple Lit Forward Pass.hlsl
line 145: OUTPUT_SH(...) will sample the ambient lighting from the provided SH lighting based on the normal.
it will write to: output.vertexSH
so you can replace it like: output.vertexSH = 1;
or add something on top, mix it – whatsoever.

you also may enable transmission.

nevertheless: the particles in the provided demo do not look too dark imho. so maybe you have a look at them first.

 

the shader uses gradients. these are always calculated using 2x2 pixels. i guess this is what causes your issue.

 

Thanks for your answer.

Is there any way to prevent this from happening though?

 

unfortunately: no. this is just the way GPUs work.

 

i just wanted to say that the lit shader does not work with the urp version 7.4.1. i hope this will be fixed soon

 

what is broken for you? i just updated latest lux urp essentailas from 7.3.1. without having spotted any issues yet.

 

Any updates on how this is working running on the quest so far?

 

no, i have no quest. anybody else?

 

Noticed yesterday, after I upgraded to 2019.4 that the Lux URP/Human/Skin shader does not work with Shadows:

• using a Directional Light Casting Shadows on a Mesh that Casts Shadows results in a PINK Error Shader

Shader warning in 'Lux URP/Human/Skin': implicit truncation of vector type at line 290 (on d3d11)



Compiling Fragment program with _MAIN_LIGHT_SHADOWS _SHADOWS_SOFT

Platform defines: UNITY_NO_DXT5nm UNITY_ENABLE_REFLECTION_BUFFERS UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 SHADER_API_DESKTOP UNITY_LIGHTMAP_DLDR_ENCODING

• Switching OFF the shadow casting of the Directional Light fixes the issue.
• Or switching to a Spotlight that Casts Shadows fixes it.
• Or switching OFF the Mesh casting shadows fixes it.

 

rendering should not be related to the unity version you use but the version of urp.i tested it in 2019.3.7 using urp 7.4.1. and everything looks fine.
which urp versiion do you use?

 

I'm using URP 7.3.1 as it is verified for 20199.4, But even when I upgrade to 7.4.1, I still get the pink error when the directional light casts shadows. A little strange.

 

which api do you use?it works totally fine using dx11.

 

Hello.
I'm on URP 7.4.1.
The decal system works in editor, but doesn't in (win) build. I installed the included 7.1.8 package because decals and volumetrics didn't work at all at first. Now they both do - decals inside the editor and volumetrics in editor and build. Just need to fix the decals system so they work when I build.

Also: any easy way to limit decals to ground/terrain only?

Thanks.

 

it does for me using Lux URP Essentials 1.44, URP 7.4.1. and Unity 2019.3.7f1 on win10.

for me they work like charm. and using the 7.1.8 package along with 7.4.1. will break all shadows from directional lights. i highly recommend to create a new project and then import in the latest version of Lux URP Essentials.

you should be able to use the render queue or stencil buffer as shown in the demo.

 

Yeah, I'm also using direct3d11.
This is the error that's causing issues and haven't found a work around, other than turning off shadows.

Code (CSharp):

1. Shader error in 'Lux URP/Human/Skin': cannot implicitly convert from 'const float3' to 'float4' at line 290 (on d3d11)
2.  
3. Compiling Fragment program with _MAIN_LIGHT_SHADOWS _SHADOWS_SOFT
4. Platform defines: UNITY_NO_DXT5nm UNITY_ENABLE_REFLECTION_BUFFERS UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 SHADER_API_DESKTOP UNITY_LIGHTMAP_RGBM_ENCODING

 

you may try changing line 290 to:
inputData.shadowCoord = float4(input.shadowCoord.xyz + input.normalWS * _SkinShadowSamplingBias, input.shadowCoord.w);

 

Is that the only option? That would be almost like starting from scratch. I'd rather just remove and re-import LUX and maybe lose & fix stuff in 2-3 scenes + some prefabs that use the shaders than lose 4 solid months of progress - if that's possible.

 

I got this mostly for the Lit Extended Über Shader. I was very suprised to find out Unity removed the heightmap option from their Lit shader after getting everybody used to the Standard shader in the built-in renderer. Especially when so many textures comes with a heightmap.

I have a request that I think would be easy to implement and a lot of people will find useful:
Color swapping. What this would do is simply replace colors in the albedo.

The idea is you tick a "Colorswap" checkbox below the base texture and you get the option to enable up to 5 color swaps (you get one enabled when "Colorswap" itself is ticked and then there's four checkboxes to enable more).

 

You probably get what I mean with my request already but I'll explain it in detail anyway:

A color swap involves three settings: A "from" color, a "to" color and a checkbox that makes the shader also replace darker variations of that color. Alpha is ignored in the from/to colors.

Example with darker variations replacement if "from" is "ff00ff" and "to" is "00aa00":
1. "ff00ff" becomes "00aa00".
2. "fe00fe" becomes "00aa00" (not enough percentage change to reduce "to" color).
3. "770077" becomes "004f00" (53% reduction).
4. "fe00ff" is not replaced because it is not a darker version of the exact same "from" color.

This feature would be very useful for people making team-based games, like an RTS where every player's unit looks the same except a stripe of team color. Secondary color swap could be used to either support team flags with two colors or it could be used to show promoted units or special units etc.

Having color-swapping in the über shader means you don't have to complicate things and waste resources with another material just for team colors.

 

I guess the hardest thing about this would be to make it look nice when the "from" color blends/fades into another color. The swapped exact "from" colors should expand into these non-exact blended colors, but the non-exact colors shouldn't be modified unless they are connected to an exact "from" color.

If my request is too complicated to implement I would like to simplify it with an "Alpha Replace" checkbox on an Opaque surface type.

This adds a single color on all pixels with an alpha value. It would blend nicely and (I think) easy to implement, yet super useful for a lot of people. Makes it possible to have team colors on Opaque textures.

If the alpha replace happens after all the Alpha Clipping stuff it should be possible to both have alpha clipping and alpha replace?

Sorry for triple posting.

 

you can import it to a new project and then manually copy the files.
or you can get rid of them (back up!) and reimport.