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://discussions.unity.com/t/664083 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?
3 Likes
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
1 Like
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?
//... this is in an external start function
vertsBuffer = new ComputeBuffer(testMeshObj.vertexCount, sizeof(float)*3);
vertsBuffer.SetData(testMeshObj.vertices);
normalsBuffer = new ComputeBuffer(testMeshObj.normals.Length, sizeof(float) * 3);
normalsBuffer.SetData(testMeshObj.normals);
trisBuffer = new ComputeBuffer(testMeshObj.triangles.Length, sizeof(int));
trisBuffer.SetData(testMeshObj.triangles);
trisArgs = new ComputeBuffer(4, sizeof(int), ComputeBufferType.IndirectArguments);
trisArgs.SetData(new int[]{ testMeshObj.triangles.Length, 1, 0, 0});
//...this happens at the end of RenderOpaqueRenderList
bt.mpb.SetBuffer("vertsBuffer", bt.vertsBuffer);
bt.mpb.SetBuffer("normalsBuffer", bt.normalsBuffer);
bt.mpb.SetBuffer("trisBuffer", bt.trisBuffer);
cmd.DrawProceduralIndirect(bt.defaultMatrix, bt.proMatFarGlobal, bt.pass, MeshTopology.Triangles, bt.trisArgs, 0, bt.mpb);
//in the VertMesh.hlsl
StructuredBuffer<float3> vertsBuffer;
StructuredBuffer<float3> normalsBuffer;
StructuredBuffer<int> trisBuffer;
VaryingsMeshType VertMesh(AttributesMesh input)
{
....
uint index = trisBuffer[input.id];
positionWS = TransformObjectToWorld(vertsBuffer[index]);
normalWS = TransformObjectToWorldNormal(normalsBuffer[index]);
#ifdef ATTRIBUTES_NEED_TANGENT
tangentWS = float4(cross(float3(0, 1, 0), normalWS), tangentWS.w);
#endif
Note:
Created a thread specifically for Lightweight pipeline here:
2 Likes
The hard part here is that it’s really nasty whichever way you go about it. Each pipeline is different so has very different data structures and pipeline execution (there was even divergence in the old unity forward vs deferred command buffer hook points that caused issues).
There could be some simple hook points added that apply to the pipelines we have:
*void AfterOpaque(ScriptabaleRenderContext ctx, RenderTargetIdentifier color, RenderTargetIdentifier depth)
*void BeforeTransparent(ScriptabaleRenderContext ctx, RenderTargetIdentifier color, RenderTargetIdentifier depth)
*void AfterTransparent(ScriptabaleRenderContext ctx, RenderTargetIdentifier color, RenderTargetIdentifier depth)
*void AfterEverything(ScriptabaleRenderContext ctx, RenderTargetIdentifier color, RenderTargetIdentifier depth)
Then we need to talk about how they should be exposed? Generic hook points that you can add callbacks too on assembly reload? Or would you want to inherit from the class and override them (less flexible).
@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 
1 Like
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
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:
-unsafe
And place in root Assets folder then reimport.
1 Like
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.
1 Like
Really not necessary.
Hi. In Beta 8 a scripting change when in requiring all asm defs to define is unsafe was allowed. We didn’t get notified in time and this broke SRP 
If you update SRP via the package manger to the version tagged 1.0.0-beta you should be good to go. As a note: please remove shader graph before doing this (via package manager) as we have changed dependency ordering and if you don’t remove it you may run into issues.
3 Likes
I was playing with SSS and noticed two things:
-
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:
-
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