Feedback Wanted: Scriptable Render Pipelines

You can get the newer versions of LWRP or HDRP from the Package Manager in 2018.2 beta or from Github if you want to mess with the latest.

 

This works for me

 

Thanks so much for the info

Do you think there are plans to add more types of lighting support to volumetric fog at some future unknown stage?

I'm thinking about area lights, but also some kinds of baked lighting and maybe even emissive materials?

I know some of these are harder to achieve than others, and that some things might not make sense if they dont support shadows yet. Or maybe some already work in some limited way already that I havent realised. You can probably tell that I lack the technical knowledge to know which light types it is practical to support in the volumetric system, so sorry if any of these are silly questions!

As for area light shadows, I know this is one of the areas where progress has been made at the 'research end' of things this year (not pipeline research, general graphics research shared with the world), so I really look forward to the later time when this stuff goes from theory & stand-alone demo project to something in HDRP! If anyone is interested in this area light shadow research (again, not Unity or HDRP version), I think a demo was released the other day: http://casual-effects.com/research/Heitz2018Shadow/index.html

 

No - SSS is not working, even on one monitor, when game window is undocked

 

Which version of HDRP are you on because in some older versions SSS would only show in one view if you have both scene and game view open. That's fixed now with the 2.x.x versions

 

This one ? https://forum.unity.com/threads/true-volumetric-lights-now-open-source.390818/
But, I don't think this works in HDRP.

 

beta9 and hdrp 2.0.4

 

it's weird - but now sss is working on every other monitor - I think there's a bug with it

 

Thanks again for the info

Regarding this last point, yes I have been following Erics work since he first presented the original area lights technique (without proper shadows) via Unity Labs a few years ago (actually I forget how long ago that was exactly). And yes, I should not have made it sound like the shadow research was a natural fit for your work/systems, and it is much too early I guess to know just what will happen with a 'mixed approach' era we might get in game engines in general. ie some of the approaches shown with ray and path tracing at GDC, which I understood to be hybrids where entire scene isnt raytraced, there is still rasterization, but with raytracing (and lots of denoise stuff) used for some specific features only. It might take a long time for this stuff to evolve, and there is so much left to do in HDRP with traditional approaches to realtime graphics, I should not get this far ahead into the unknown future!

 

@SebLagarde is it worth to support forward and deferred renderers in one pipeline? I'm not a rendering engineer and I had the impression that modern forward renderer is much more faster than deferred and also can handle more complex materials and vr. Also its very hard and time consuming to make everything work for both forward and deferred. I heard that forward cant handle many lights but I saw demos on youtube with hundreds of thousands dynamic lights implemented with some new forward technique(cant remember exact name). Can you elaborate about this?

 

I was bit surprised of this comment, I was expecting forward only mode to have only limited features. Are you planning to support things like SSR, decals (and mesh decals) on forward only?

 

Thanks for the reply. You mentioned current state of SSR, I've seen the new settings on Scene Settings but they don't really do anything on latest 2018.2.0b10 and 2.0.4-preview. Is it supposed to work already or is it still waiting for some changes from the engine side?

edit-> seems like I'm not the only one wondering about this: https://forum.unity.com/threads/screen-space-reflection.536885/

 

The answer is not much earlier in this thread: #706

 

Ah, I missed it, thanks Kinda bummer we need to wait till 2018.3, hope we get it at least on 2018.3 betas soon

 

@SebLagarde Some more questions regarding the 2.0.4 release of HD SRP:

1. In the legacy pipeline, for reflection probes there are options for "Clear Flags" and "Background Color". In HD SRP those options are missing. If I remove the skybox material (which comes back no matter what), set the Camera "Clear Mode" to "Background Color" with a color of black, add a reflection probe, then the reflection probe background color is blue no matter what settings I change. Will those options come back in the future?

2. In the legacy pipeline, there is an option to force reflection probes to be forward-only (by setting the Deferred Reflections shader to "No Support" in the Graphics Settings tab). This option was added in 2015 after a change was made in Unity 5.2.
See this thread.
Will there be an option to choose whether a Mesh Renderer is affected by reflection probes or not in deferred? Currently, setting a Mesh Renderer's Reflection Probes to "Off" does nothing.

Thanks.

 

IMHO it sounds like fight "sparkling effect" on smooth surfaces should be addressed as soon as possible (top prority, as everything hehe).
Right now, even on a simple scene with smooth objects, or with water puddles, what catch the eyes is this "sparkling effect", specially when bloom enabled.
Other than that the scene is very beautiful in HD pipeline, thats the reason i am counting the seconds to get rid of this sparkles on my scenes

 

Some critical feedback here. I tried adapting a plugin I have to work under one of the pipelines. (LRP v1.1.11-preview)

SRP still needs a lot of work if it wants to succeed. It's really not extensible, it seems you'd have to hand-write new features you want into a given pipeline by hand instead of using universal hooks and object-attached code.

Specific things that don't work:

• Camera.current is null in OnWillRenderObject
• Don't get onPreCull, OnPreCull, OnPreRender, OnPostRender camera events
• Calling Camera.Render() while rendering blanks out the rendered view. (And remember, you can't get the latest VR pose until you are already rendering.)

If the answer here is "SRP shouldn't support things like that, it needs to be built into the specific pipeline" then:

• Don't ask Asset Store authors to support SRP. We can't write something that's generally compatible without some common standards and good API hooks.
• Don't expect third-party plugins that can augment any sort of visual capabilities in Unity.
• Don't expect most people to be using any SRP pipeline in future.

SRP should be a way to alter the way things like Camera.Render() work, not a regression of rendering systems toward the days when you wrote your own from scratch and had to hand-cobble in every special rendering feature you need.

 

Hey guys, please help.
The "Procedural Sky" values in the Volume settings are causing strange lighting behavior on indoor areas... the inside walls (even if i reduce smoothness to almost zero) are getting what appears to be strange reflections where should be dark (attached image)... disabling the sky eliminate the problem, but obviously is not an option.

In vanilla Unity i can aliviate this same behavior decreasing the values on the "Environment Reflections"... where are this settings on HD Pipeline?

Any other tip?

 

Since HDRP and Shader graph, there is little to zero augmentation required. HDRP for me, offers AAA rendering capabilities with similar performance. What is there you would do, that an AAA engine cannot?

Funny joke.

If you are making rendering tools, then it's sufficient (IMHO) to support LWRP and HDRP. I don't see what the big deal is. Studios and individuals have been asking for something that can compare with AAA for years. That comes at a price I willingly pay.

 

Shader Graph doesn't solve all shader needs. We still need custom solutions and that's pretty tedious process atm due to how SRP is built.

 

We are rapidly finding we do not need more, really. Just nudging existing stuff. Still finding it impossible to see what AAA is doing, that we presently cannot do within HDRP + shader graph. I even have great water. What is missing that *you* personally require?

 

Who is "we" in this context? Today, Shader Graph is far from feature complete but even when they get it all done, it still can't do everything people do today with custom Unity shaders. If you look what happens on other engines, UE4's materials allow pretty complex things but they still have their limitations and you still need custom approaches for some things.

Water is one example as it's pretty complex thing when you do it "right". I've seen some impressive water shaders done in node graphs but most realistic ones have always been done with custom code.

You could also look at Book Of The Dead, it's shaders are modified from the stock HDRP instead of building new ones with Shader Graph. In fact, they even removed the whole Shader Graph from the SRP on it because they didn't use it.

 

@hippocoder @rizu I have to agree that custom solutions are needed. Or perhaps not always -needed-, but prefarable for sure! I love shadergraph, but I also want writing custom master nodes for it to be easier. I dont really care about the custom node workflow, as long as master nodes are not so difficult.

 

Newbie here. So you're meaning that if SRP wouldn't support hooks and extension points, we'll start seeing things like "HDRP 1.0.4 Custom Water Fork" and "HDRP 1.1.2 Realtime GI Fork", making using and merging custom features a nightmare?

 

Exactly what I said, our studio, or "me". We are doing a complex 3D title that benefits from all the stuff you would normally find in an AAA complex 3D title. Environment. Characters. Effects (Indie budget, just saying - HDRP brings AAA rendering features to me)

For example, today with HDRP you can make a clone of Uncharted 4, God of War, Latest Battlefield. Any Dice title (as far as rendering goes).

What exotic thing do you want to make that isn't covered by these titles? Whatever it is you guys are making, it's going to have to be pretty custom I guess.

With old builtin renderer I would have been totally in agreement, but HDRP is really, really good when you dig in. It's hard to figure out what is missing.

But if you can totally nail what is missing, it would be best for it to be advertised so that it can be included in the graph or HDRP.

If it's guessing at theoretical maybes, then I'm going to have to say that I don't need more than the above mentioned blockbuster titles.

 

HDRP has/will have everything would you need to just make a high-quality game graphically. Book of the Dead was made before HDRP shader graph was out so it would be using a custom Lit shader rather than a Shader Graph shader. Anything too custom that is being mentioned is probably an SRP thing rather than HDRP. Meaning you might be thinking of a custom SRP otherwise, it's just asking for extra nodes in shader graph or just asking for a better way to just write shader code (which the devs know about) for those who prefer to do things that way if you don't want to use shader graph.



Being able to easily write custom master nodes will be nice as well. When HDRP is fully feature set matching what the Standard Lit Shader can do with all the lighting models present and yet to come (cloth, subsurface etc) that will be good for pretty much every situation.

So from what I'm seeing it just comes down to more custom nodes/a way to easily make custom master nodes which will be for specific use cases (so that's a per project thing), an easier way to customize or write the Lit/Shader Graph shaders.

I would say wait for Shader Graph to be finished before worrying about what's missing on the HDRP side of it since this will be the version that will have the most options per material.

 

I am quoting another thread above, to contextualize...

I ran into that shadow atlas size issue (error "Shadow allocation failed in the ReserveFinalize step").
The only light on scene is a Directional Light (mixed) with shadow resolution at 2048... if i add any light (spot or point, low resolution - 128) to the scene i get the error and no shadows anymore. If i increase the shadow atlas height / width (to 8192) in HDRP settings the error goes away.

My concern is that my scene is VERY small and very simple... i wonder if i will need to crank up to a much higher value the shadow atlas in bigger scenes, in order to accomodate more lights / high res shadows....

 

you might want to utilize per light shadow fading distance

 

I started experimenting yesterday with HDRP under Unity 2018.2 latest beta. The results in the demo scene look pretty good on my 4K monitor, but I've run into some questions about architecture. I realize SRP in general and HDRP in particular are very early in development, but I'm looking ahead as to how best to make my Asset Store editor extension compatible. It's an edit-time tool primarily, and generates (and renders procedurally) meshes with a custom unlit shader that uses barycentric coordinates for wireframe highlighting as well as some other features.

The rendered meshes are very small and simple, and rendering in the game mode is NOT intended to be a common thing -- it's for short-term use during debugging or for a very small number of meta-game objects such as quest targets or map markers. So my emphasis is on flexible configuration and easy deployment, not necessarily raw performance at runtime. (The point here is that I'm not doing draw-call-per object out of ignorance, but as a conscious choice allowed by the specialized nature of the tool.)

My extension actually -- and to me somewhat surprisingly -- works correctly in the Scene View even in an HDRP project, but as I expected the objects are invisible in the game view.

Of course I've read the wonderful post about the changed callbacks (thanks for that!) and have adapted an experimental version of my code to intercept the new beginCameraRendering event, and I've verified that I'm receiving those callbacks. Where I'm still in the dark is, how do I actually inject the drawing of the mesh into the new SRPs, without writing my own custom pipeline? If the only way to do an "immediate draw" in game cameras is through forcing people to use my custom pipeline for their whole project, then that's not viable. I've read some of the example code on Github and also the relevant posts on this forum, and so far I'm not seeing any way to inject a mesh draw without a custom render pipeline -- but I've got to believe I'm overlooking something.

Currently the draws are happening with Graphics.DrawMeshNow(). Is there a general equivalent of this under SRP?

One other thing I could do, if the SRP architecture allows it, is to inject the meshes into the render buffer, but I'm not clear on how to do that in a way that does not depend on the pipeline in use.

I'm not asking Unity to write my code for me, and I'm also not needing to solve this right away since it's obviously going to be months before HDRP is "production ready". I'm just trying to get ahead of the curve a bit so I can gradually swing my asset's code base in a direction that allows me to maintainably support builtin rendering, LWRP, HDRP, and other people's custom SRPs.

Is there documentation on how to add a custom node to the ShaderGraph? I'm considering whether it's worth implementing some of my existing shader's custom features as ShaderGraph nodes.

Mainly what I'm asking for here is pointers to information I may not yet have found on the SRP Wiki and the rest of this forum, or if anyone else has solved this problem. (If you have, and your help gets me across this hump, I'll gladly "comp" you a copy of my asset!)

 

Some ShaderGraph feedback, since "feedback wanted" is in the forum topic:

• It's pretty easy to use overall. I started watching an hour-long tutorial from Unite Berlin, but got antsy and started playing on my own even before the tutorial finished (although the tutorial is quite good...no offense to the presenter!).
• I had an intermittent bug where the blackboard sub-window would "stick to" my mouse cursor and not let go. This usually happened if I was adding a Property input to it, and seemed to be related to trying to move the mouse out of the area of the blackboard while the current field was one of the data fields within the new Property rather than the blackboard window itself. I initially hit this under Unity 2018.1.6 with the latest SRP and SG from Package Manager. I haven't seen it as much under Unity 2018.2 beta, again with latest SRP and SG from Package Manager, so maybe it's a bug that has been fixed. (Closing the ShaderGraph window and reopening it on the same graph reliably resets away from the problem.)
• One problem I've found with SG is that its asset files appear to have the same extension as regular custom-written shader source code. This makes for a conflict with third-party text editors such as Flipbook Games' excellent ScriptInspector 3. Since the option to export shader source from SG makes it very clear that a ShaderGraph asset is not just regular source code, it would be very helpful if SG assets were named differently from regular shader source so external tools can tell them apart. I've also reported this to the developer of SI3 to see if he can work around it.
• You've got a lot of interesting nodes in SG, and I know more are being added. One thing that is very cumbersome to do right now is to select one of many inputs (of arbitrary type -- Vector, Color, Boolean, Texture/Map...) based on an integer value. I got it working with a string of branch nodes, but it's "chalky and unpleasant tasting" in the extreme. How about adding a generic Multiplexor node that can have an arbitrary number of data inputs and a single data output, with an integer selector input that chooses which one is routed?
• It appears to me that your Vector1 type is roughly equivalent to a Float. Is this actually the case internally? If so, it might be clearer to rename Vector1 to Float or to clarify the equivalence in some other way.
• This may be a reach, but it could also be useful to have some kind of enumerated input property. In my custom shader, for example, I accept a primary color as an input and also an integer that determines one of four algorithms by which a secondary color is determined (three are differently computed from the primary, and the fourth overrides the computation from a secondary color input). I can't be the only one who needs to do something like that.
• It would be really useful to have some sort of corner/edge detection node built in, either barycentryc or similar, for things like wireframe effects or edge highlighting. If that's already present, I didn't see it. I tried experimenting with derivatives of normal and tangent direction, etc., but you don't get the same kind of result.
• When time permits, please add to the SRP Wiki an example of how to make a custom ShaderGraph node type.
• In the output preview, if one is using a custom mesh, there doesn't seem to be a way to actually move the preview viewport, just rotate and zoom it. This can be a problem if the custom mesh has its origin at the bottom or somewhere else that's not near its center, as would be the case with many architectural objects.

Thanks for providing this feature. I think it's going to make a lot of designers and technical artists very happy.

 

Hi Seb and Tim,

So some quick notes after a few days evaluating SRP: HD for a large indie game (Pheonix Point). Still on 2018.1 as I'm testing on PC and XB1 currently, so my comments might be out of date a little. Focus for me is whether we can consider use it in production for a game releasing 2019.

Performance and quality is pretty good on both PC and XB1, however there are places its lacking.

Auto upgrade and texture packing from Standard to HD is nice.

Shader graph is coming on well but bit worried by performance (note I wrote AMD's RadeonRay to UE shader graph translator a year or two ago, so I might be a bit paranoid about this ).

The material upgrade tools are great but it would be awesome to have the functionality available on a material (so for example letting the artists use single channel textures and auto-pack them on change). SRP:HD has a very different art interface (texture channels etc.) and ideally we could provide a custom input layer for the common cases (i.e. they are used to using Standard shader inputs)

Structurally its not very modular or indeed scriptable itself, instead of having a base handling most geometry/shaders with bolt on fancy features, its an all or nothing approach.

It seems to be focussed on new features rather than making it production ready. The underlying tile/cluster rendering is something we really benefit from and tbh I'd be happy with just the features unity currently supports at a production level with SRP:HD. No ETA on the basics part being production ready makes it hard to decide go/no go. Currently it seems we have to either use the existing and relatively slow default unity path or basically accept maintaining a custom renderer based on current SRP:HD.

So my current thinking is that it would be possible to ship with it, but requires an experienced renderer/optimisation person/team that treat it as a 'drop' and then maintain/merge/fix over the product lifetime. The big gain for us would be performance rather than new features, so we stuck in the middle gap. Old Unity pipeline quality is okay if we accept low performance where SRP: HD has the performance but seems to be focused on new features.

Anyway hope those thoughts are useful

Thanks,
DeanoC @ Snapshot Games