Feedback Wanted: Lightweight Render Pipeline

It's here: https://github.com/Unity-Technologi...ity.render-pipelines.lightweight/CHANGELOG.md

 

Visually, it allows you to do things like planar reflection via some coding:

https://github.com/UnityTechnologies/LWRPScriptableRenderPass_ExampleLibrary

Programmatically, it allows you to do extra processing before or after rendering of a scene, the goal is to make use of current render result to do some tricks like above, so it's like post processing, but not necessarily the whole screen.

AFAIK this entry refers to "adding a new API" that's compatible with LWRP 5.x (Unity 2019.x) releases. Not the ability to do extra rendering, which was already possible using an older API.

 

I said it in another thread I might as well say it here:

- Quick note: don't use GitHub release that wasn't released officially via Package Manager unless you know the package like the back of your hand.

- Reason: there are times they haven't passed the QA test, meaning, only consider the Package Manager version to be final.

 

Thanks bitinn

By the way, with this latest version, with unity cloud build, I receive this error for LINUX (windows and mac compiles fine):

Code (CSharp):

1. [Unity] -----CompilerOutput:-stdout--exitcode: 1--compilationhadfailure: True--outfile: Temp/Unity.RenderPipelines.Lightweight.Runtime.dll
2. 22: [Unity] Library/PackageCache/com.unity.render-pipelines.lightweight@4.7.0-preview/Runtime/DefaultRendererSetup.cs(2,42): error CS0234: The type or namespace name 'LWRP' does not exist in the namespace 'UnityEngine.Experimental.Rendering' (are you missing an assembly reference?)
3. 23: [Unity] Library/PackageCache/com.unity.render-pipelines.lightweight@4.7.0-preview/Runtime/DefaultRendererSetup.cs(41,22): error CS0246: The type or namespace name 'IBeforeRender' could not be found (are you missing a using directive or an assembly reference?)

Maybe I just need to reimport the project. I will and edit this if anything changes.

 

Will 4.7.0 fix postprocessing in VR?

 

Rendering from a second camera in 2018.3.1 with 4.6.0 preview to a rendering texture does not work in LWRP and VR mode. The second you turn on the VR camera the texture stops updating or turns black. It works as normal in a non-VR mode so this is a game breaker if you want to have a scoped rifle for instance in VR.
*EDIT*
2019.1 seems to solve the above but creates new issues instead.

 

It would be case 1112145, Unless Alpha's not meant to be a back buffer image in Premul.

 

Hi
Sorry for my ignorance and my little English but I am interested in using it for my own VR projects, for it, Do you know if it would be VR ready soon? Thanks for your time

 

4.7.0-preview seems to reproduce a issue: https://issuetracker.unity3d.com/is...-pipeline-gives-corrupted-image-in-ios-device

EDIT:
In 4.7.0, a "Depth only" clear flag doesn't work. It results clearing all previous rendered image. So I changed a flag to "Don't clear", a glitched image was shown on iOS. (works correctly on macOS)

 

Wow, It's a big change.

Can I see any ScriptableRenderPass injection example? (ex: Render a scene in perspective -> Render some models in orthographic as overlay -> Render uGUI)

 

And I see what you mean. Works for PBR... Not for unlit.... Bizarrely enough.

 

Can you not just create a new material and assign it to the cube?

 

Is there no support for D3D for the SRP Batcher, or am I misunderstanding? I have turned it on in our branch of 4.x and it appeared to be doing *something*, though I may be imagining things.

In regards to the performance testing, I too have been seeing higher bandwidth costs than expected with LWRP. We won't be moving to 2019.x for this initial release, so 5.x is not an option for us. I'm not requesting a back port to 4.x, but do you think a back port is possible? I can merge code myself in our local branch but I know there may be some core engine dependencies.

Speaking of the Shader Variants in VR, this was so crippling to our iteration that we actually stripped Standard Shaders all together and have instead opted to only use ShaderGraphs. If there is anything else you can speak to, or would like some additional insight as to what we are seeing I'm more than happy to help.

 

So you have tried the mini profiler and it didn't change anything?

https://forum.unity.com/threads/srp-batcher-in-2018-2.527397/#post-4099828

I can see SRP Batcher helped to reduce draw call on my end, but I am using Metal API (not enabled by default in 2018.3, but can be enabled at runtime apparently)

 

Results were inconclusive using the Stats window and better diagnostics tools like RenderDoc and NSight weren't revealing anything further, hence my inquiry.

Our Render loop and Material definitions are quite well optimized as it is, so I'm not ruling out that even if it does work with D3D, it may have little to no effect in our case.

On a side note, I see on a re-read that @phil_lira mentioned it doesn't work with VR yet, so it actually wouldn't matter in our end use-case.

 

If you've used any other material/shader editor before you should be fine. It's basically the same for all of them in any engine you use, path/raytracers included (except these have some other advanced features built into their master nodes but they share a lot)

If you're completely new don't worry. there's a lot of tutorials out there that you can use to learn from (keep in mind it doesn't have to be Shader Graph specific). I would suggest starting off with recreating a basic version of the standard shader. Basically just adding texture inputs and tiling.

 

I don't actually use ShaderGraph, but the Content Creators on our team do. They are making cool things with it, but I have had to make modifications and additions, as well as custom Master Nodes to really be able to unlock them.

It is as intuitive as a node editor can be, but it is somewhat limited in its current state. It mostly serves as a surface abstraction, rather than a full-blown Shader Editor at this point.

Still, very good, because it puts the power in the Artists hands and unblocks them from waiting on someone like me who otherwise has to hand write everything.

There are performance concessions that you'll make, too, as naive implementation on top of a node abstraction will never be as efficient as hand-optimized HLSL.

 

C'est la vie. The first step is always making it work/look right. Making it fast comes after. And if it comes to needing advanced low level optimizations, then that's where you seek out help from the community and use it as a learning opportunity.

"Premature optimization is the root of all evil." - Knuth

 

I can’t be absolutely sure, but I recall ‘receive shadows’ on the LWRP Lit shader in transparent mode used to function as you’d expect. In the 5.2 package the surface just renders background shadows over the top and doesn’t receive shadows- is this a regression or just future behaviour?

 

Is VFX supported?? or its just for HDRP exclusive only?

 

As per this Doc: https://docs.google.com/spreadsheets/d/1nlS8m1OXStUK4A6D7LTOyHr6aAxIaA2r3uaNf9FZRTI/edit?usp=sharing

2019.1 is their current target.

 

As noted by others, this is a really big change. I feel this is the kind of information that really should have been in the changelog, so users don't have to trawl through long forum threads full of unrelated issues to figure out why everything suddenly broke. I personally found it funny (in a bad way) how there's specific mention in the log about fixing a bug for Depth Only cameras in 4.6.0-preview only for Depth Only to be deprecated in 4.8.0-preview without any note in the log.

In any case, is it safe to say users that currently make use of stacking should not update past 4.6.0-preview?

edit:
Am I in a timeloop or does the changelog have the year mixed up too?

 

Yeah, I saw that after I did another skim of this thread. It's not *that* critical as we are almost entirely GPU bound, but I suppose more optimized state changes as a result of the new batcher could help with that as well, but we're mostly SM+L1$ or VRAM bound (as per my last NSight profile) which are things that content will hopefully be able to address.

I did a quick search and it doesn't look like the GraphicsFormat API is usable when creating RenderTextures through a CommandBuffer or RenderTextureDescriptor in 18.3. I may have missed it though.

I've noticed this for sure. I was curious to see whether or not leveraging Compute to do the resolve may help us here. Understanding that UAVs have their own implications and that this wouldn't work for mainline LWRP because of Mobile's shaky Compute support, but I'll do a test in our branch.

Yeah, it was an atrocious increase in build times for sure. Glad to know it's acknowledged and being looked into. It almost seemed as if it were compounded by how many scenes are actively being built, as if the Shader compilation was executing for every scene. We've moved entirely to ShaderGraph Shaders as they only generate systemically-driven variants and our build times are good again.

I'll shoot you a message about the backports, many thanks!

 

Does anybody knows how to make real time shadows on lit terrain not as black as on other objects, this only issue is bounding me from using LWRP

 

Hi Phil,

Yes that's it.

Cheers

 

Thanks for the timely reply!

My apologies, as 19.1 is still in alpha, I haven't been using that so I completely missed the changelog for that version.

Right, I did read that from the Google spreadsheet/doc that was linked earlier in the thread, and that makes sense. However my observation thus far has been that it worked like it did in the built-in pipeline, but my usecase is probably a lot simpler than for most other people. I used it simply for displaying particle effects using a second camera, and overlaying that on top of the main camera via the depth value setting.

Ah, my apologies, I referred to the bug as a bit of a jab at how the bug was listed in the changelog, specifically mentioning the Depth Only flag, yet there was nothing in the log about how the functionality was completely changed in subsequent versions. I have not experienced the bug in question, fortunately.

I look forward to the alternative solution and documentation! I greatly respect the work that you guys do, and am always for a performance gain, was just frustrated at the lack of information about such a big breaking change. Will this alternative be exclusive to 19.1, or will that be back ported to 18.x? In any case, I suppose I will be remaining on 4.6.0-preview until that's ready!

 

thank you Phil, one more question seems like camera.layerculldistances doesn't work in rendering pipeline mode, is it any alternative to it?

 

I apologize, my bad. It works but somehow amount of triangles become much bigger (in "game" mode stats) after updating to pipeline. I'll check, its probably my internal bug

 

Any ETA for light cookies?

 

Hi phil_lira
Sorry for my ignorance but I am working with VR projects and interested in using LWRP to optimize my 3D PC games for VR, for it, Do you think if I would use LWRP could optimize it for VR?
Thanks for your time
Alejandro

 

Hi phil_lira
Ok, Thanks for the info.
Another question, please . Since I am new in this topic, Could I use the Book of the Death Environment in a LWRP via template? If it is like that , Could you teach me to do it? Thanks

 

You would need to move all of the Materials (which are HDRP Materials) to use LWRP Shaders. They will likely show the magenta error colour otherwise.