on the right is ppv2 for bloom
this trend towards more complexity and less performance isn’t the best
how is urp pp?
on the right is ppv2 for bloom
this trend towards more complexity and less performance isn’t the best
how is urp pp?
PPv2 is slow because of its volume system. You can shave off a lot of cpu overhead by stripping some update code (that is more or less pointless in builds/runtime) from PPv2, there is a talk and a custom github fork for it here Post Processing V2 CPU Performance Concerns
I’ve heard the volume performance improved on SRPs, can’t tell for sure since I haven’t played a lot with them on my own but if what I heard and read over srp forums is correct, it should be better in terms of cpu usage than ppv2.
it also looks like the green stuff is taller but yeah cpu comes at a premium so how do I strip volume?
@Neto_Kokku to the rescue as usual 
https://github.com/KokkuGames/PostProcessing
I’ve heard that before and it seems super bizarre to me. Isn’t the volume system just a bunch of lerps for a handful of parameters? How is that slow?
From my understanding its not the volume lerping itself but fetching and updating all effect parameters from profiles @ every frame (the ones you also see in inspector when editing profiles, they get fetched and updated even if there is no value change). This gets expensive when you have effects that are using curves/gradients etc and lots of volumes.
That github fork removes parameter updates @ runtime iirc, but at the same time removes the ability to change values of the effects at runtime (they wont get applied unless you disable and re-enable the camera’s post process layer)
2 Likes
Ah… that means no depth of field following an object.
Because it’s a lot of lerps.
The bulk of the problem, by far, is the color grading: nearly all of its parameters are actually stored as AnimationCurves, and since there isn’t a way to know whether or not a curve changed what it does is re-sample the curves every frame. Worse yet: it takes 128 samples of every curve. And it doesn’t care if there is only one volume and there’s nothing to blend with: since the code is designed to look clever instead running fast, it does all that*. Every. Goddamn. Frame*.
It’s sheer madness.
Because it’s a lot of lerps. The bulk of the problem, by far, is the color grading: it uses AnimationCurves to store the curve values for each field, and since there isn’t a way to know whether or not a curve changed what it does is re-sample the curves every frame. Worse yet: it takes 128 samples of every curve. And it doesn’t care if there is only one volume and there’s nothing to blend with: since the code is designed to look smart instead running fast, it does all that*. Every. Goddamn. Frame*.
It’s sheer madness.
That still works. In the game we are using it in, for example, exposure compensation is constantly updated. What I removed was the crazy re-sampling of color grading AnimationCurves, as those are not supposed to change during run time by looking at the public API. The curves are sampled into an array of values, and that is what is used to blend between volumes. I just changed it so the sampling happens only once.
1 Like