With the Lightweight and HD SRP we are not supposed to include UnityCG.cginc anymore, but that file contains a bunch of handy functions which are missing from the Lightweight and HD include equivalents. This requires a lot of shader refactoring. Why not add these missing functions?
I feel your 3 threads about almost identical things could have been 1 thread.
There is one post with one identical item out of 4, which is why I included the link to that item. But not all 3 post are identical because one post is specifically for HD only (camera relative rendering).
In case you wonder why I made a separate post for the camera relative rendering shade issue, it is is because I was told to do that in the Beta forum by one of the UT employees. He said I should keep posts for HD and LW separate.
Are they are still looking for moderators?
1 Like
Did you ever figure out where the UnityCG.cginc alternatives were / how to replicate functions?
I just copied the missing functions from UnityCG.cginc and put them into my own include file. I just don’t understand why it is not included in the new LW and HD versions as these functions contain nothing fancy. Just some math.
No, but you’re responding above to a non moderator and non staff. As far as I’m concerned, your behaviour is correct.
We are currently still heavily changing the shader libraries for Core, HD and Lightweight so nothing is set in stone, right now things that are not needed by the pipeline are being left out, as it is all code that bloats any shader(precompiled) and slows compile time so having functions that are not needed by the core rendering makes sense to not be included.
One major point of SRP is to ditch a lot of legacy code that is bloating the legacy render pipelines, this is the only way we can go forward and more importantly open the rendering up to users for full customisation.
In saying that I’m sure we are missing a few functions that will be useful to you guys, feel free to post a list of functions that you have run into needing to use that don’t exist in the current SRP libraries, if we feel that they would be useful across the board we will look into adding them where appropriate.
2 Likes
I am all for bloat reduction. Maybe you can add a separate include file, not needed by the core SRP?
The functions I need for my shader are:
ObjSpaceViewDir()
UnityObjectToViewPos()
1 Like
These plus a reasonable way of getting light direction for different types of lights would be great
For lightweight this is very straightforward as it’s a forward only renderer so we have set buffers for the light data, we also have two functions:
Light GetMainLight()
which gives you the main lights data
Light GetLight(half i, float3 positionWS)
which returns the additional lights based on the index you ask for, this lets you use it in an loop if you want to light all additional lights
for eg(from the lighting.hlsl):
for (int i = 0; i < pixelLightCount; ++i)
{
Light light = GetLight(i, inputData.positionWS);
light.attenuation *= LocalLightRealtimeShadowAttenuation(light.index, inputData.positionWS);
color += LightingPhysicallyBased(brdfData, light, inputData.normalWS, inputData.viewDirectionWS);
}```
Actual light direction isn't stored as it is recreated by the offset in word space from the object being rendered to get the direction from the object, we do store it for the main directional light but thats about it.
Again this is all going through changes right now so all of this might change.
[quote="Elecman, post:8, topic: 700302, username:Elecman"]
I am all for bloat reduction. Maybe you can add a separate include file, not needed by the core SRP?
[/quote]
Funnily enough I needed this for a water shader I was working on and did the same, copied it out from the UnityCG.cginc and had it embedded in the water shader, I believe we may have simply just missed adding that in along the way, all the transform functions are changing right now as it makes no sense for HD and Lightweight to have the same functions locally so these will be moved to core, I'll bring up adding these two.
3 Likes
Thanks this was exactly the info I needed!
Very glad you included the call to getting the actual light count using GetPixelLightCount (which I had no idea existed). Should be able to get a decent start now with this info
Hey guys, I’m writing some documentation on shader and we are some of the shader and C# API for LWRP based on feedback we received. Meanwhile don’t refrain from posting the things you feel are missing or that could change. We are taking all of that into account.
Rendering meshes on top of anything else while receiving lighting correctly and casting shadows without 2 camera overhead (first person melee in my case) for HDRP and LWRP. It’s a super common use case for everything really. Do we need 2 cameras for such a common use case?
Thanks 
1 Like
Hi, i’m trying to use the Light mainLight = GetMainLight(); Direction = mainLight.direction; in Shader Graph code, but i always get the error
“Assertion failed on expression: ‘success’
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()”
And it returns nothing.
Sorry. I completely missed your message. No, we are going away from camera stacking approach as this is bad for many reasons (extra culling, extra bandwidth, problems like you said to resolve shadows).
So, we are prototyping a solution that will allow this. I can’t promise anything yet in terms of when we do it but I’m super excited for this as it’s a major workflow improvement.
This solution would make the renderer and all render passes in LWRP data driven and customizable.
So you could 1) inject easily custom render passes in the LWRP renderers 2) customize the built-in ones, f.ex, tell the RenderOpaquesPass to render specific layers and specific shader passes. This would also solve the lack of rendering all passes in a shader people have been asking for in SRP.
This way you could, render your character/guns/hands in shadowcaster pass by adding it to a specific layer that only the shadow caster pass renders.
Then in the render opaques/transparent you inject a custom render pass for rendering the gun/hands. We might also provide with LWRP a render pass that renders object with custom camera matrices/fov so devs don’t have to create it, just add it to the renderer. But also, can’t promise anything now.
1 Like
For shader graph feedback/issues I’d recommend posting here: https://discussions.unity.com/t/687913
Hi,
How to get " unity_StereoEyeIndex " in the shader graph (LW)?
Thanks
I tried to use Core RP Library instead of UnityCG and some of standard Lib, to study.
-
I believe BoxProjectedCubemapDirection is not yet …or maybe somewhere with another name?
-
OptimizeProjectionMatrix
Other than the UnityCG.cginc, I think
3. TransformHClipToNDC in core Lib will be helpful.
- V_SmithJointGGXAniso with partLambdaV doesn’t need TdotV and BdotV for there argument.
@phil_lira I would argue you seriously underestimate the scope of the problems camera stacking solves. It’s going to be a nightmare with out that.
I found I forgot the link to the shader code…
The code is litChk.shader in this blog post.
techblog.sega.jp/entry/2019/04/25/100000
Sorry the blog is in Japanese but the code itself is no jp.