A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Graphics Experimental Previews' started by Tim-C, May 9, 2017.
But feedback is still necessary.
(It's still pretty experimental though...)
Now, after finishing migration spr repository to graphics repository, i hope unity graphics team finally had time to implement some critical srp features:
1 - RenderWithShader analogue
2 - multipass shaders
3 - ability to replace shadowcaster shader, and shadow buffer format(i.e. for VSM)
4 - proper Fallback. In standard rendering i can just put utility passes in the last shader in Fallbacks chain(i.e. old shaders had "LightMode" = "Vertex", "LightMode" = "ShadowCaster", "LightMode"="Meta" in last Fallback). In SRP this dos'nt work
And will be great if you setup CameraType.Reflection for camera.RenderToCubemap
Looks like thread is dead.
I’ve been telling my users to stick with standard pipeline for the time being. SRP has potential but still a lot of wrinkles to work through.
Yes please. Probably they didn't because it wasn't efficient?... I never felt good about feeding strings into it, I hope it didn't literally perform string comparisons for every shader.
Additional point to that: it always makes me nervous to use Enable/DisableShaderKeyword in rendering code (e.g. enable->render pass->disable->render other pass). Is it fast? Should I avoid it? Can we get precomputed keyword hashes instead of strings maybe?
If you blur the VSM, it is actually a good idea to render to standard depth first to save bandwidth. Convert to VSM during first blur pass.
Also shadowcaster shader can be replaced, it's just your shader needs to have a pass named "ShadowCaster".
Is there any explanation for SRP batcher not being compatible with built-in lightmap variables? :|
Did anyone tried URP on Android? Open gl es 3.1 or vulkan? If yes then how's the performance compared to built in render pipeline? Thank you
I want to do RSM, so i need mini g-buffer instead of simple depth map.
Problem is that EVERY shader need to have that specific pass. SRP can't do proper fallback to certain pass, like in old days shaders.
Unity already feed some per material properties to "overrideMaterial", like light/reflection probes and lightmaps. All they need to do is feed other material properties to this "overrideMaterial"
Further investigation: https://twitter.com/guycalledfrank/status/1261917956021407755
It doesn't work with unity_LightmapST in UnityPerDraw, but does if you also add unity_DynamicLightmapST
EDIT: actually it turns out I missed the "blocks" idea: https://blogs.unity3d.com/2019/02/28/srp-batcher-speed-up-your-rendering/
I guess then your only way is to draw renderers with overrideMaterial and use layers or renderQueue to split the drawing into multiple passes with different shader variation (opaque, alphatest, etc). Very cumbersome, yes.
Is there a way to know if a particular shadow cascade covers any objects? CullingResults.GetShadowCasterBounds gives it for the whole light (full shadow distance), but then after I set split data/matrices and call DrawShadows(), it may not overlap any objects and don't do anything... which is OK unless you expect to prepare/process the texture. In my case I convert depth to VSM, so clear & conversion happens even if nothing was drawn.
Interesting, how many people are actually make their own render pipe?
New SRP is released but not for 19.3 only for 2020.2.
Will 19.3 get new SRP later today?
Just had to rewrite my shadow rendering from using DrawShadows to regular DrawRenderers, because I didn't want to cull/use visible lights (mine are static & worldspace) and it worked great. Now I'm wondering why would anyone use DrawShadows anyway? Probably because it checks for "cast shadows" on renderers (not a problem in my case, just using rendering layers instead)?
Is there a changelog anywhere?
Is there any point in cullParams.cullingPlaneCount option? Attempting to set it to anything other than 6 results in "Assertion failed on expression: 'params.cullingPlaneCount == kPlaneFrustumNum'" spamming. Wanted to cull without using 2 planes I didn't need, and it worked, (or looked like so) but got super slow due to infinite error spamming
I've searched. This could be https://github.com/Unity-Technologi...render-pipelines.high-definition/CHANGELOG.md
No it still doesn't work after ~3 years. The C# code says you can use up to 10 culling planes, but the C++ code has it set expecting 6. I'd suggest reporting it as a bug so more people are asking for it to work.
SRP api is abandoned?
Yeah, really curious about how the SRP api is going to evolve, if at all. There are still tons of stuff that are just impossible to do with the SRP api, like overriding stencil values on a per-material basis or making a custom, per-renderer light assignment, or vanilla-unity forward multipass for lights. I really doubt that the majority of the black-boxed C++ rendering stuff can even be done in C#.
There are currently two stencil bits exposed to us.
Which bits are used for what
Still a lot of work making it useful. This will most likely change with the Shader API update for both SRPs
There are big changes coming, to find out more read this post by the devs
Sorry, my mistake, I meant overriding the stencil values on a per-renderer basis. Builtin Unity did this for stuff like masking out lightmapped surfaces and providing limited layer mask culling to deferred lighting.
Please change the "Utilities" namespace in Unity.RenderPipeline.Core.Runtime.dll. Put it somewhere where it doesn't break every single one of our projects, since we already have an Utilities class in our base Framework. It is currently impossible for us to event try to use the scriptable render pipeline in any project.
I totally agree with this, but I should also recommend changing your Utilities class to something like <CompanyName>Utils to avoid these sorts of collisions.
As a side note, I really hate how generic their naming schemes are getting due to difficulties google searching answers. A good example is Shuriken vs the VFX graph. When I search for particle stuff, I can filter it with Shuriken when I'm having troubles. When I search for Visual Effect Graph, I get all sorts of "How to make Beautiful Visual Effects in your unity game!" type blog posts that aren't related to the VFX graph.
Being fair - as much as Unity should *really* not use such a common word as a namespace it kinda cuts both ways. My driving instructor used to say that it takes 2 bad drivers to have a collision. Maybe the same thing applies to namespaces...
Our Utilities class is in our own namespace. The collision occurs even if I write "using Utilities = Our.Namespace.Utilities". The only way I could prevent the issue would be to pollute my code by typing the complete namespace at every instance where I use the Utilities class, just because Unity thinks it is a good idea to use such a common name as a namespace in <global>.
I didn't realise they had put it in <global> Yeah that's pretty dumb.
On the plus side it will trip them up frequently enough that someone is going to stop getting invited to the office parties...
I believe you can render the mini g-buffer in a shadow pass. I mean all they want is a pass tagged "ShadowCaster" right? I implement the point light shadowmap by outputing world space distance to the color buffer. I set color buffer as RHalf with 16bits of depth. and it works (didn't really utilize depth at all).
I also want the ability to customize per object data. It is really annoying when you can do nothing to stuffs like motion vector, lightmap, etc. Even HDRP has the problem. Camera-related rendering actually causes problem to motion blur when an object's transform is reset to the origin of the world.