Cinematic Image Effects (Pre Release) package

The depth of field effect doesn't seem to be working as I saw on the presentation - in the video it looked as though it was actually blurring objects based on their distance from the camera, rather than just having 2 planes overlaying the screen?

Am I being dumb or am I missing something?

Thanks in advance

 

There was no error in shader, but reimport helped thanks Tim

 

Open ScreenSpaceReflection.shader,
find this line: " if (csPosition.z < -100.0 || smoothness == 0.0) {"
change -100.0 to whatever you need. Tested with -300.0 - works fine.

 

Did distance limit affect performance? if not might be better to adjust it based on far clip

 

Just did a very quick test with -25.0, -250.0, -2500.0... didn't see any noticeable impact.

 

Nice information, thanks for testing it out.

 

Distance limit is to prevent visual artefacts, not performance, it's a screen space effect.

 

Quick q. is there any intention for SSRR to work on WebGL?

 

I get the feeling that may not happen until WebGL 2.0 has more browser support.

 

Hello, I am working on a stereographic camera setup and I have noticed the Screen Space Reflections aren't working if the camera frustum isn't symetrical: the reflections stay as the frustum never changed.
This is very important for 3D and VR.
Use this script to test it, simply put it on the camera with the Screen Space Reflections effect:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. [ExecuteInEditMode]
5. public class FrustumModifier : MonoBehaviour {
6.  
7.     [Range(-1f,1f)]
8.     public float horizontal = 0f;
9.     [Range(-1f,1f)]
10.     public float vertical = 0f;
11.  
12.     // Use this for initialization
13.     void Start () {
14.  
15.     }
16.  
17.     // Update is called once per frame
18.     void Update () {
19.         Matrix4x4 matr = GetComponent<Camera>().projectionMatrix;
20.         matr[0,2] = horizontal;
21.         matr[1,2] = vertical;
22.         GetComponent<Camera>().projectionMatrix = matr;
23.     }
24. }
25.  

I'm using the concepts from here:
http://docs.unity3d.com/Manual/ObliqueFrustum.html


This is what happens:

 

I love you guys

 

Hey,

I did some small modifications to the SMAA package to get the temporal AA to work better. The problem in the temporal solution is that the ghosting is just incredibly bad. So bad that it's practically impossible to use at all.

What I did is that I hacked in a slightly modified version of neighbourhood clamping from Tiago Sousa's Graphics Gems presentation.

This is from SMAA.cginc around line 1390 (I'm still using an older version of the repo, so the lines might be different):

Code (CSharp):

1.     // Blend the pixels according to the calculated weight:
2.     //return lerp(current, previous, weight);
3.  
4.     // Neighbour clamp
5.     float4 n0 = SMAASampleOffset(currentColorTex, texcoord, float2(-1, -1));
6.     float4 n1 = SMAASampleOffset(currentColorTex, texcoord, float2(+1, -1));
7.     float4 n2 = SMAASampleOffset(currentColorTex, texcoord, float2(-1, +1));
8.     float4 n3 = SMAASampleOffset(currentColorTex, texcoord, float2(+1, +1));
9.     float4 cmax = max(n0, max(n1, max(n2, n3)));
10.     float4 cmin = min(n0, min(n1, min(n2, n3)));
11.     float4 avg = 0.25 * (n0+n1+n2+n3);
12.     float4 wk = abs(avg - current);
13.     float blend = saturate(lerp(0.35, 0.85, wk));
14.  
15.     // Clamp previous to neighbours colors
16.     float4 previousClamped = clamp(previous, cmin, cmax);
17.  
18.     float4 color = lerp(lerp(current, previousClamped, 0.5*weight), previousClamped, weight);
19.     return color;

Also to get a better accumulation information I did the following change to AntiAliasing.cs (around line 459):

Code (CSharp):

1.     //Graphics.Blit(rt1, m_Accumulation);
2.     Graphics.Blit(destination, m_Accumulation);

The end result is that the ghosting artifacts are minimal, even without any object specific velocity buffers. The game we're working on, P.O.L.L.E.N (http://pollengame.com), does quite many drawcalls and we really cannot afford to render all the moving objects twice. We also have loads of animated textures and post processing and these are impossible to work around with velocity buffers. I'm very satisfied with the results and it's clearly an improvement in quality over the non-temporal SMAA. The biggest downside is that sometimes some pixels might flicker even when the camera is static. I think it would be possible to get rid of this by tweaking the values a bit or having a better accumulation buffer, but I'm unfortunately too busy with our schedule to do any more improvements before our launch.

I don't know how this compares to Playdead's temporal SMAA (https://github.com/playdeadgames/temporal), but it seems that they are heavily relying on velocity buffers to reduce ghosting. I suspect it's overall a better implementation though

Anyway just wanted to share this back to community, as someone might find it useful.

Below you can find some cropped screenshots, SMAA vs. TSMAA.



The difference in the cutout floor grill material is quite remarkable.



TSMAA can also smoothen texture surfaces, as it's basically supersampling.



Motion is also handled rather well. There's minor blurring on the texture, but practically no ghosting. And all this without any velocity buffers.



Here the image just looks much cleaner.



Another example of image quality.



TSMAA can even improve texture filtering, even though in this example the contrast suffers a bit.




Diagonals and cutout textures are again resolved much better.


I hope this might be useful for someone. And if you happen to do any improvements feel free to share, I know it's still far from perfect

 

That's looking brilliant, thanks for sharing. Can't wait for the Unity guys to implement this, at the moment the Cinematic Temporal SMAA really is unusable, and as PlayDead have shown, the 'motion buffer problem' is very solveable.

 

emm.... looks... blurry...

 

It indeed has a tendency to blur the image a bit. You can always use a sharpening filter though. The smoothness definitely doesn't fit for all games, I agree with that.

 

God damn. You guys are really pushing Unity in a fantastic direction
I showed that Adam demo to a friend of mine and his response was "What the hell, that's *Unity*? It looks amazing!"
On a side note, to bring up something from earlier in the thread, once all these effects are closer to release ready are you guys going to create a single combined uber shader from them? Or will that task be left to the end user?

 

Tim C: Thanks for your kind words The code definitely could use some cleaning and something should be figured for the shimmering to make it "almost perfect", but IMHO it's definitely much better than the current temporal solution in SMAA repo.

The reason why I dislike velocity buffers and wanted to stay away from them is that they work only for the specific instances where your world is solid and everything can output proper velocity data.

In our game we have lots of post processing effects, texture animations, raymarchers, vertex animations, transparencies etc. For many of those it can be very difficult, or even impossible to calculate the proper velocity vectors. So for our purposes we had to find a solution that works well without velocity buffers. I think what we have here is a rather good general solution which also happens to be very performance friendly (when compared to traditional SMAA). No extra draw calls or buffers - just plug & play

Of course there are limitations - the softened look definitely doesn't fit for all games and action games might encounter more issues regarding ghosting (which still exists even in this, it's just very hard to find out).

That said, I'm anxiously waiting to get my hands on with your TAA code

 

More options the merrier. Thank you all for the great work you're doing. It feels like you guys are team members here in a way

Incredible. What hardware is needed to run TAA with motion vectors (Adam demo) at 60fps? can we see it happening for mid range cards like Radeon 7870 or is it more of a Geforce 980 GTX...

 

That is really great to hear Tim! I was almost dissapointed to see the SMAA because it meant, I thought, that unity wouldn't pursue a TRAA style system which imo is the future direction, but super glad to hear I was wrong! It looks incredible so far. So.. if you don't mind I have a slu of questions ^^

1. I know it's an inherent/unsolved problem, but any new special sauce for transparent objects?
2. Is it using Luma weighting for HDR AA?
3. UE mentions mip biasing to prevent some of the blurring, would require deep engine integration, can we expect this too?
4. What are your thoughts about custom velocity buffer rendering? If for example I wanted to scroll some textures on my material, would I be able to write (MRT?) some UV velocity somewhere?
5. How is this draw call wise? I always figured that for the majority of objects the UV velocity could be figured out from depth + old MVP, or did I figure wrong? Or is this more done in a deferred MRT way anyhow?
6. More of a comment, and I'm sure you're already on it, but it seems that at the moment all the post effects have their own temporal filtering components. I really hope the TRAA will be designed to obsolete all these.


In any case, thanks so much for the update, really exciting! Can't wait for it to hit the bit bucket too

 

Is there a specific reason why "Cinematic Image Effects pre-release" on the Asset Store doesn't get an update?
Also, is 5.3.0 really necessary to use those shaders? Or can I use them in 5.2.2 as well?

 

That new TAA is looking brilliant props to everyone at Unity who worked on it. The first time I saw the Adam demo that was the first thing I noticed - it actually had proper AA, wasn't blurry, etc. Can't wait to have a play around with it, once that's out in the wild, there's very few things holding back Unity in terms of top-of-the-line realtime graphics (as everyone can see from the Adam demo).

 

@Tim C
Any possibility you could find someone to answer my previous question? I think it got lost:

"Is there any plan for WebGL compatible fallbacks? We'd really like to have our WebGL builds match other platforms or it pretty much makes WebGL obsolete."

 

Thanks for the response, the main issue we have at the moment crops up when building for WebGL:

"Shader error in 'HistogramCompute.compute': Current target build platform does not support compute shaders"

This points to the tonemapping effect, which is quite important for us to achieve a consistent look.

At a guess, that error suggests it's just something to do with the editors histogram display, which surely isn't required in an actual build, but I suppose Unity is adding it as a dependency anyway?

 

I guess the expense of the velocity buffer preparation can be mitigated somewhat with making assumptions and omitting objects in the distance from it and so on, as well as it being used for anything remotely temporal? Will we see the feature hit 5.4?

 

Thank you for your replies!

Alright, so it is going to be updated eventually. That's great!

I see. So if I get some of them to run in the 5.2.2 Editor, are they going to work in the iOS / Android / OSX player, too?

 

Can't seem to get the Depth of field working with most of the objects in my scene. I have absolutely zero knowledge of how Depth of Field actually works, but can I get clarified if it works with planes / transparency?

Cheers.

 

Sorry if the question is inappropriate for the topic but since we're talking about rendering capabilities, could you guys explain why is there no support for HDR in Forward?

 

There's no HDR+MSAA for forward or deferred. No MSAA in deferred period because it's super expensive to MSAA deferred, if it's even possible on a particular platform. No HDR+MSAA in forward because it requires deeper integration of tone mapping than Unity has hooks for yet.

 

I wonder if there's any actual value to making forward and deferred consistent because if say you use forward on mobile, then you can still use forward on desktop. Chances are as a port it wouldn't need more than forward either. So is there any real value chasing consistency between forward and deferred?

Seems to me that Unity would better serve us by drifting the two apart to strengthen them individually, for example deferred becomes more integrated in the engine and it's OK if it doesn't match up to forward only.

 

Yeah, that's what I wanted to know. Is it because it'd be troublesome merging the antialiased edges of the objects with the background?

 

The problem with HDR and MSAA is because the values being interpolated can be so extreme. If you have two pixels with a value of 0.5 (127/255) and 1.0 (255/255, the brightest a screen can display) you can blend between these easily (0.75 or 191/255) and get a value that transitions between them nicely. If the two pixels are 0.5 and 4.0 this gets more complicated since the blend between the two is 2.25, well above what the screen can display, and now you don't have a visible transition you just get a hard edge again.

http://theagentd.blogspot.se/2013/01/hdr-inverse-tone-mapping-msaa-resolve.html

 

In the (updated) TonemappingColorGrading script, how do I assign a new LUTexture from the outside? Looks like the lut prop does not take arguments?

Code (csharp):

1.  m_GradingScript.lut = new TonemappingColorGrading.LUTSettings (true,(your tex),1f );

 

...you make impressive videos and lot of events.
but my boss asks me, when the picture will be better in VR? like unreal engine, of cry. I promise him, in version 5.3. Then I say, it will be in 5.4. Now I say, Good news! in 5.5 must! ...maby ...some day. like shadows in large world, or mixed mod. We small company, we dont have much time, and we dont need impressive videos and events. sorry, I'm disappointed

 

A company will fail hard in game development if it does business decisions based on "future features". Make decisions only for features in your hands. This is the wisdom of all successful developers.

 

little render test with the new unity image effects

 

Hi guys !
I just would like to know if there is already a "tutorial" to move from the old DoF from Unity to the new one. I would like to know how to achieve the same result as the previous one. If there is no documentation or what I will just change values randomly as I did before

Thanks !

 

You shouldn't be promising your boss features that are entirely out of your control. If you're not coding them yourselves they're not in your hands. Whatever Unity is doing is not your responsibility since you're not coding for Unity and your boss should be well aware of that.

 

Anyone has this problem? It's look like burn out by light. we are using Unity 5.3.4p1 with Cinematic Effects.

 

Hmm this kind of problem could be avoided if the cinematic effect are only one component and one uber shader, so people can get correct effect order/stack