Developers of LIMBO open sourced their anti-aliasing tech for Unity 5

Source: http://gamasutra.com/view/news/268722/Limbo_dev_opensources_its_Unity_5_antialiasing_tech.php

GitHub: https://github.com/playdeadgames/temporal

 

Really nice. I really wish Unity would take all good MIT or BSD licensed stuff and integrated it with the engine or at least include in standard assets.

 

The post I'm linking below, made today in the Cinematic Image thread probably fits nicely with this very subject, and contains much insight into what Unity themselves are up to on this front. It's rather exciting.

link to post #319 in the cinematic images effect thread

 

Not really because:

1. you can get it regardless from github etc
2. While this solution is very nice and all, it's not suitable for a wide audience.
3. Performance will suffer without native velocity buffer which is en route.
4. Standard assets has to be maintained by Unity. This would be suicide.

Quality > Quantity

 

Not sure why they'd pay someone to take a perfectly fine crisp looking scene and make it blurry. I dunno sometimes I think people are so wrapped uo in graphics stuff they just aren't really thinking clearly..

 

Honestly they both appear a bit blurry to me. At least the second one doesn't have jagged edges too.

 

1. Yes, but the problem is with discoverability. And last time I've checked Asset Store forces prices onto asset developers, this is one of the reasons there is still no good and constantly updated free voxel terrain solution on the AS even though there are several on the Internet.
2. How so? Have you tried it? Because as a matter of fact, I did and it worked nicely.
3. Again, have you tested it? Also keep in mind theoretical performance gains are nothing if both solutions can provide framerates that are in satisfactionary range (60fps+).
4. No, only the parts that are developed by Unity. For included MIT/BSD/PD code not developed by Unity all they have to do is to download newest version from that project's github and whatnot.

 

Would be better if Unity took BSD stuff, improved it and submitted improvements back to original repo.

 

Ha ha! That's funny because the jagged edges are a big part of why the first one looks sharper to me. This stuff is so personal though no right or wrong. I'd rather have things be crisp and clear and others want it to be super smooth and blurred.

 

It's far from impossible to make a TAA solution, the issue is as @hippocoder says when every MS of rendering budget counts having stuff like a velocity buffer really helps.. Well really having shared buffers and anything that causes less passes always helps, we could do with all the post being integrated.

Not to say it won't work for your solution, it's very nice of them to release it.

 

Yeh I like crisp, jaggy's I don't like them all but then to not have them means a compromise on losing overall image detail, and having varying extents of performance loss on AA the solution used. Seems like a whole lotta effort for not much.

I do like camera and lighting effects its just some get overrused, it's like watching the Unity GDC demo'd scene. To me it looked better when all the camera effects got turned off .. I was like that's a nicely detailed and textured environment now that I can finally see it properly without all the added post fx.

The solution to jaggies to me is to just play the game at a higher resolution natively, like 4k ... though until 4k@120hz I'm not interested (then again displayport1.3 does make that reality so maybe not far off)

 

People are free to put free items on asset store. Judging by this thread, "discoverability" is not an issue.

Yes, I tried it before this thread. It is too complex and has a lot of redundancy in the UI and does a lot more things that it shouldn't including motion blur with artefacts (it's perfect for their game, not Unity as a standard assets effect).

Yes. The authors have a Unity source code license and have engine-side velocity buffer. They were just kind enough to release this slower version for the public to learn from and perhaps use. Using skinned meshes will create a fairly big performance hit. Also, mesh copying etc. At engine level, this is redundant, and it should be coming in a future update along with Unity's new Adam demo AA.

It's never going to happen because that would imply the source assets are a) kept relevant and b) kept up to date. There is never, ever a guarantee of that. But you can include it yourself. Standard assets by definition are assets that are guaranteed to work and included as standard. Unity *has* to maintain them, and this is too much work for the vast amount of assets you'd have them do. Again, a wonderful fit for asset store, where coincidentally, you can also get the standard assets...

And I'll be frank, the majority of MIT/BSD/PD code I've seen is very very far from production quality, usually it will be freely available so people can contribute as the author simply doesn't have the commitment full time. Perhaps that's OK for you.

 

I see... Good to know!

 

I just hope that when we get native velocity buffer support that it's exposed really well. There's a lot more stuff you can do with that info than just TAA.

 

You can find the information on the cinematic post thread from @Tim C

 

Except this case is special because
a) It's high profile indie dev putting out their code and
b) They had various major outlets such as Gamasutra tweet about it yesterday. I've learned about it before seeing it here from Gamasutra's article and tweets.

Also I remember about a year or half ago someone wanting to put some high-end voxel solution on asset store that is constantly updated for free and everyone screamed bloody murder about "race to the bottom" and "destroying asset market", then someone responsible for the Asset Store (with UT tag, so no random troll) chimed in that the author, in fact, can't put it for free unless they price it comparatively citing AS policies as a reason. Asset Store price fixing is real, let me tell you that.

 

All the same, your responses should really take account of what Tim C from Unity has said about the implementation Unity themselves have worked on. It's been linked to several times already but here it is again.

link to post #319 in the cinematic images effect thread

 

Fact is, if you want antialiasing on a pixelized graphics display then you MUST have some amount of what you call 'blurring'. Antialiasing is a HACK to try to get around the fact that the pixels aren't small enough, by spreading features across multiple pixels. With really small pixels/high density/retina screens for example antialiasing is much less 'needed' (its effectively a form of super-sampling). What we'd ideally like is super high density screens, that would solve it.

Any way that you try to antialiase an image it will get at least a bit blurred and less crisp. However, what I'd do then is apply a 'sharpen' filter over the whole screen and tweak as desired to try to reclaim some of the crispness? The antialiasing here on the `almost vertical` lines is quite impressive.

 

Let's wait, Unity gurus will bring a fast TAA soon.

 

"what I'd do then is apply a 'sharpen' filter over the whole screen and tweak as desired to try to reclaim some of the crispness? The antialiasing here on the `almost vertical` lines is quite impressive."

Yeah a sharpness filter does help counter the blur of most AA techniques.. but have you noticed how many games that offer AA settings yet no sharpness filter option.. yeh just about all of them.. only one I can think of right now that does have a sharpness setting is Arma3 ... and of course now my own game (todo: add sharpness filter option)

 

Well, not really. "Proper" AA, that's done in hardware with forward rendering, doesn't have the "blurred" look that this does. It only examines polygon edges and leaves textures alone, whereas deferred rendering AA generally blurs the entire screen in some fashion an attempt to get rid of jaggies. Hardware AA adds detail, rather than removing it, since it has access to info that goes beyond the pixels that end up being displayed. Of course you're still limited by the pixel grid, but so far I haven't seen any post-processing AA that can equal hardware AA; all the various clever tweaking is still just an approximation and can't get rid of the blurred look, only diminish it to some extent.

--Eric

 

You gotta ask why CryEngine uses deferred MSAA and nobody else does?! Why even bother with TAA?

 

Because it is better to avoid flickering

 

Just up the sample count, deferred MSAA is pretty heavy and personally I prefer the look of temporal AA as long as the image has been post sharpened.. Looks slightly more "cinematic", but yeah if MSAA is better they could go down that path..

 

Am I the only one who has never seen AA flickering?

 

Unless something has changed on this front, Deferred MSAA only picks geometric edges, while most TAA techniques also smooth out shader aliasing.

Also, it *should* be faster (assuming you pay the cost of the velocity buffer for something else as well).

 

I tried this TemporalAA out in a few scenes. The quality of the AA seems to be quite good and it does cut down or eliminate the flickering in many cases. A direct comparison with Unity's Standard AA effects looks good (as far as the AA is concerned).

The real problem here, as everyone has mentioned, is the unavoidable blurring of the screen. Even closeup details tends to get lost as the pixels are smeared. Sure I saw no AA jaggies, but also couldn't see the detail in normal up-close textures either, and it tended to cause quite a bit of eye strain.

I think I'll stick to the Standard Unity AA effect for now which works 'good enough' for most extreme AA issues.

 

Same for me - at least until the new AA arrives. I suspect the blurring of the Limbo developers technique is perfectly acceptable in a game that is by large flat shaded or minimalist.

 

From what I've seen in this video UE has same problem. I think it's TXAA's 'feature' which makes it

 

Yeah, I can see these being great for VR where you need smoothness at all costs - even a jittery pixel will hurt it. But for most games, FXAA and SMAA are really sharp and nice, for what they are.

 

That sort of aa is good for 'natural' scene with lots of trees and plants and mountains and animals of various sort but looks overly blurred in artificial human environments. Of course the nature of those nature environments would hide a lot of the aliased edges anyway.

 

Hello, I have had a problem with my project and I solved it by exporting a package with all the scenes into a brand new empty project.
I copied the project settings and everything now works fine.
But one thing: this antialiasing solution.
I reached perfection in the other project with this solution, but now for some reason the shaking introduced by the jitter script is not eaten back by the temporal reprojection script.
The obvious result is that if I activate the jitter script, the screen is shaking by 1 pixel the whole time.
Anyone has any idea how this is possible?

Old project: perfection.
Same prefab exported to new project: shaky.
It's out of my comprehension.

I checked all the settings just to be sure, and everything is the same. I tried to reorder the scripts in the camera but no way, and I'm completely out of ideas of what can be causing this.

 

I uploaded two videos: the first shows the old version, working perfectly, the second shows the new version with mangled script connections (or at least this is what I think the problem is).
Please note that the character (thereby included all dependencies) was exported from the old project to the new one as is.
I later tried to modify something to restore the thing but with no success, but as you can see all settings are identical, scripts are the same, everything looks the same, and should be the same. Unity version is the same, PlayMaker version is the same (and shouldn't be involved in the problem, I'd say).
Please help!

https://dl.dropboxusercontent.com/u/858716/SR/bugs/old_good_version.mp4

https://dl.dropboxusercontent.com/u/858716/SR/bugs/new_mangled_version.mp4

 

Solved!
The problem is in how Unity exported the package: it didn't include the noise.cginc file, which is used in one of the shaders.
I had to recover it from the old version of the project.
I took the whole folder from the project and replaced the one in the new project and remade all the connection, works perfectly now.