HDRP new post processing extending

I have installed Unity 2019.1.0f2 with HDRP 5.7.2

How can I change parameters by script (Namespace)?

 

Same problem here. It is very frustrating. I think PP extending significantly more important for the developers, than something like raytracing. Nobody asking for shader graph integration, just give us simple api (ppv2 api was great), even it will change 100 times in the future and will be not so performant at this moment.

 

*I'm asking for SG integration, it's a real bummer that we don't have PP Graph out of the box. People hacked this for PPv2 already but then HDRP PP became a thing and those 3rd party workarounds don't work anymore here.

For comparison, UE4 has had PP node graph support from day one

 

Felt the same way for a second there but remembered UE4 was a full release and HDRP is still in preview, so it's not really a fair comparison. If that was the case then PP in Shader Graph would have to be rebuilt for the new Prost Processing pipeline.

 

It doesn't work, because there is no API. So we need API in the first place, to do something.

 

I've already manually modified HDRP PP, I know the deal Just wanted to point out that there are people who would want SG PP.

 

Is there any update how to create new plugins for HDRP?
Will it allow extending just for PPv3 or there will be a new specific way (not using PPv3) to create effects?

 

There will probably be API to extend the PPv3 in the future, just like the PPv2 had. Looking through the source code of PPv3 on their github, there is a comment line "todo - user effects go here" or something like that in the place where the effect rendering gets handled, so it definitely seems like it's coming ^^.

We're also looking forward to it.

 

Just to make sure I haven't misread anything here, I understand it's not currently possible to create post-processing effects in HDRP 5.13, the way I was doing under PPv2 using PostProcessEffectRenderer?

 

Yes, it is not currently possible

 

Right! There is no API for it currently. I mean, I get that HDRP is experimental and hardly production ready, and is still being worked on a lot, but releasing the new HDRP with PPv3 with no option to add custom effects (on which a lot of projects and 3rd party assets like ours relies on) and without at least letting us use PPv2 as a work around (though from my understanding it is not possible due to implementation limitations.) still shocks me

To us it looks like the whole thing was rushed out for 2019.1...

Edit: if you have the knowledge its still possible to add support yourself if you can't wait for the official API. Looking at the source, it doesn't seem that hard, but for us that's no good since we use the PP custom effect API for asset store products, and we can't rely on such "hacks" for those.

 

> we can't rely on such "hacks" for those.

I think it's acceptable in this case. Anyone brave enough to buy assets for HDRP - which is after all still in preview - surely would accept the need for temporary workarounds until there's official support.

Personally I've been hacking around the lack of custom blocks in the VFX graph and I've got no qualms about it. As soon as there's official support I'll hopefully change to doing it properly. And if I can't for any reason then I'm prepared to hack my way round artificial restrictions for as long as I need to. I'm a firm believer in the "we're all consenting adults" approach to encapsulation and access control.

 

I get your point, and is a fair one, after all that's why the pipelines are open source to modify them to fit your needs. However we as a studio have other tasks and projects that also need to be handled (for example most of our work hours now go into our game project which is due to release this summer), so for us it might not be the best practice to spend hours just to implement a feature that will be added anyway in a unity update sooner or later, just to have to revert everything back, spending even more time to do it the proper way (which in our case was already working out of the box and was easily implemented for PPv2).

Also since we're talking about adding missing parts to the pipeline code itself, the "fix" might not be easy to ship in an asset store product since the HDRP itself comes as a package, and the "hacking" part will end up being handled by the customer by tinkering with the package's source (which in our case, most of customers are not coding savvy and come from archviz / art / cinematics fields)

So in the end it really depends on what you are trying to achieve with the SRP and where does your implementation end up being used.

Edit: This is in no way hate directed towards Unity or you, just my and my team's point of view regarding the situation.

 

I can't find ppv3 anywhere...

 

PPV3 is integrated into the HDRP itself, not a separate package. It's the "Volumes" that exist in HDRP. Now they contain the postprocessing effects too.

 

Also to add to this: people using HDRP should uninstall any PPV2 (it isn't working and will not work)

 

In case you're still looking for an answer

Cross-posting this from the HDRP feedback thread, hope nobody minds

using UnityEngine.Experimental.Rendering.HDPipeline;

Then I set a volume with all the other variables like this, then assign it in inspector:

public Volume AdjustablePostProcessingVolume;


This is the basics. You might want to call it something other than tmp if you're doing multiple things all under void Update or whatever, but this is how you get values.

 

You might want to edit your last post here just to clarify the current status quo (it's locked).
Likewise, Unity should update this page here with any relevant info about that code compatibility.
Cheers

 

I second this. With the current complex state of affairs related to SRPs and related features, it's fairly critical to keep online docs up to date.

 

Why would we need to use volumes though to make a simple image effect ? It is an overkill, i would rather have the option to use the stack separately of volumes like in Unity 2019.2 (where the stack works fine)

Maybe some users need image effects without using full volumetrics and make the game crawl.

Also how do we extend this new pipeline without instantiating it ? So users can actually use them in assets, because if instantiated and changed will break everything else that uses the default HDRP pipeline.

 

Will the stack also not work in Unity 2019.2, because in the current Beta works ok. Thanks.

EDIT: Just had a quick look and the new post processing effects seem to use compute shaders. Is there no way anymore to use simple globally compatible shaders to do an image effect in HDRP pipeline ?

 

Support for PostProcess v2 will probably go away completely when 2019.2 will merge with the changes that happened in 2019.1 if what was written by unity staff in the previous page still holds (PPV3 will be only for HDRP and in the future also LWRP, PPV2 only for built in and LWRP.)

At this point I really hope more for a way to inject our own command buffers into the camera's render loop (for our asset it would be a better implementation than using volumes since SSAA rendering can't be blend between volumes anyway and it just makes everything more hacky) I've saw something relevant to this in the HDAdditionalCameraData API but is not of much use for us in the current state.

Compute shaders can be generally faster on current gen hardware (which HDRP is targeting), but I really doubt they will force us to use compute shaders for our own effects (well I won't be surprised if they do either, after all look at how everything changed in 2019.1 HDRP ) I think some posts ago some guy from unity stated that ppv3 will get non compute shader support for a LWRP integration in the future, so probably (or hopefully) it will be available for HDRP too.

I hope they take into consideration that it would be harder to port existing assets that already exist for ppv2 and use regular shaders if they were to force a compute only implementation.

 

I think they have converted most effects to compute shader, that is why i assume may not be compatible with simple hlsl shaders, but i do see few shaders in there as well, now trying to decypher how all these work to try and create some effect that references something from the new HDRP post processing pipeline, but i am in the dark as to how this new stakc works so far

 

Hi. It would be really nice to enable custom HDRP post processing via shadergraph like
Amplify Shader allows it for PPV2.

 

They are working on it: https://github.com/Unity-Technologi...commits/HDRP/feature/post_process_master_node

 

Amplify will probably allow it too after HDRP gets the custom effect implementation done. But I feel like I'm getting a bit offtopic

 

Really good news.

 

Can't wait this feature. I hope that it will be as powerfull, as the PPv2 extending.

 

Please give us SSAA in some form ... whether its built in, or giving Raul_MadGoat whatever he needs to get his product working in HDRP.

 

quick question, is the new way to do image effects like bloom in Unity 2019.1 to be used for future Unity 2019 releases, or all that is going to 100% change for next versions and be abstracted in a stack v3.0 ?

Is there any incentive in spending time to extend this new system, or will change soon ?

Thanks

 

Hey guys, I have a question about accessing the Color Curves Override of the new HDRP post processing stuff. Hope it's ok if I post this inhere.

This previous post helped me a lot however I'm stuck:

As you might know, the ColorCurves override looks like this in the UI:


What I intended to do is access the existing points (here two) and change them from script.

I managed to get access to the Color Curves override like this:

Code (csharp):

1. using UnityEngine.Rendering;
2. using UnityEngine.Experimental.Rendering.HDPipeline;
3. ...
4. private Volume volumeComponent;
5. ...
6. volumeComponent.sharedProfile.TryGet<ColorCurves>(out colorCurves);
7. //colorCurves.master.value;

From the last line:
"colorCurves" is of type ColorCurves
"master" is of type TextureCurveParameter
"value" if of type TextureCurve

I'm assuming the last one contains the "points" or keys I want to change. According to the documentation of TextureCurve apart from the length property (which I can access), there should be the Keyframe Array containing the Keyframes. However I can't figure out how to access that, as my IDE tells me it's not there.

Am I misunderstanding the documentation?

In TextureCurve, there's also the method MoveKey, but it again requires a reference to said KeyFrame array.

 

So we still can't write our own postprocess effects for HDRP, we can use stack v2 for LWRP but it will be replaced in future so I guess there is no point learning it at the moment, right?

 

sounds about right: https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3933

This LWRP PP PR got merged to srp master few days ago so it means 7.x/2019.3+ LWRP (or Universal RP after name change) will not support old PP package at all.

 

Interesting, seems like pp is very abandoned, seem bit strange

 

Which rather increases the urgency of implementing custom filters in the new system.

 

True, though there is no clear way on how to do that yet, i already checked hdrp ones and are very integrated which means need to create custom pipeline, which in turns means would be incompatible with everything else, so is dead end for now.

My guess is these will be abstracted and removed from hdrp pipeline package, but cant tell when. At that point will make sense to extend them i hope.

 

I doubt since one of the main reasons for the new HDRP post volume system seems to be better integration in the pipeline itself to improve performance etc. but with unity we never know..

 

@nasos_333 Looks like Keijiro has figured out how to add custom filters to HDRP: https://github.com/keijiro/HdrpAovTest

Is AOV Request a documented feature? By documented I mean something better than the API docs which tend to be limited to inscrutable statements like "Use this request to define how to render an AOV"

 

That looks promising! Thx for sharing the link

 

Amazing find, many thanks

 

Looks like hack for me.

 

Nice. Could not find any info for what AOV stands for.
Does someone has an idea?

 

Probably Arbitrary Output Variables.

Google that term and you'll see it used a fair bit with other sorts of 3D graphics rendering software.

I havent looked into its use in Unity scriptable render pipelines yet, but lately I hae also been seeing lots of mentions of a RenderGraph now being used in some recent github HDRP pipeline versions. eg stuff making use of UnityEngine.Experimental.Rendering.RenderGraphModule

 

any news considering release of 2019.2 ?

I've tried to fork and modify HDRP itself, but the differences in where specific macros reside in comparision to StdLib.hlsl from PPSv2 was a turn-off for me. Maybe someone has some advice how to manage to get those in correct way? Is there some sort of migration guide PPSv2 -> HDRP Post Processing?

 

No I haven't had any luck getting the post process stack working in 1019.2, however I have managed to modify this (by the wonderful Keijiro, of course) https://github.com/keijiro/HdrpBlitter to basically recreate my effects. It' not as elegant as the older system was, but it works until there's an official update.

 

Any new ETA?

 

In case that anyone needs custom post processing & hdrp in 2019.X - I wrote small step-by-step tutorial how to achieve this by actually modifying the pipeline itself: https://medium.com/another-angle/custom-post-processing-using-hdrp-in-unity-2019-x-60302a2fa1e0

 

Thanks for the input in this, very cool.

One major issue with HDRP atm is that it needs to modify the pipeline itself, so cant be compatible with future versions, that one reason Unity needs to create some way to do that outside the pipeline.

 

Sure, I cannot agree with you more. But!

After digging in HDRP code itself I've gained some knowledge how stuff works under the hood. It is really valuable I think. As for compatibility with future versions - it shouldn't be too difficult if you can handle git merging pretty well

 

@nehvaleem Out of curiosity have you looked at the AOV workflow as seen in Keijiro's repo?

https://github.com/keijiro/HdrpAovTest

How does it compare with your approach?