PRISM - Realistic All-In-One Post-Processing for Unity

Can you do color grading via Photoshop with this asset?

We recently saw this video and are wondering if there's is something similar for Unity, and this seemed pretty close:

 

We were not planning on using the AO in this package, but just testing it, is this normal behavior?

 

One more thing, the fog behaves weirdly with close values, but also, there isn't any falloff setting? I'd like to use it as atmospheric distance haze for the Ultimate Water Asset, but the fog beging too sharply regardless of setting:

 

Yep! The way I do it in photoshop is just importing the "Neutral" LUT that PRISM comes with, making all my edits in photoshop, making sure those edits are also applied to the LUT, and then just saving out the edited LUT.

Hard to tell without knowing all your scene-specific values (particularly your depth precision) - is it the same if you switch to deferred and use the G-Buffer for depth/normals?

That doesn't look right, I'll look into that. Does it help at all if you try super high (or low) values in the inspector there?

 

Thank you for the replies! The LUT will be interesting to experiment with.

As for the AO, today when I fired up the project, the strange behavior was gone. We did not change anything, but our camera is set to 0.05 near and 300 far (it's a VR applicatioin for product inspection, so we view highly detailed models up close).

I also checked the fog again, and I don't know, it might be behaving normally (apart from the flipping up close issue perhaps), only we want to use it as atmospheric haze, something that neither Unity's fog nor this was made to do...

 

Two different machines have now produced the following errors on build:



Running PRISM in the editor works fine, but not building.

There's supposed to be Direct X 11 setting in the PlayerSettings dialogue (since d3d11 is mentioned), but in 2017.3, the only reference to Direct X 11 I can find is the fullscreen mode, which is set to "fullscreen window".

We are building a SteamVR application targeted to a 1080 graphics card.

 

Hi Eker,
I'll DM you to dive deeper into this one. Looks like it could be a Unity import issue.

 

Hi, a quick question about your Prism asset: I see there's mention of VR support in the update notes, however can you confirm that Prism supports Single Pass Stereo Rendering (SPSR) with its effects? And does it also support the newer Single Pass Instanced Rendering as well? Thanks!

 

Well I bought it anyway as I'm looking for an adequate DOF effect that works in VR. Unfortunately there are multiple shader errors when trying to build with Single Pass Instancing enabled (in Unity 2017.2.0p3 and Unity 2017.2.2p3):

Shader error in 'Hidden/PrismDepthOfField': undeclared identifier 'sampler_CameraDepthTexture' at Assets/PRISM/Shaders/Prism.cginc(384) (on d3d11)

Compiling Vertex program with STEREO_INSTANCING_ON PRISM_DOF_MEDSAMPLE
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP SHADER_API_DESKTOP UNITY_LIGHT_PROBE_PROXY_VOLUME

I've no knowledge of shader language unfortunately - is there a possibility that you could look into getting Prism to work with Single Pass Instancing? Thanks.

 

I have a question about the mobile support ( I'm kinda new to unity ) : While reading the description of the asset I got to a point where I saw Mobile (SM3.0) compatibility; I made some research on my how and I came to know that it is Shader model 3 but I was not able to identify since what time it has been used on mobile devices .
I'm saying that because I want my game to be compatible with as many lower-end phones as possible and I'm not understanding the compatibility extend of your asset. (since I don't really understand that SM3.0 thing properly ).
can you enlight me, please?
Thank you .

 

But is it working with regular Single Pass? That knowledge should help me as author didn't specify it exactly even though after going 3 pages in the forum I have learned someone patched some stuff for single pass in 2017 yet I am not really sure.

 

If you guys could confirm this that would be helpful. It should work with regular single pass, unfortunately I don't have an HMD so am limited in what I can guarantee works with VR. SP Stereo is super flaky with how much Unity has been changing it lately, so again I wouldn't recommend banking on PRISM's support for that.

Hi,

Short answer: PRISM is perfect for lower end mobile devices when you want to put more than 1 posteffect on the camera. That is one of the main design considerations of PRISM, it has been tested and released on multiple low end platforms/devices, and if you have any trouble, it is a platform I own myself and so can provide direct support for Short answer, go for it!

 

I'm guessing compability with other assets isn't a priority, but if anyone has any tips on how to get depth blur working together with Playdead's TAA (https://github.com/playdeadgames/temporal), it would be greatly appreciated!

 

When will Prism get LWRP support?

 

Currently on my TODO to look into now that the LWRP is looking stable feature-wise, for anyone that needs a version ASAP, feel free to PM me for more info.

 

Hello there, I am using Prism with the Lightweight scriptable pipeline and it is not working at all, anybody else having the same issue?
If so, anybody found a solution?

 

HI there!

I read that Prism supported Single Pass Stereo rendering but... it isn't true for me, on Unity 2018.2.3f1!

Bloom and sharpen modules break the effect. They're pretty essential, and using a 3rd party solution defies Prism purpose and benefits! (it's really faster than the post processing stacks!)

Could you please fix them? Other 3rd party solutions had the same issues, but fixed them when asked.

I guess other modules using the same approach are breaking the FX as well.

Im also getting the weird banding @ekergraphics is getting with AO. Is there some setting to increase the number of "slices"? Looks like the artifacts is only noticeable when looking at almost orthogonal surfaces.
In editor it flickers for some reason (Depth method: depth normal texture, VR headset either plugged or unplugged), but it gets totally white when running with the headset plugged in! (no AO contribution at all)

I'm on a nVidia 1070, Forward rendering, HDR, default RP, Linear color space, SPSR, currently testing on an Oculus (so all postFX are on the "central" eye camera). and I have no other PostFX on the camera, of course

Here are a few pics of the issues:
Split Bloom:


Sharpen (totally breaks Single Pass Stereo rendering):


AO (in editor-please note that the above pics had it ON, but actually wasn't working):
This is "View AO Texture", but the artifacts are visible when playing in editor with the Oculus unplugged.
Plugging it in makes the texture go full white in game.


That's... some pretty serious banding, also affecting non-VR projects. Doesn't matter how tweaked the settings, I could only bump the contrast all the way up to smooth it a bit. Ending with a totally different result, of course :/
AO settings are set to max quality, max samples, Blur type wide, blur pass radius 2, 2 blur passes, AO contrast 1 (because with 0 it simply gets worse):


Is there some way to preserve a crisp separation in the AO map? Just setting it at 2 blur passes already feels like I'm using a downscaled texture.
May I suggest temporally interpolating the dithering, to preserve some detail? Or maibe using depth map/normals to prevent blurring pixels that are not facing in the same direction/that are on different depths?

I understand you may want to keep it lightweight, but the AO module really doesn't keep up with everything else, which is really a pity

Could you please have a look at this? I understand you may not have access to a VR headset at the moment, so I'm volunteering to test.

These modules are pretty essential, and if just one of them breaks, makes the whole asset unusable for VR (single pass), and this is getting more important day after day, especially now that the next Playstation is going to leverage on VR a lot.

The fog module also gets either transparent or full white, I can't understand why.

Please don't get discouraged by the amount of extra work, I'd really love to use Prism in my VR projects and tests as well!

Keep up with the great work!

Best,
Alessandro

PS: I know there's already a lot going on, but I'd love to make 2 feature requests
1) Have different light adaptation speeds, one for reacting to sudden bright light (which generally is faster), and a second one to adapt to darkness (usually much slower)
2) Possibility to enable a Filmic grain clamping/fading flag, so that it only affects darker areas, and leaves the bright parts untouched. So two values would be needed, in a similar fashion as other similar features: starting brightness and fade speed. Some people would probably want to do the opposite: grainy brights and flat darks. Of course this has to be done as one of the last passes, since I don't want eye adaptation to bump up or down grain intensity.

Or... is it already working like that? I can't see grain on bright areas, yet it's rising the brightness too much and too soon, so midtones end up being gray-ish. If so, probably a Bias/esponent + offset would help. It just ramps up too fast, and it's too present in dark scenes.
Having a different monochrome shader alternative would be nice
Filmic grain works perfectly in VR+single pass

 

Hi Alessandro,

First off - apologies for the late reply, did not get a notification for this one! Thanks for the detailed post. Regarding SP Stereo support on 2018.2 - definitely want to get that working, as you mentioned it has been an uphill battle without an HMD to test it on but feel like we're very close as is and if you would be able to shoot me a DM or mail via the support mail, I'd love to provide some 1-on-1 support and work together on a solution for you.

Regarding AO - IIRC that is a side-effect of using the "Depth Only" method - can you try switching it to deferred and seeing if that fixes the stepping? That definitely shouldn't happen and in all my testing I haven't seen anything like that when using the preferred Deferred or DepthNormals methods.

1) On the TODO - currently I'm looking at ways to better integrate PRISM into 2018.x in general, and this specific feature may get rolled into more of a general 3.x update, which I want to do.

2) I like this idea alot - again would probably go in a 3.x release, but I can see myself using that. I think not being able to see grain in bright areas may be a result of the effect in general not being applicable to HDR colours > 1 - ie. if I go and set my camera to 12,000 ISO and shoot a person against the sky, with the exposure set to match the person's brightness, the sky will not show noise, it will just be a blob of brightness.

 

Been having a solid play around on Unity 2018.3, lots to change in PRISM to keep up with Unity's direction with Post-Processing, but confident PRISM v3 will be a solid new foundation built to the way that future Unity post-processing is heading. After taking a look at some of the things Unity are doing, there's things to like and dislike, namely their move to hlsl, which now requires a lot more 'busywork' on the user end to maintain across APIs than shaderlab; a bit of a misstep there IMO.

What this effectively means is that a future PRISM version (v3 in this case) would simply not be backwards-portable to 5.x versions. In light of this, the current v2 version of PRISM would stay fully supported on 5.x and 2017.x, but the new v3 would turn into the version to use for 2018.x. Currently, I'm thinking this may end up taking the route of having to be a paid upgrade, in light of the fact that I will have to spend so much time updating it - PRISM is thousands of lines of shader code that has not seen this big of a change since release in 2015. However, I value the input of PRISM users here, and encourage any discussion around this topic. Basically, my goals are the same as every other developer here - to continue the development of the asset that started the post-processing revolution in Unity, and continue to support it for years to come.

As an aside, something that has always been a widely requested feature from PRISM, now in testing on my v3 branch - PRISMAA - superfast, depth-based AA that has an (almost) 0 cost when used with PRISM.Sharpen! Works beautifully on grass and other depth-based jaggies, and the method used avoids 100% of the dreaded FXAA-blur. My goal is for it to be a default on any mid-range mobile right through to desktop.

A bit of eye candy to end on, featuring PRISM.AA (beta) - most visible in the grass and table.

PRISM Off:

PRISM On:

 

Hello GoGoGadget!

I enjoy when devs say discussion. It’s always cool hearing what others have to say!!

Your goals regarding pricing and update seem right. As 1, paid asset, 2. Code refactoring. I think that sounds right.

Question I wanted to put up here since were discussing future stuff, will (hopefully) real-time ray tracing and path tracing be in prism? This might seem crazy to ask. But since prism is post processing, and ray/path tracing is also light. It logically seems to be in the same category.

If something like that would be in a post FX, that would be cool!

I also understand that something like that is pretty major. So i’m ready to discuss

Thank you!!

 

A line always needs to be drawn eventually for an upgrade, and I think a new Unity version with breaking / forced refactoring is the perfect time.

 

Hey Xalox,

Thanks for the feedback there! Regarding your question, as soon as I saw NVidia's recent RTX demo, I hopped straight on and did some digging into the current state of DXR (DirectX Raytracing) in general, and in Unity - no doubt it's cool to be able to even think about real time pathtracing. RTX is apparently coming to Unity, since Nvidia used Unity's logo in their presentation among others, what I imagine it will be is a generic Unity DXR implementation with NVidia's API as an optional extra.

The key thing to remember about that is that DXR isn't possible in shaders alone - it requires the CPU to submit the correct scene information in a specific DXR format first, so basically, Unity has to be the first to lay the groundwork before us shader devs can start playing with it.

Worth noting as well - technically "real-time raytracing" is actually already in PRISM, PRISM's AO uses raytracing Pathtracing, however, will have to wait until DXR.

 

Awesome!! Ah I never knew that, that’s really cool! I have studied into it a bit. I understand it has been done with a compute shader in Unity (path tracing in general). Does that lessen the performance?

Thank you!!

 

In general, doing it via compute shader is currently the fastest/only way to realistically do it until DXR comes out. This does of course mean that devices that don't support compute shaders (sub-DX11) automatically don't work, and anything sub DX12.1 (DXR) won't support that either. So while it is exciting technology, any work on it would be as a "bells-and-whistles" effect for high-end only, it would not currently be a 'replacement' for any existing effect if it does make its way into PRISM.

 

Ah that makes sense!! Thank you!!!

 

Having to pay for an upgrade is not an issue. We value your work and we know that it is not that easy to sit for hours and code. I'l Wait for it for sure!.. Just tell me something please, do you have an expected release date (like 2019 or end 2018)?

 

I am wondering if PRISM auto-exposure would work on mobile... or even for VR?

 

So right now it is too early to give a release date, I can say it's still very early in development at the moment, and if you are using 2017.x still, or even if you've got a project stuck on 5.x, purchasing PRISM now is still your best bet. I am actually migrating a PC project to 2018.1 with PRISM and have not run into any issues so far, but wouldn't recommend PRISM on 2018.x if you only need it for VR right now for reasons listed higher in the thread.

I would certainly like to have at least an internal 3.0 PRISM test ready in 2018, but since I am about to release a new major version/sequel of my game (which uses PRISM, of course) that is first on my checklist.

I've just started this poll, would be great to gain a bit more insight into what platforms PRISM users are currently targeting: https://www.strawpoll.me/16530070

Actually PRISM's auto-exposure method doesn't rely on compute shaders as many others do, so it has a higher chance of at least compiling for mobile, but the issue is you basically need to be on HDR for it to have a proper impact, and the current version is very scene-dependent (doesn't like some scenes).

 

Your poll only lets you select one option.

 

Whoops, fixed with new poll: https://www.strawpoll.me/16536190

 

Just like the Russian elections!

 

So! Over the last 4 weeks I've been working on one of the completely overhauled features for PRISMv3, PRISM.Bokeh. It's a bokeh-supported Depth of Field effect that I have written, basically, from the ground up, for pixel-perfect Depth of Field. Not based on any other implementation (I tried out DICE's DoF, which is just a pain, and very limited in terms of customization), but some cool stuff I've learned from various papers is in there.

The design goals for PRISM.Bokeh were:

• Create a high-end, realistic near & far-field Depth of Field that wouldn't look out of place in a cutscene from games like Tomb Raider or Red Dead Redemption 2
  
• Keep PRISM's current DoF's excellent customisation abilities, including ease-of-blur, blur radii options, and most importantly, ability to control how much bokeh there is!
• Full support for front-field DoF, with "blur-over" - most DoFs fake/miss this, but in a real camera, if something is blurred in your near focal plane, it blurs over the background. This was far and away the hardest part of PRISM.Bokeh to get perfect, but it works fantastically.
  
• Performant enough for standard use with just far-field DoF on, comparable to original PRISM Depth of Field

Spoiler: PRISM.Bokeh Off

Spoiler: PRISM.Bokeh On

Spoiler: PRISM.Bokeh+PRISM On

It is now the first beta-ready revamped feature of PRISMv3 (still tidy-up/platform testing to do).

 

Interesting news!

Back in May, just a few posts up on this page, I asked about the depth blur compability with TAA, which didn't work in v2.

Does this work in v3 by any chance?

 

Hi!
I get this error in 2017.2.0f3 when building my project:

Tried re-importing the project, but no luck. I have had this problem on several other projects as well.

 

For me to make it work. I just had to delete the prism folder then re-import the prism asset and it fixed it.... I don't know if it helps

 

Hi Emile!
I already tried that and it didn't work sadly. Thanks for trying to help though!
Edit: I sometimes manage to get the build to run on the second attempt, but this does not always work and is not exactly a good solution.

 

Will this ever have any implementation with cinemachine?

That's one of the main reasons I'm sticking to post processing stack 2.0 so far is it's integration and being able to have settings per virtual camera.

But i would love a solution more optimized for mobile. Also does your DoF work on webgl?

 

FYI - new PC troubles (I'm now waiting for my 3rd motherboard in 1 month...) so apologies for delay in responses here/on email.

To be honest, haven't had a chance to check out cinemachine but from the looks of it it's very much worth checking out/supporting. I will add it to the roadmap, but as a point of reference, have you tried PRISM w/cinemachine, if so were there any particular issues or just "didn't work at all"?

Are you building for DX9? That error looks to be DX9-only, potentially a shader compiler issue in Unity since that line has a conditional compile to only compile in DX11 or above.
Easiest fix: find the lines
if(_DirtIntensity > 0.0)
and
if(_FlareStrength > 0.0)
Around that line # and just comment them out, and comment out the two #if's before them. You can delete the line:
col.rgb = CombineFlare(uv,col.rgb, dirtVal);
if you're not using flares as well in that case.

So in V3, DoF has been entirely reworked, on release I think it makes total sense for me to QA it against Unity's builtin TAA since that's the one everyone will be using, and if it works w/Unity's TAA it should work with any other 3rd parties'. TLDR: Probably but can't guarantee vs that specific one for launch.

 

I am building for DirectX11. Tried removing the lines of code, but I still get errors.

 

Well technically it can work it's just not integrated.

For instance with post processing stack 2.0 in cinemachine I can set up a different post processing set up per virtual camera. It also supports using the "focus target" of that camera to control the DoF effects distance.

 

Noted. Sounds like something that's hopefully as easy as adding some attributes to functions, PRISM's preset-lerping and focus pulling are super simple so I'll check it out.

Do you mind PMing me with the new errors after you've removed the line that caused the old one and I can try have another look? Also, sometimes Unity's shader compiler will throw out an "error" like that after compilation but still compile successfully and work as intended, since the code is correct. Obviously shouldn't happen but worth checking to see.

 

Hello I have problem with depth of field wiht prism, it is very strange cxause it dont work (work bad way) in forward rendering and defferd too, in deffered I made debug and it can't see forward shader here and cant caluclate depth proper way, so it blurs everything. What is more strange that If I add post processing stack to the same camera s prism, with antualiashin effect or post processing dof, then Prism see all shaders depth in proper way, it need only to post processing stuck to be turned on. Do you have any fix or idea why it is like that?

 

Hey Jakub, I'll DM you for some more info!

 

Just an update here, been waiting to finally get the chance & play around with 2019.x and HDRP as it is obviously the way forward for inbuilt high-end graphics in Unity. In the meantime, tidied up a new really nice noise/dither effect as well as a noise-reduction effect (sounds counter-intuitive - but they work great together to emulate high ISO + NR on a DSLR image or video). Pics soon.

Til then, wondering if anyone else who currently uses PRISM has had a chance to use HDRP + the Postprocessing included in it?

So far I've found:

• No way to extend it at the moment - seems like Unity don't mind if all games made on 2019.1 HDRP look the same

• Bloom is basically just a multi-layered gaussian, exactly the same as Sonic Ether's from back in the day... Which is great if you want to simulate vaseline on a lens:

• No debug settings/views? Can't see how this new HDRP has missed that, big oversight if so IMO.
• Anything color-related they've done very well, something for PRISM to improve on, particularly workflow-wise (as it's all technically possible with PRISM's LUTs but a lot more effort)
• DoF is very nice
• What unity calls a "physical camera" seems to actually mean "film camera" and not DSLR. IE. grain is monochrome, no ISO noise, sensor size doesn't seem to affect DoF at all, no idea how the DoF focuses by default

Anyways, back to the topic of this thread - for anyone who has played around with the new HDRP - what do you think of the new physical camera model? Yay or Nay? Could quite easily replicate it in a future version of PRISM, but it took me a fair amount of time to learn everything in photography, and I can't help but think not every PRISM user is that keen on having to effectively design their own camera+lens per-scene instead of just dragging some easy sliders.

 

I think the new physical camera i s fantastic, especially if you're into Cinematic stuff.

 

Getting these errors when trying to build to android in 2017.3 with Prism v2.4

Thoughts?



Yea so it's basically throwing an error for anything i'm not using, which is odd.

 

Just tried to repro and couldn't in my current 2017 build (which is where most android dev took place) - so would suggest right click>reimport PRISM if you haven't already, DM me if it's still occurring, next steps will probably be to try commenting out the problem line.

 

Hi,

Does PRISM support Unity's dynamic resolution scaling on the platforms where that is supported? i.e. are render textures set up with "useDynamicScale = true" where it makes sense?

Kind Regards,

Kevin

 

@GoGoGadget, Will you update to support unity 2019.1 ?

 

Rendertextures in PRISM v2 don't set that bool specifically when created, but by the same token, all render textures PRISM creates are based off the size of the primary screen render texture - so if PRISM is fed a RT 80% of screen size, for example, then it will "just work" with it. With that said, my primary project doesn't use that feature so I can't for sure say that the current version of PRISM works with it in production, but if it doesn't, I'd be happy to send an update to you with that bool flagged.

Good news! Short answer is yes, working on a REALLY exciting update (exciting enough to use all caps) for 2019.x and beyond, now that Unity has finally reached a point where their post-processing APIs aren't changing every week. 2019.x will be PRISMv3, which will draw upon a lot more photography-inspired techniques and effects, including much more in-depth color controls - I am an manual photographer myself, and I want to get PRISM's color editing to the point where I prefer to use PRISM than lightroom or darktable

Here's a sneak peek at a very simple feature that's already in the primary postprocessing stack, colour temp.

But "what's the point in having an effect that's already in the PostFX stack" you probably ask - very simply, it's better As always, no 2 image effects are created equal. Unity's Color Temp effect in 2019.x, non-HDRP is pretty bad. It's range is "-100 to +100" which defeats the purpose of calling it a color temperature, when it's just a random tint, and worse still, it doesn't preserve lightness - which means it's not a real color temperature. Example below of Unity's current effect:

Neutral scene (Unity) - note the scene brightness (white area in histogram) should stay the same size:


Set to "-100" color temperature, whatever that means - as you can see, not correct:


That's just the tip of the iceberg as well. Very excited to keep working on V3 and bring a beta version within the next 2 months out for people to test! Has taken a bit longer than expected with conversions to hlsl, but will be worth it in the long run.