Feedback Wanted: Scriptable Render Pipelines

Hi.

I'm a student at a university who has been watching this project from the shadows from a while, and now this summer on weekends I think I would like to try building a couple of SRPs for the experience. I have two projects in mind that would greatly benefit from custom pipelines. One of them is a game in which different scenes use different visual styles with different effects, weather, ect. The other is an FPS somewhat similar to Splatoon with a "paint the world" effect (which I got a prototype working in 5.6 using particles and texture arrays and a fake lightmap, though the mechanics are different and I would eventually want to add a full fluid simulation. So if you don't mind, I have quite a few questions on things I have ran into so far.

First, what exactly is the purpose of using a factory system and producing pipeline instances? I couldn't really figure out how that is useful, and some of the Unity pipelines don't seem to bother with it (BasicRenderPipeline just uses static functions, and the mobile deferred pipeline just passes rendering back to the asset). While I really like the idea of splitting run-time data with serialized data, Unity automatically creates and deletes pipeline instances whenever something is changed in the asset from the editor, which means any run-time data registered into the instance from script during Start() would get broken if an artist decided to modify the shadow settings during play mode. And I'm not sold on the idea of generating a new pipeline instance every frame to handle dynamic events. What am I missing here?

Second is just a nitpick, but why is GetCullingParameters in CullResults rather than a method called GetPararmetersFromCamera in CullingParameters?

Third, what exactly are your plans for managing lightmaps? Will we have access to controlling when Enlighten would perform a meta pass after requesting a renderer update? Will we be able to store our own custom texture transform matrices in renderer components that work for multiple lightmaps and other kinds of world-space maps? For example, when I built the FPS prototype, I had to create a baked black directional light and specify a small lightmap resolution to get the entire baked lightmap into a single lightmap atlas, so that I could use the baked lightmap UVs to index my texture array. But in the future I would love to be able to just automatically have Unity pack the baked lightmap uvs to fill a single atlas, and then after painting the particles to the texture array, update global illumination on either the CPU or GPU (not sure which will be easier/more performant) using either Enlighten or my own system, and then draw the scene. Are there any plans to make something like this feasible?

Fourth, regarding discussion of callbacks within the render pipeline, I imagine it would be something like this:
1. I build up a list of CullResults for things that need callbacks. (C#)
2. I call a function in Unity API that takes a list of CullResults and spits out a 2D list of Renderers. (C++)
3. I use this 2D list to send out appropriate messages as I build up my rendering instructions. (C#) Would I use SendMessage for this?
4. I submit my context. (C++)

Would this be an efficient approach compared to how Unity is currently doing things?

Fifth, will we be able to customize CameraEvents to attach command buffers to?

Sixth, will we be able to define our own render queue enumerations instead of simply using "Opaque", "Transparent", ect? More specifically, have an easy way to specify them from Shaders and such?

Seventh, how would the following use case be possible in SRPs (assuming it is possible)?
I have a particular type of enemy whose body is emitting fire. However, I want full control over the style of the fire, so I write a compute shader that takes in the deformed mesh (hopefully from GPU skinning), and outputs mesh data for fire for that frame. I have over 100 of these fire enemies in my scene, but only about 10 of them will be on screen at once, and I only need to update the fire when the enemy is on screen. I want to render the enemy mesh during the opaque pass. Then in the transparent pass I want to run the compute shader on only the visible enemies and then draw indirectly the fire. I then want to use a similar technique for smoke enemies, water enemies, ect. The only way I can imagine doing this would be to use a custom callback that sends out a reference to a command buffer to fill to all the objects after culling objects on a specific render queue (hence why I asked about custom render queue enumerations).

Eighth, I'm noticing in some the examples the use of an AdditionalLightData script. I have a sinking feeling this is going to lead to a lot of artist frustration, as an artist could easily forget to add this script when creating a light. It could also lead to confusion when changing the light component parameters have no effect, because actual data lies within the AdditionalLightData script. For example, maybe I wanted the light intensity to be calculated by a lightbulb type and wattage so that I could simulate a sketchy electrical system. Would it be possible to get a minimal version of a light (and probes and maybe even cameras) that we could inherit from that has the normal MonoBehavior messages (or at least the important ones)? Maybe this minimal class would only contain info for culling (like bounding box and such that would be hidden from the editor)? And then provide some way to print a warning when a user adds the regular Unity light? (This might already be possible. I'm not very good at editor scripting.) Are there alternative solutions far superior to this idea?

Ninth, can we get callbacks for when a pipeline asset gets assigned in the editor to that particular pipeline (as well as a callback for when a pipeline gets removed)?

Tenth, which shader variables does SetupCameraProperties actually set up?

And finally, is it a good idea for me to be trying to build my own SRPs this early? Am I asking too many questions?

I really like where Scriptable Render Pipelines are going. Aside from the things above, everything is really intuitive. It is easy to cull what you want to cull. I have full customization over shadows, light falloffs, styles, abilities to do crazy interactions between multiple lights and cameras, apply filtering to the skybox by drawing it first and then running compute shaders, whose results I can use to apply other shading effects, and all sorts of stuff.

And things for the most part just work. The easiest evidence that anyone can try is Debug.Log the order the cameras get passed in the array. You'll find it is sorted by the cameras' depth values, just as one would expect!

 

Was hoping to play around with this but i'm stuck at the first hurdle and don't seem able to download a fully working version of SRL.

I'm not familiar with github, so I just use their gitHub desktop software to deal with it. Unfortunately this means when cloning it will download the latest version ( master ). I then tried reverting back to the 156fb11 commit, but it told me there were merging conflicts that had to be resolved first and, yeah no idea what to do about that. I'm not even sure if the conflict refers to current local version or reverting to the 156fb11 version.

I then tried downloading the 156fb11 zip and the PostProcessingStack V2. Unfortunately something is messed up and the PPS just spews out errors until i disable the component. Whilst in some scenes ( e.g. LDRenderPipelineVikingVillage ) I have a Missing prefab, but no idea what it was or if its important. So even when I have a 'working version' its unclear as to whether this really is working or if things are broken/missing intentionally.

Can anyone provide clear series of commandlines for doing the github stuff - assuming that the results provide a working version of SRL for a specific Unity version


So with regard to pushing updates and experimental builds of SRL I would say

• The github instructions aren't very useful for someone unaccustomed to github.
• The fact that the master version is generally on a build not available to alpha testers, let alone beta testers is painful.

My suggestion then is that periodically Unity deploy a working version of the project for a specific Unity beta/alpha version that is available to the public. Though I dislike having multiple beta/alpha installs i'd rather that and be able to get in and playing with SRL immediately than the situation currently where I have nothing or spend most of my time trying to get a working version.


As for SRL themselves, its too early for any real comments, but I am somewhat confused with the pipeline asset apparently needing to be assigned by hand to graphics-ScriptableRenderLoopSettings properties.This would appear to be an awful decision, not least because if I hadn't happened to have a read a GUI popup in the GDC2017 demo I would never have known to swap pipeline assets and been very stuck/confused as to why it wasn't working or that i just had a black screen.

Are there any plans to change this?
Why can't it be changed via script at runetime? or if it can shouldn't these SRL test demos be doing so, instead of the tester trying to workout with pipeline asset goes with which demo?

 

Oh wow! I totally was not expecting such a detailed response! This answered a lot of my questions. Embedding custom data right into into the inspectors of lights and cameras sounds amazing! That actually makes things like implementing custom camera events and such safer too.

So how could I write code like this in my shader's subshader block:
Tags { "Queue"="OpaqueMoonlit" }

Where somewhere else in my C# code I define OpaqueMoonlit to be equal to 2115?

In addition, how would I change the dropdown options in the "Render Queue" setting in the material inspector?


Right now, per-object configuration is still a bit lacking, both for the example I gave previously and for light and probe sorting. If I was on low-end mobile (which I usually never am) and wanted to sort lights either by intensity, by distance, or both (taking into account a custom falloff equation), I would not be able to. I feel like either a new variant of command buffers are needed, command buffers need to be attachable to materials (with some way to access per instance data), or both, or some other more intuitive solution.

I'm kinda curious if and if so how surface shaders could be incorporated into SRP? They were nice for the black box render pipelines, and they might be nice for when people start sharing their custom pipelines with each other, but probably not the highest priority.

Anyways, I think I'm going to hold off on building my render pipeline until either some new information on how to do things or a new iteration of the API arrives. In the meantime I think I'm going to work on building the non-SRP aspects of some games that could really take advantage of SRPs.

Thanks again for all the information! It's exciting stuff!

 

Hi @phil_lira @Tim-C I am following this awesome feature since the beginning and I must say that is an incredible and fantastic initiative.
I would like to know if there is any ETA (Unity version, weeks, months ?) for this and if it can be used in a production environment. I am mainly talking about the LD pipe.

Thanks a lot !

 

Tim-C responded earlier in this thread about LD pipe's stability:

So looks like in 2017.1 (july) it will be usable for some, and in 2017.2 (november?) usable for most.

 

Thanks for the answer @scvnathan. Seems that I missed that post.

 

I am also wondering if we can add properties to lights in SRL.

 

Are there also some information about the deferred rendering path ? @scvnathan @phil_lira @Tim-C

 

So, for anyone who needed a video explaining the stuff, i've found this:

Hope it helps understanding the loops better.

 

1) Would it be possible to access the reflection/specular pipeline as well to eg. enhance the current smoothness main reflection that based on a hand full of blended pre rendered cubes?

2) Currently to build a clear coat metallic material, I have to hack the the internal build in reflection shader and exhaust some BDRF channels.

The whole discussion needs creative and eloquent ppl who have the ability to introduce possibilities of the new system. Programmers are not able to do this.

If a game designer or shader artist didn't know what the HDRP can offer, this discussion about HDRP seems to be a academic entertainment for programmers.

Why buying a expensive programmer into my company, if I do not know what the new system can do for me, or what definitely benefit I have from.

 

@Tim-C Nice thanks

 

@Tim-C any new release for the SRP?

 

Recently I've noticed @hippocoder asking a number of Asset Store developers who make rendering-related add-ons for Unity at present, if they are going to support SRP's. This caused two questions to loom large in my mind.

1. Isnt it a bit early for this? Especially for assets that will want to target the HDPipeline for desktop etc given that it was still described as at an early stage of development in May.

2. A lot of the conversation, presentations and documentation to date tends to focus on the idea of people taking one of the C# pipelines Unity are making and sharing, and modifying it for their own needs. Is there much of anything around that focuses on how Asset Store devs can make their stuff work with one of Unitys pipelines that their customers may be using? Users who will likely want to use with more than one render-related asset store item with the pipeline, making the scenario where each asset comes with its own complete, customised pipeline a bit messy (to say the least) if I've understood SRP's right?

Anyway these questions arent supposed to be a criticism of hippocoder, its just once I had thought of them I really wanted to know the answers! And its quite possible that question 2 simply stems from ignorance on my part, and me not having the time or complete technical vocabulary to deduce the answer(s) from the existing conversation & docs.

 

I also ask it in the spirit of wanting to be as helpful to asset store devs as possible, it would be nice if some general advice for them was put out now, and a good guide with them in mind released at the appropriate time.

I'm not an asset store developer myself (yet) but I noted that some of them got a bit burnt out by the number of rendering changes made to unity at various points in the 5.x cycle. So whilst some of them are no doubt interested in what they could achieve with this new degree of rendering control as this pipeline stuff matures, I also sense trepidation and groaning from some and I want to ease their pain! Which at this stage mostly just means getting the right advice in place in terms of the when and a little something about the how. Even if its just a few sentences here in this thread that I can point to when the subject arises. Cheers.

 

I'm not actually asking on behalf of Unity. Blue badges don't work for Unity, we are just proven to be beneficial to the community and Unity alike, and aren't paid or anything. Call us helpful but passionate people that mingle between.

But in my experience you generally want to spread awareness of something long before the something lands, otherwise you, and everyone else will be sat around waiting. Unity isn't going to wait. It'll release what it has as soon as it can do so, unlike the old days when features needed to be held back for a new paid release.

In this case, SRP is a really big deal and totally the future of Unity so we want people really working toward that ASAP not later. It will take asset authors a while to even learn where it fits in with their assets or if it's even useful. As for V2 post stack, that's much more relevant for people doing post FX that needs to play ball or be a little more optimised.

So I spend time informing people of Unity's basic tech direction early as possible, so we don't have to wait ages for some form of improvement, and that these asset authors can also feed back any early problems to Unity staff.

It's just one of the general things I do, to be helpful rather than any agenda.

 

Oh dont get me wrong, I never thought you were doing it on behalf of Unity. I've done similar myself in the past, most obviously when it comes to metal supporting compute shaders in 5.6 which I've gone on about all over the place on the forums.

So I'm all for the spreading of awareness and really what I was getting at is that by you doing so at this stage, I found myself with questions I need answers to in order to join in with such conversations with asset store developers in a way that puts a little more meat on the bones.

 

For the sake of clarity because I do go on a bit, I will explicitly state the two nuggets of info I have been fishing for:

A tiny bit more timescale info that carries on from the planned story in regards experimental->standard of the LD Pipe, but for the HD pipe. I know since it sounds like this is further away for the HD Pipe so I assume that talk of timescales will likely want to be kept looser, but some sense for asset store devs of, eg, whether to plan for the year 2017 or 2018 for desktop HD Pipe being considered the new ready standard that users might start clamouring to have support for in their asset.

Some advice from Unity about exactly how they envisage multiple 3rd party asset store assets fitting into the way the pipeline works, the practicalities of shipping their assets that make use of a particular pipeline, and/or reassurance if there are no obvious major tech issues here.

 

I still want to get around to playing with this SRP, I have a perfect project for it ( recursive portal rendering ) and i'm hoping that SRP will show a reasonable performance gain due to be able to share various data sets between various operations ( e.g. render depthnormalTexture using same culling data ).

However currently I feel that there is so little information about the system, that it appears to be in a state of high flux and out of sync with unity builds that developers can get it just seems like an up hill battle. Every time I look at the source code project I have a bunch of questions ( e.g. why does it appear that SRP requires custom shaders for each type?) that I can't find the answers to, but which I don't want to post in case i'm missing some detail somewhere and want to avoid spamming the thread with a question every few days. I sort of feel I need to actually try and implement my project and post questions that arise directly from it.

What I would like to see is periodic updates to this thread providing absolute links to Unity experiment builds that support a specific SRP branch/tag. Heck I'd even perfer just a single download from Unity that provides the editor and SRP library in a single package so I don't have to try and work out which builds work with which branches etc. Just something to help get developers started instead of wasting their time matching Unity builds to branches etc.

I'd also like to see some updated documentation on where the current state, direction, plans for SRP are outlined. It doesn't have to be well written, just comprehensive in providing important up to date information.

Most importantly I feel its high time such a important feature gets its own sub-forum and not just a few threads dotted about. That way developers who are playing with this tech can post issues, bugs, questions, findings that others can help or learn from. I mean I may not have the time to write my own SRP, but I do have the time to read up a few threads a day about the issues or success other developers are having and learn from the information they posting, thus arming me with great information for when I do have time to play with it.

I don't know, I just feel like perhaps UT could be doing more to make ease of entry to SRP better. Providing more complete demo projects that aren't broken when you try to run them, perhaps a video or twitch live stream explaining the current system in depth etc, anything really.

I realize that can be a large amount of additional effort and work, but currently I feel the only people who truly understand the tech are those UT developers making it and without getting greater input from customers it runs the danger of not providing required features or missing bug reports.

 

SRP definitely needs it's own graphics sub forum if only to draw attention to it because there's a lot of data here that's really specific and should not be lost. I left a note for the staff, don't know what is happening there.

 

Totally agree.

 

Definitely agree with a sub forum, though I don't think it is a big deal until the next iteration of the API. Speaking of which, it's actually super awesome there's still a planned update for 2017.1 given that a while ago I remember it being stated somewhere that Unity had internally already forked 2017.2 and that there would be no new features for 2017.1, as well as the fact that the current SRP GitHub is on 2017.2. That goes to show how much they value our feedback!

This is just speculation on my part, but I'm guessing Unity's main purpose for HDRP right now is a means to test their design and uncover some pitfalls and snares before cleaning out all of the legacy code with a fresh new SRP-friendly system. I wouldn't recommend this to artists right now. At the current state it is more a matter of whether or not graphics programmers are on board with the direction of the framework. Someone from Unity, please correct me if I'm wrong on this.

When looking at the API and the changes that are being made and promised, a lot is still in flux, but big picture things are a little more stable than you might expect. The major hurdle SRP had to overcome was finding a way to make SRPs work in Unity. You have one or more scene editors, a game view, material previews, and possibly some other previews. Unity had to make that all work to provide real-time feedback. Currently they have a pretty good solution to the problem. (I won't say it is perfect yet because I can't figure out how to make Unity not rebuild my instances and reallocate my shadow maps and break all my events in play mode when I just want to adjust the atmospheric density which lives on the asset for serialization benefits and all that actually needs to happen is that I loop through all instances and copy the new value.) The general idea hasn't changed much since its inclusion into public builds. You have an asset which generates instances for all the different windows, and then in those instances you have your rendering loop in which you fill a context with commands to cull data, execute command buffers, and draw renderers, as well as whatever other logic you want to put in there. And the fact that people have mostly been asking about features rather than questioning the design choices either means not enough attention is coming this way or that the design choices are tough to beat (I think it is a little of both).

I actually know the answer to this (to some extent). First off, many SRPs will redefine the shader constants, making the older shaders incompatible. This is actually a good thing, as it means we have more control over what globals are stored in the shaders. I don't have to use Unity's time conventions anymore. I could define a time convention where x is milliseconds, y is seconds, z is minutes, and w is hours. I can now package this in a CBuffer used every frame along with wind settings and other per-frame data and get a little bit of a performance boost. Also, generally a SRP will have custom shaders so that they can take advantage of SRP optimizations, such as tiled lighting.

The SRP 2017.1 beta 5 release works for me, and I don't believe the API has changed at all in any 2017.1 beta since. They switched to 2017.2 only a couple of days after release. Something to note is that in 2017.2, they hid RenderPipeline.cs into the engine. That confused me for a while until I got a chance to test things out myself. I also recommend checking out the Unity Package in the initial post containing the presentation project. No git required, and in my opinion provides an easier code template to start experimenting. A fun little challenge is to try to add lighting to the scene.

Looking forward to the new API!

 

Tested ScriptablePipeline for a few weeks. Here’s what I’ve come up with.

As a general goal, I was trying to create a ScriptablePipeline for low end mobile devices. The biggest requests I have are to help support forward, single pass, and per object point lights on these low end mobile devices.

1. Per object point lights on low end devices, like the IPhone 5, which don’t support compute buffers. The current LightweightPipeline.FillLightIndicies requires compute buffers which means light indices cannot be used on low end mobile devices.
2. Use shader preprocessors per object to turn on/off the calculations for point light code in vertex/fragment shaders. For our shader, running the point light calculations for all objects costs 25% of gpu device utilization. Only 1/2 of our objects are in range of a point light and our tests showed that the gpu device utilization could drop to 1/2 (12%) which is a huge reduction.
3. Static objects with single pass per object point lights. Allowing objects to use both light maps and single pass point lights would help immensely with our performance. Currently, the only way to support point lights on static objects is through multi pass lighting, which is prohibitively expensive for low end mobile devices. In the case that all objects in our scene are in range of 4 point lights, running single pass lighting costs 25% gpu device utilization while multipass lighting costs 45% gpu device utilization. The old unity pipeline appears to assume objects either get light maps or single pass point lights (unity uses vertex lit) but not both. The scriptable render pipeline would be more useful if it was customizable to allow objects to get both light maps and single pass point lights.

The ScriptablePipeline seems like it could be a great feature to help Unity support low end mobile devices and high end pcs. In contrast, my attempt to write a custom renderer using CommandBuffer.DrawMesh/DrawRenderer was time consuming and needed more work to lower cpu usage. However it did show that if scriptable pipeline supported the above features, our expected gpu device utilization for point lights would drop to 12% (IPhone 5, 30 fps). This would enable us to make our Unity games look much better.

 

Is your GDC presentation available in video? couldn't find it in the GDC vault...

 

Is it possible to pause the render loop so I can save battery when the view doesn't change?
Related: https://feedback.unity3d.com/sugges...er-loop-for-lower-power-consumption-on-mobile

 

You should check this out:
https://forum.unity3d.com/threads/b...t-with-immediate-new-frame-upon-input.476263/

 

Thanks, that is exactly what I am looking for.

 

In the older version, it seems that you where doing some light sorting based on intensity. Wasn't that good enough ?

I would like to know if there's a example on how to handle cookie and if it's possible and how to handle image effects ?
Thank a lot !

 

Nice, this is indeed better

Thanks for the precisions.

Thanks again, I didn't know about the PostProcessing customisation, that's awesome !

You are doing awesome work with the Postprocessing and the SRP !

 

Oh I forgot to ask about point light shadows @phil_lira , is it planed in the LightWeight pipeline ?

 

Thanks for your reply, looking forward to Scriptable Pipeline.

Yeah I can see how it would be better for state management if the default behaviour preserved batching, it seems like the cpu cost would increase in general. However light computations can cost more than is saved by batching, helping lower overall gpu utilization. For us, that next level of customization seems necessary, thanks for looking into it.

Sorry, I didn't mean to indicate that this wasn't currently a feature in Scriptable Pipeline. Things like this are actually one of the reasons we want to use ScriptablePipeline over the old Unity pipeline.

 

So, any guidance for asset store devs as per my previous posts?

 

Also, it is possible to give any clues as to when you will next tag a release for a particular unity version? eg will there be a version thats more up to date than the last one (May, 2017.1b5), that is tagged to work on, for example, the initial release version of 2017.1?

 

How bad is this exactly? It's not like Unity doesn't already have things like this. Heck, lately I ran into an issue where an assignment operation (assigning an 8k poly mesh to MeshCollider.sharedMesh) cost me 20 ms. I'm working on writing a native c++ plugin to get around that issue. It's kind of like the Find function. It's a performance killer when used incorrectly, but when used appropriately (like during initialization while generating a procedural world) could save a lot of programming time. Then again, if the possibility of exposing renderers occurs a big performance cost to SRP even if the feature isn't utilized, then it's a bad idea. That's at least my view. You probably know something I don't.

Personally I think it would be really cool to have a DrawRenderersWithCommandBuffer function, in which we could set up CBuffer parameters indirectly from the top 8 (yet to be determined) nearest lights and set up an array of light color, light position/direction, custom light cookie data, and even dispatch a compute shader ahead of time to re-orient some flowers to point towards the light without clipping into the plant-covered character (Sorry, I like to do a lot of weird fantasy stuff).

Here's some made up example with made up API (and probably syntax too because I'm tired):

Code (CSharp):

1. LightSorter = new LightSorter();
2.         LightSorter.sortMode = LightSorterMode.INTENSITY_FALLOFF;
3.         LightSorter.falloffCurve = LightSorter.GetPropertyFromAdditionalLightData<FantasyWorldAdditionalLightDataComponent>("m_FalloffCurve");
4.         LightSortResults = LightSorter.sort(8);
5.         CommandBufferIndirect cmdi = new CommandBufferIndirect();
6.         for (int i = 0; i < 7; ++i)
7.         {
8.             cmdi.SetGlobalVector(LightPositionShaderIDs[i], LightSortResults.GetPropertyFromTransform("position", i));
9.             cmdi.SetGlobalColor(LightColorShaderIDs[i], LightSortResults.GetProperty("color", i));
10.             cmdi.SetGlobalTexture(LightCookieShaderIDs[i], LightSortResults.GetPropertyFromAdditionalLightData<FantasyWorldAdditionalLightDataComponent>("m_LightCookieRTI", i));
11.         }
12.         cmdi.SetComputeVectorParam(FlowerFollowerComputeShader, "NearestLight", LightSortResults.GetPropertyFromTransform("position", 0));
13.         cmdi.SetComputeBuffer(FlowerFollowerComputeShader, FlowerFollowerComputeKernalID, "FlowerMesh", cmdi.RenderIndirect.VertexDataToComputeBuffer(VertexAttributes.POSITIONS | VertexAttributes.COLORS | VertexAttributes.NORMALS | VertexAttributes.TANGENTS));
14.         cmdi.SetComputeBuffer(FlowerFollowerComputeShader, FlowerFollowerComputeKernalID, "VertexDisplacementMatrices", cmdi.RenderIndirect.GetPropertyFromAdditionalRendererData<FlowerLightFollower>("m_VertexDisplacementMatricesBuffer"));
15.         cmdi.SetComputeBuffer(FlowerFollowerComputeShader, FlowerFollowerComputeKernalID, "VertexDisplacementMatricesIndices", cmdi.RenderIndirect.GetPropertyFromAdditionalRendererData<FlowerLightFollower>("m_VertexDisplacementMatricesIndicesBuffer"));
16.         cmdi.DispatchCompute(FlowerFollowerComputeShader, FlowerFollowerComputeKernalID, FlowerComputeTGX, FlowerComputeTGY, FLowerComputeTGZ);
17.         cmdi.SetGlobalBuffer(FlowerFollowVertexDisplacementMatricesShaderID, cmdi.RenderIndirect.GetPropertyFromAdditionalRendererData<FlowerLightFollower>("m_VertexDisplacementMatricesBuffer"));
18.         cmdi.SetGlobalBuffer(FlowerFollowVertexDisplacementMatricesIndicesShaderID, cmdi.RenderIndirect.GetPropertyFromAdditionalRendererData<FlowerLightFollower>("m_VertexDisplacementMatricesIndicesBuffer"));
19.         cmdi.RenderIndirect.Draw();
20.         context.DrawRenderersWithCommandBufferIndirect(DrawSettings, cmdi);

Now obviously this example reeks of reflection and serialization issues to name a few. But if there was a way to have this level of power, where SRP could adapt to any use case rather than a limited few (such as single mode light sorting) while still maintaining performance given whoever programs SRP doesn't do anything stupid without profiling, well, I know I would have a lot of stupid fun...

Anyways, looking forward to the next API update! Besides per-object concerns, custom shaderlab tag values for built-in types, awaiting lightmapping API, and the few other random things already addressed, I have no more feedback to give unfortunately.

Time estimates are always appreciated, but I totally get there's a lot of uncertainty and challenges for something so game-changing. We appreciate what you do!

 

Just out of interest, could SRP be used to create a pre unity 5.6 forward rendering system? I keep running into issues with the new allowMSAA setting in 5.6 and above, mostly I think due to the resolve.AA that happens. I've not checked the SRP source in a while so unsure if resolve.AA can be avoided, while still having MSAA?

 

Thanks for the brilliant, extremely helpful reply. Great amount of clarity, cheers!

 

I think we are probably going to need a SRP graphics sub forum. @Tim-C too soon?

 

Just realized you released the new API with the 2017.2 beta! At first I was a little disappointed that it wasn't back-ported to 2017.1 where things are stable, but then I cracked open the documentation (Can't actually open the editor due to some licensing issue/bug).

THE RENDERPASS API IS AMAZING!

I'm psyched! I prefer deferred rendering as most crazy effects I'd do work in screen space. And in the case of my FPS project, I'm also doing a bunch of MRT rendering of PBR textures for painted objects. This new API makes all of this about 10 times easier and more intuitive to do this kind of stuff, plus it comes with performance benefits! Also, the per-target blend modes is really nice! If there was a way to do this before in Unity, I am unaware of it and had to rely of CopyTexture commands and do bleding directly in the shader.

Quick feature request: Can we bind a render texture array slice to a RenderPassAttachment?

I don't have much to say on the ScriptableCullingParameters/CameraProperties API as the documentation isn't quite complete/clear yet, but I like the direction it is going. I'm guessing it is pretty new as not even the public repo uses it.

I totally get why you haven't had time to address features like lightmaps and per-object stuff. I just hope that as SRP develops, more and more of the API reaches RenderPass level of intuitiveness!

Now that 2017.2 is out with the new API, are you going to create a new thread there?

 

Cool. As you say probably alot of work, but at least it gives options.

I've been working on a recursive stencil portal rendering system ( which i'm desperate to find some time to update to SRP as I think that would be cool) and the result in 5.6 was just a blank (skybox) view. The whole rendering chain was broken, though I think in the end it may have just been due to some form of loss of the stencil buffer due to MSAA Resolves. In the same project I noticed massive numbers of resolves due to the recursive rendering ( via Camera.Render() ) required.

Thinking about it, my project might still be broken as I simply circumvent Unity allowMSAA and instead create my own renderTexture with AA and render directly to that, thus avoiding resolve.AA after each and every camera.redner() call until I've finished rendering all my cameras.

I guess the main point is that something changed in 5.6 and which I assume is how MSAA is dealt with, that ends up possibly destroying information between multiple camera renders as well as having the potential to introduce needless resolves when they are not required. Most likely this is just an unfortunate side-effect of Unity being a generic engine, vs the developers special knowledge about the render system they want to create. Funnily enough exactly the sort of thing SRP is going to solve

Having said that I recently found a very bizarre situation in my fixed version where the final resolve.AA appears to add content to the view that is not from my renderTexture at all - no idea what is going on there, it really doesn't make sense, so need to dig into it further.


A simpler to understand and more obvious issue with 5.6 MSAA is that canvas ScreenSpace-overlay has lost any AA capability! I submitted this as Bug 927346 ( QA just marked it as reproducible ). In a simple test create a 1 x 128 UIImage then arbitrarily rotate it. Prior to 5.6 if you had MSAA enabled it would be nicely anti-aliased, since 5.6 nothing, its just aliased. Interestingly using ScreenSpace-Camera does not have that problem, but sadly breaks other aspects of my code. I'm hoping this bug was just an over-sight that can be fixed as AA on canvas can be very important in some cases.

 

Since 2017.1 release is next week and this 2017.1 beta sub forum is probably going to be closed, Shouldn't SRP already have it's own sub forum?