Feedback Wanted: Scriptable Render Pipelines

@SebLagarde Are there any plans on built-in support for virtual texturing?

 

Hey guys, have you tested the performance of the lightweight renderer vs the current one(w/forward rendering) on mobile?
Like through a bunnymark or similar? Do you guys even do benchmark testing?

Thanks!

 

https://forum.unity.com/threads/lightweight-pipeline-performance-expectations.515382/

 

New SRP build is out: https://github.com/Unity-Technologies/ScriptableRenderPipeline/releases/tag/Unity-2018.1.0b6

 

Patience is a virtue.. Working nicely with b7 thanks.

 

Edit - Just realized B6 is out with a compatible release, will try in the new version and report back.
Edit 2 - Bugs occur as above in B6, including the crash.
Edit 3 - Copying the depth directly into the camera target (as done in beta release 6) resolves the issue. Crash should probably still be fixed though.

Just some general bug reporting - Not sure if this is the best place. If there is a better place that will reach you guys immediately let me know. This is using Unity 2018.1.0b2 and the respective tag/version in your GitHub repo.

I'm having trouble with scene view wireframe, selection outline and grid behavior.
I'm setting the filled depth buffer (24 bit, depth format, created explicitly as non-temporary renderTexture) at the end of the render loop, similar to your HD pipeline.

If there is no depth buffer set, and I then try to select something with the selection outline enabled the engine crashes.

(Direct3D11 / Vulkan) If the depth buffer is set, the grid appears instead in the top panel (tabs, play, pause, next frame buttons etc.), until I select something, then the grid and wireframe outline appear in the correct positions.

(Direct3D12) If the depth buffer is set, the grid and wireframe outline appears very far below the expected position. The selection outline appears in the correct position.

Pic :


I realize, given the nature of SRP, that there are many places I could have gone wrong, so this could very easily be a fault on my end, though the crash at least should be addressed.

 

@Tim-C do we have any news regarding custom code injection in LWRP? I see that there's a hardcoded PostProsessing pass "After Opaque" and "After Transparent", but it's pointing to the built-in PostProcessing stack.
Do you have any info on that?

Right now I'm starting to think about IL code injection into LWRP dll.

 

Don't understand - why not just copy and modify LWRP source code with own shaders?

 

I can do it for my own projects, it's a wonderful solution. I'm absolutely fan of this new system and will use it extensively in future projects.

But not quite so for the assetstore packages. I can't really make a post processing "injection" instead of the standard one as it's hardcoded right now. So users who use the built-in LWRP version (for apparent reasons) can't really benefit from alternative solutions.
Also think of the endless assetstore packages like UI blur, fast glass refractions, custom fast shadows (based on projection instead of shadowmapping for example) - it's not really clear how to make it work with LWRP

I have posted in this thread regarding this a few pages ago, and it was very nice of Tim to reply to all of my questions. There was an ongoing internal talk between Unity Tech guys regarding hook points, so I have decided to check how things are going.
This is that answer I was referring to https://forum.unity.com/threads/fee...e-render-pipelines.470095/page-5#post-3369158
Cheers

 

That's the thing though, once you start pulling SRP to general purpose you lose the benefits of it and may as well use builtin. SRP comes with shader graph, which is going to be what most people (our little dev shop included) will ever need. Asset store sales will suffer in the near term, yes. And in my view, an acceptable tradeoff because I like performance.

Perhaps the key here is educating people how to modify SRP correctly, and start selling pipelines, with instructions on how to integrate into other pipelines.

Isn't that middleware 101 historically?

 

Yes, this is exactly what I am looking into right now.

But my question was aimed at specific "inner talk" about hook points. So I'm not suggesting anything, I'm just interested

 

What kind of inner hooks would you be looking for? Per object? I assume you'd want something similar to what the grab pass is capable of, right? Like a command buffer you could attach to a renderer rather than a camera or light?

That would be interesting.

 

Hi, really great to see the SRP finally working on my PC, thanks for that! It might be ask too much, but maybe somebody can push me in the right direction, I'm trying to get DrawProceduralIndirect working with the HD Pipeline. So far, I can render an object, but it is not shaded, just unlit with DrawProceduralIndirect ! I put my code in the RenderOpaqueRenderList method in the HDRenderPipeline.cs. Any advice how to proceed? Do I need to add it in an extra lighting function?

Code (CSharp):

1.  
2. //... this is in an external start function
3.       vertsBuffer = new ComputeBuffer(testMeshObj.vertexCount, sizeof(float)*3);
4.         vertsBuffer.SetData(testMeshObj.vertices);
5.  
6.         normalsBuffer = new ComputeBuffer(testMeshObj.normals.Length, sizeof(float) * 3);
7.         normalsBuffer.SetData(testMeshObj.normals);
8.  
9.         trisBuffer = new ComputeBuffer(testMeshObj.triangles.Length, sizeof(int));
10.         trisBuffer.SetData(testMeshObj.triangles);
11.  
12.         trisArgs = new ComputeBuffer(4, sizeof(int), ComputeBufferType.IndirectArguments);
13.         trisArgs.SetData(new int[]{ testMeshObj.triangles.Length, 1, 0, 0});

Code (CSharp):

1.  
2. //...this happens at the end of RenderOpaqueRenderList
3.               bt.mpb.SetBuffer("vertsBuffer", bt.vertsBuffer);
4.                 bt.mpb.SetBuffer("normalsBuffer", bt.normalsBuffer);
5.                 bt.mpb.SetBuffer("trisBuffer", bt.trisBuffer);
6.                 cmd.DrawProceduralIndirect(bt.defaultMatrix, bt.proMatFarGlobal, bt.pass, MeshTopology.Triangles, bt.trisArgs, 0, bt.mpb);

Code (CSharp):

1. //in the VertMesh.hlsl
2. StructuredBuffer<float3> vertsBuffer;
3. StructuredBuffer<float3> normalsBuffer;
4. StructuredBuffer<int> trisBuffer;
5.  
6. VaryingsMeshType VertMesh(AttributesMesh input)
7. {
8. ....
9.         uint index = trisBuffer[input.id];
10.         positionWS = TransformObjectToWorld(vertsBuffer[index]);
11.         normalWS = TransformObjectToWorldNormal(normalsBuffer[index]);
12.     #ifdef ATTRIBUTES_NEED_TANGENT
13.         tangentWS = float4(cross(float3(0, 1, 0), normalWS), tangentWS.w);
14.     #endif

 

@Tim-C
I have two points on this -
It's either something like current camera command buffers (something like you have described), assembly reload hooks or inheritance/composition/ordered interface implementation
Or just scrap the whole idea of hook points altogether so there's absolutely no way of dealing with it using built-in SRP pipelines, just like @hippocoder said.

First option will enable assetstore publishers to create more custom content for built-in pipelines
Second option will probably reduce internal complexity and fear of breaking assetstore stuff (which is sertanly a good thing)

 

Noticed another case when upper body IK should be automatically disabled - when character moves in the direction more than 90 degrees relative to camera view ray. Try to hold down 'S' key in 3rd person view with IK enabled - character will run towards the camera alternating between looking left and right which looks weird.

 

@Kumo-Kairo - agreed, hook points seem very limited. If you're doing anything meaningful you will need a bunch of data from within the pipeline, just having the render-context and render-targets is very limited. But then providing culling data, lighting data, shadow data etc. etc. etc. will be difficult to make work, and would change within every pipeline.

Instead, each pipeline should be uniquely modular, and that would be up to the author of the pipeline to add hook points for their users, as well as document how to use them (ie. interpret the setup lighting/shadow data in shader etc.). You could do this for each of you're authored pipelines, it would set a strong example for other developers, but enforcing it on other pipelines seems like a surefire way to destroy the flexibility of what you've built.

I would suggest instead documenting the hell out of this thing and encouraging asset store creators to do the same for there pipelines. It would also be nice to have optional code in packages that are only used when another requisite package is included. This would allow asset creators to build code specifically for each of the pipelines they plan to support. Though that would then require some sort of versioning and automatic code updating built into the packages so you don't have a mess of incompatible packages of different versions.

Don't be discouraged though, it's well worth it. What you've built, even in its current, somewhat messy form, is incredibly awesome. Speaking of -

Trying to get CoreUtils.DrawFullScreen() to work. I'm using the corresponding shader functions :

GetFullScreenTriangleVertexPosition(vertexID)

To generate the clip space positions and texCoords, like you guys are in you're deferred lighting pixel shader (HD pipeline). This only serves to confuse me more. The function itself draws a single procedural triangle without any indices, though the shader method seems like it should take a quad (And it works perfectly when blitting, which uses a quad), and I'm not quite sure how a mesh can be drawn without indices..?

I can't blit as I'm using unbound multisampled inputs & targets and blitting forces them to resolve (possibly a bug? possibly intended behavior?). I could just draw a quad.. but I want that 8% percent performance gain so I can waste it away on something else completely trivial...

Any ideas?
Edit : Nevermind - got it

 

Scriptable Render Pipeline doesn't seem to work in Unity 2018.1.0b8 if you import either the Lightweight or HD pipelines into a blank project using the Package Manager I see this

Code (CSharp):

1. C:/ProgramData/Unity/cache/packages/packages.unity.com/com.unity.render-pipelines.core@0.1.28/CoreRP/Shadow/ShadowUtilities.cs(250,51): error CS0227: Unsafe code requires the `unsafe' command line option to be specified

And any custom shaders referencing pipeline files cannot open those files. I also cannot create new pipeline asset files and existing asset files are blank and unassignable. Everything seems to work in beta 7.

 

Those having problems with unsafe errors for beta 8 should create a text file: smcs.rsp (ensure it is that and not smcs.rsp.txt) containing:

Code (CSharp):

1. -unsafe

And place in root Assets folder then reimport.

 

Thanks, that seems to fix everything.

 

Alternatively you can check the "Allow 'unsafe' Code" checkbox under /PlayerSettings/[platform]/Other Settings. Which appears to do the same thing.

Edit: Wait nope that doesn't actually work I just got a false positive when I tried it.

 

I found that beta 8, the latest HD SRP 0.1.32 from the package manager, checking Allow ‘Unsafe’ and deleting the library folder before reopening the project all worked.

 

Really not necessary.

 

I was playing with SSS and noticed two things:
1. There is no sign of backscattering, at least I couldn't find it. I guess it is not implemented? Notice the hand transmits red light, but the reflection is pure white:


2. SSS blurs or desaturates textures quite a bit. Is it supposed to work this way?

 

Looks almost like its doing a bit of bloom on that area :S

 

@SebLagarde ,
>Sorry can't tell without more details (Settings, light intensity etc..)
Surface type: Opaque
Material Type: SSS
Enable transmission: true
base color, normal, mask maps present (except detail channel). Normals don't have much details though.
Diffusion profile: skin
Thickness: 0.75
Other settings at defaults.
White spot light, 60lm, about 10cm from the hand.


I have figured it out, increased light intensity to 900lm, and thickness to 1 to decrease transmission.

Some red noisy backscattering finally visible:


Transmitted light is more intense:



Made a quick real life comparison with a 900lm flashlight:

red backscattering is more intense and wide, not sure how to replicate this.


transmission is less intense. Shader probably needs Thickness max limit to be increased to 2 or 3 to properly model lower transmission in real life.

 

@SebLagarde ACES Tonemapping + eye adaptation on defaults, 1:1 model scale. I was trying to say that for default skin profile transmission is exaggerated relative to SSS in the direction opposite to light normal (the undersampled red ring, or backscattering - this term is often used in scientific articles). Increasing light intensity to simulate a flashlight with a reflector doesn't change this.

Regarding the decision to to match spot light to a point light - it would probably be easy enough to add a dropdown with options like "full sphere intensity" (the way it is now) and "spot intensity" to avoid confusion and to assist users when they are trying to match intensity to a real world spot light. LED manufacturers probably specify intensity for a specific solid angle, not a full sphere, and then it gets reduced by the reflector, so calculations get messy. With that dropdown users can just select "spot intensity" and specify the value from light datasheet. Then it can be recalculated to the value used currently ("full sphere intensity") before it reaches the shader. Just a suggestion

 

Where we can find it ?

 

Hi, when trying to build the Nightmares scene in the LightweightAndShaderGraph project for Windows x86, I'm getting the following error:

C:/ProgramData/Unity/cache/packages/staging-packages.unity.com/com.unity.render-pipelines.lightweight@0.1.21/Data/LightweightPipelineAsset.cs(2,19): error CS0234: The type or namespace name `ProjectWindowCallback' does not exist in the namespace `UnityEditor'. Are you missing an assembly reference?

Does anyone know what reference needs to be set?

 

In real life our hands also have bones, which reduce the transmission a lot, so it's not exactly a fair comparison.

 

Thanks! I'm going to update the package now.

 

@Tim-C: Thank you very much for this detailed post.

My asset currently uses the GL class to draw some lines after rendering finished (in OnPostRender() as suggested by the Manual). I see that there are events called before rendering starts which is already great, but is there a way (without manipulating the default SRPs) to use GL calls to draw something after rendering has finished? Is the GL class still supported in the future or is it going to be deprecated?

 

Hey guys! So far having a blast with HD srp on my current project. One thing that I noticed was using post processing with vr capture reorients the cubemaps. Turn it off, perfect cubemaps and equirectangular images? I updated to the latest HD pipeline and Post processing v2.0.1-beta. Thank you!

 

Will 2018.1 have different lighting and rendering system ?

 

If someone does not know where to find it: you need to have the SRPHD version 0.1.33 installed with Postprocesing 0.2.0 and then this checkbox is in the HDRenderPipelineAsset edition.
Below is an example of the json manifest file that works with the beta 9 version

{

"registry": "https://staging-packages.unity.com",
"dependencies": {
"com.unity.render-pipelines.high-definition": "0.1.33",
"com.unity.package-manager-ui": "1.8.1",
"com.unity.postprocessing": "0.2.0"
}
}

 

From looking at the shaders in the github, it looks like the actual coding of shaders isnt changing too much (as in some syntax changes, but nothing major like all commands changing / types changing etc).

I am super happy to see this as up till now I thought all the practise in writing shaders I have done would count for nothing! Actually it looks more in line with standard HLSL which is a good thing IMO!

EDIT: such as this: https://github.com/Unity-Technologi...line/LWRP/Shaders/LightweightCopyDepth.shader

 

1) What is the criteria used for splitting some draw commands in ScriptableRenderContext and some other in CommandBuffer?

2) Is there any way I can copy a texture into RAM and not VRAM?

3) A bit off-topic, but I am using RenderDoc to better visualize the results. Is there any way of filtering the draw commands to Camera.Render? I am wasting lots of time searching for that node in every capture.

Thanks for the great work.

 

I'm having some problems understanding how to use the pipeline assets.

Using the HD Render Pipeline, where can I write a custom lighting model? Earlier, I could just write a custom deferred script and drag it into the custom deferred shading slot in graphics settings.

Now, when I add a custom deferred shader in the HD Render Pipeline Resources asset, I don't see any changes - not even when I leave the field empty. I only see changes when I leave the Compute Shader fields empty. What am I missing?

 

Hi,

Is there a chance to repair Lit shader? In beta 9 and SRP HD 0.1.33, when we insert the texture into the Detail Map by setting Detail AlbedoScale to 0, we get a disco?
In previous version (0.1.27) Detail albedo scale 0 was neutral to material.




BTW, the new SSS is awesome ! If this continues, Unity will be the best realtime SSS renderer.

 

@Tim-C
Thanks for making things a lot more clear about the future of SRP. And yes please don't think about compatibility, think of usability, performance, flexibility and extendability first, the rest come after. At least we all know where the future of rendering in Unity is heading and this is all good for us devs who invest our next projects into Unity, helps us make better decisions.
Lastly, don't neglect other important parts of Unity, the new terr*in (ehem * cough *)... Keep the transparency and don't leave 4years promises threads in Limbo, it is not healthy for both parties.
I think if it wasn't for SRP and all this modularity and extendability of the engine, I would have long gone look elsewhere.
Keep the nice work, I love how SRP is shaping up.
Regards,

 

I am using unity for almost 7 years and following unity developers everyday on forums. @Tim-C took part of development of all these feautures somehow. Some of them: UI, Image Effects, Shader Graph, SRP, and maybe many more we do not see in background. I really want to thank you for all these great features you present us And now new challenge: why not New Terrain system?