Scion - Filmic Post Processing

It's a work in progress. The screenshots in this thread are all default Unity. The blacksmith demo really looks great, it's a shame it's so slow (Scion or no Scion, the scene itself).

 

To paraphrase what @Aieth has said on the Jove thread previously, the eventual plan is to extract post-processing from within Jove so that you would use Jove for the core rendering, and Scion for post-processing effects. For now, they are largely separate beasts.

 

Yeah that is correct.


This is really long overdue, but I have finally uploaded a standalone demo. So everyone that is curious, feel free to give it a try! https://dl.dropboxusercontent.com/u/233290703/Scion_1.3_Demo.zip

 

I spend way too much time on just zooming in on stuff. Modified the logic a bit concerning upsampling (border between sharp in focus and blurry depth of field) and I am pretty pleased with the result.

Scion on


Scion off
​

EDIT: And then there was some play time with lens dirt + lens flares. Now back to work!

​

 

@Aieth little suggestion: Grain is usually stronger(or at least more visible) in darker parts of the image. For example, movies, especially in high quality on blue ray show this very well. Take a look at productions like 300 or Terminator Salvation. The blacks are extremly grainy, the medium tones are already much less grainy and the whites almost not at all. I would love to have control about how the brightness of the image affects the graininess.

 

Thanks for the suggestion. Grain is slated for some upgrades for 1.4, I'm gonna start working on that pretty soon. 1.3 is essentially done.

 

Same comment on grain (I believe we chatted about this on skype too) - it's nice to control how grain acts based on brightness because noisy lighter colours are distracting. It does need tweakables... Unity's might have it too.

 

Glad to hear Another thing that is on my whish list is a brightness treshold for bloom. Basically a minimum brighness a pixel has to have, to be added to the final image(maybe even have a control curve of how much each brighness value is added)... I really like the bloom but to fight the washed out, soft look we have to counter act a lot with color correction or reduce the bloom. In some cases I wish to have very strong, wide range bloom and still have contrast in the low mids and lows. Currently it seems like every pixel that is not black will add to bloom. Not sure this is ideal in all cases, as it makes it hard to hide that a blurred image is overlayed with the original image.

Also, can you shed some light on how the fx are chained internally? While i can get great results with Scion, i would be more efficient tweaking the values if i know in which order fx are applied and what kind of blend modes are used.

 

I am really opposed to any sort of thresholding for multiple reasons To begin with it is by definition incompatible with automatic exposure. Do you threshold against the value before exposure or after? If before, darker scenes will have 0 bloom (even the spots that are relatively brighter than the rest of the scene). If after, the bloom amount will vary wildly with the exposure.
The removal of thresholding in the modern pipeline is a step towards how stuff actually works, complexity reduction and predictable results. Bright objects cause bleeding, not arbitrary settings that might break under other conditions.
Doesn't setting the intensity fairly low and the brightness high cause the behavior you are looking for?

The FX chain roughly goes like this:

1. DoF runs first, using the virtual camera result from the previous frame (not noticeable)
2. The source with DoF applied is run through a luma weighted downsample into a half resolution texture
3. A downsampling chain is run max(bloomDownsamples, lensFlareDownsamples) times
4. The virtual camera grabs a low resolution down sampled texture and computes a logarithmic average of it
5. That goes into the virtual camera calculation, with exposure being calculated and under certain modes the values needed to derive the cameras circle of confusion (which is then fed into step 1 next frame)
6. Lens flares grabs its desired texture and does some arbitrary magic to generate something that resembles lens flare (physically based lens flares are far too expensive (e.g 20fps GTX 980))
7. Bloom grabs its smallest texture and runs an upsampling chain, using a sampling pattern that reduces fireflies. It additively blends into the larger textures until it reaches half resolution. This converges to gaussian blur according to the central limit theorem
8. The combination pass is run, applying post effects in this order (where source is the texture with DoF applied)
- Chromatic Aberration
- Interpolate with bloom and lens dirt according to settings and lens dirt textures
- Additively blend lens flares according to lens dirt texture
- Apply vignette and grain
- Apply exposure to the result
- Convert to sRGB and apply color grading
- ???
- Profit

I'm posting this from memory, but I hope I didn't miss anything

 

Profit indeed Thanks a lot for the detailed overview, this definitely helps! I assume tonemapping comes after exposure, right?

I wrote you a PM on this topic...

 

I'm very interested with thresholding myself. Even for more reasons than simply bloom.

Usually sunlight is many thousands of times more powerful than an ordinary lamp. So if a directional light source sun has an intensity of 8 then a lamp on a sidewalk would have an intensity of ~0.001 to be physically plausible. I need to have somewhat plausible values for my project which isn't really game related.

Street under direct sunlight : ~120,000 lux

Street under streetlight : ~22 lux

What workflow do you recommend to deal with this in the best way Aieth?

 

I have a clean scene and after I attached Scion to my camera I get the following: Forward is upside-down, and the Game view-port is really dark in both Deferred and Forward. Does that look right with the default settings?

 

Unfortunately thresholding is incompatible with the way bloom is handled, it literally can't be implemented without screwing up the entire thing. I would have to implement a separate bloom algorithm along with it. I might do it, we'll see how the changes in 1.3 are received.

About the workflow, Unity doesn't have a photometric pipeline and no assets made for Unity are made with that in mind. So the best solution is, unfortunately, just do something until it looks about right.

I am assuming you have MSAA turned on in the quality settings? This causes Unity to disable HDR, and without HDR Scion works poorly. If you do have it off then you can tweak the exposure compensation until your scene is nicely lit (or you can change the tonemapping white point, also affects brightness but in a different way).
The flipped screen should be fixed in the next patch.

 

1.3 has now been submitted to the asset store. Should probably be approved early next week.

 

hello Aieth,

All was working fine with 1.3 until I deselected chromatic aberration.. all turned pink and and it wont allow me to activate the script anymore:

I get this error msg:

Invalid pass number (1) for Graphics.Blit. Material=Hidden/ScionCombinationPass, npasses=1
UnityEngine.Graphics:Blit(Texture, RenderTexture, Material, Int32)
ScionEngine.CombinationPass:Combine(RenderTexture, RenderTexture, PostProcessParameters, VirtualCamera) (at Assets/ADDONS/TOOLS/Scion_1-1/Scripts/CombinationPass.cs:108)
ScionEngine.ScionPostProcesserformPostProcessing(RenderTexture, RenderTexture, PostProcessParameters&) (at Assets/ADDONS/TOOLS/Scion_1-1/ScionPostProcess.cs:421)
ScionEngine.ScionPostProcess:OnRenderImage(RenderTexture, RenderTexture) (at Assets/ADDONS/TOOLS/Scion_1-1/ScionPostProcess.cs:379)
UnityEditor.DockArea:OnGUI()

I've deleted all scion from project and reimported but the problem is still there.

 

Thanks for reporting that!
Could you try reimport the shaders folder? Under ScionPostProcess/Resources/Shaders

 

ok all sorted

Thanks

 

Patch 1.3 is now available on the Asset store!

 

Great work, Aieth!

 

What hippocoder said

 

What julianr said

 

I also support the general sentiment expressed in this thread.

 

Haha thanks everyone. Appreciation means a lot, given how much time and energy I've spent working on it

 

Are you thinking of releasing the asset for mobile in a future?

 

I have considered making a mobile version, but in that case it would be a completely new product. The limitations and expectations are completely different from mobile to desktop, and 90% of Scion does not really make sense for mobile. I am undecided though, I suppose it's gonna depend on how my financial situation works out

 

If you are on the outlook for a niche for a new product, there is no satisfying post antialiasing anywhere to be seen on the store. I am sure i am not the only one who desperately needs good AA. Also, i think since you are more into pushing visuals on the rather performant end of the spectrum i believe it would fit well with scion. Can i preorder?

 

Asset Store description says PC/Mac, but what about Linux? I was under the assumption that if Mac is supported, Linux is basically defacto supported as well since both use OpenGL.

 

You are correct. I stayed away from saying DirectX/OpenGL since that's too technical for some users. Should probably add Linux to the description too

 

Good morning guys... just updated my copy of Scion in my scenes and I LOVE LOVE LOVE the new Depth of Field options especially the manual range...didn't understand it AT ALL, but now I get it focal range and depth range work together... (I use manual range, but I hope to make the camera autofocus the way I want it) but if anyone is using SMAA by @Chman , for some reason I am getting this really nasty rendering error...

No SMAA



SMAA The only way to fix this is turn it off



EDIT: False Alarm ... just had to reset the script... everything is good

 

I'm using SMAA and have no problem with it. Put SMAA after Scion.

 

I fixed it... just needed to reset everything...

What is the EXACT order for Scion? I have been reading that everything should come before it...

 

In my experience, AA should always be the last image effect in the chain.

 

Depends on your needs.
AA before Scion could result in less flickering, but give you leaking pixels instead. If you change the color value of a pixel without modifying it's depth, you've changed the 2D representation of the scene. E.g color can bleed from a foreground pixel to a background one, and the error is then magnified by post processing running on it.
AA after Scion does not suffer from issues like that, but on the other hand it has far less effect on the finished image. Its a trade off between leaking pixels and flickering.

As for the manual range, that's been in Scion for months now

 

It was my first time really using it... didn't understand it at first... but I got it now... I'm making a fighting game and will most likely not use DoF unless it's in a cutscene or my presentations

 

Hi, I'm getting this error if I disable the camera in my scene. What makes it more difficult is that the inspector for the camera turns blank, so I can't change any settings on it or re enable it.

 

Hi @Aieth ,


I bought Scion and it really looks good. I would just like to know if you are looking into implementing some type of Antialias. It could be Temporal Antialias or any sort. This guy created one: http://forum.unity3d.com/threads/temporal-anti-aliasing.312525/ I tested it by downloading the standalone demo he made and it looks good. Right now I'm using SMAA the free one and it is good however, there are still crawling lines in certain angles. The TAA that was developed from the link is actually good. You will just notice the AA issue when moving but I believe that can be somewhat hidden by using motion blur just like what Unreal Engine has. In Unreal Engine's TAA, when you move you'll notice the jagged lines but because of Motion Blur it somewhat hides it (blur) which I think is normal for TAA. Is it possible for Scion to have that feature since you are already implementing most of the important post process why not include TAA? Unity has this AA issue ever since. Hope to hear from you soon. Thanks!

 

Thanks for reporting it, slight oversight. Will fix it for 1.3.1. If you want a hotfix PM me and I'll send you an updated version of the script

Temporal anti aliasing is harder than you think. A lot harder. It's the generation of the motion vector buffer that's the tricky part. It's expensive and hard to implement, and even then it's not compatible with third party stuff. If/when Unity implements a motion vector buffer, I will definitely consider adding my own temporal anti aliasing.

 

Yeah +1 for that. Could accelerate lots of things having a motion buffer at engine level. Surprised its not there. Probably because speed wasn't important or something before.

 

I would love to have a version of Scion built for mobile performance. Would be happy to pay for that separately as a new product. I find the mobile bloom really poor in Unity and I haven't found a good alternative set of image effects for mobile.

 

Scion is great. It feels like one of the missing puzzle pieces for postprocessing bringing Unity5 scenes closer to how it'd look in UE4.

And I like puzzle pieces because you don't have to write them, and I certainly couldn't write this, and can just plug them into your projects more or less.

Shame the only thing Unity seems to be missing now is a TXAA implementation and it doesn't look like it'll be coming too soon.

 

I've been considering it, but that's a whole other can of worms I'm not sure I want to touch

Glad you like it! Agree about the temporal anti aliasing. If only Unity implements a motion vector buffer that's integrated into the engine core, then I will add temporal anti aliasing

 

The only real issue I have with scion is that it's rather dominant, that is, it's not really flexible due to the fact it doesn't use things like threshold or manually controlled settings. This is both good and bad. It's good because anyone can make something gorgeous with scion, but bad if you know the look and behaviour you want.

I also don't think that it should be threshold either, I think that's for another asset or another author. Scion understands clearly what it wants to be.

 

hi is there ssao as well that I'm just not seeing or will be added?

 

There isn't and there isn't much benefit in adding it.

 

What AcidArrow said. SSAO runs in a different stage of the pipeline than post processing does, and there are already several excellent assets on the Asset Store that do SSAO (SE SSAO and SSAO Pro come to mind, though I am sure there are more).

 

Thank you!

 

Hi Aieth!
Scion 1.3 Depth of Field looks great! Just one question:
Is it possible to increase the "depth range" limit (Depth Focus Mode: Manual Range). 50 is not enough for my needs. It's a city scene with 1:1 dimensions and the focal distance is about 225. I would like to set the depth range between 75 and 100 to get a bigger focus area!

 

The "limit" is only a UI limitation, I'll replace the slider with a field for 1.3.1 Although I must ask, are you sure you need a focal range that long? Just because something isn't 100% in focus doesn't mean it goes all blurry, it's a very gradual transition.
In general I recommend to stay away from the focal range as it violates how it works in real life. Instead I recommend using a fixed focal distance and increasing the F number (switch the camera to either manual or aperture priority for this setting).

 

Can you please explain to me how the aperture priority setting works in term of simulating different shutter speeds of a real camera? I know what it does to the look in relation to motion blur when using real cameras but since we don't have motion blur yet I wonder if there really is a difference in the end result between changing shutterspeed and iso number here.

If you wanted to go all out on the simulation aspect, you could implement a setting to scale the grain effect with the iso number like a real camera does in lowlight conditions ^^.

 

Aperture priority has nothing to do with shutter speed. Right now all shutter speed does is act like ISO, as you say. I was planning on doing per object motion blur but there's simply no way of doing it fast enough the way Unity currently works. I will revisit that plan when/if Unity implements a velocity buffer (along with temporal anti aliasing).

Yeah there's a lot of things that can be done It would be very ad-hoc though, simulating what actually causes the grain would be insanely expensive and definitely not worth the cost.