Scion - Filmic Post Processing

Nice hahaha Thanks @hippocoder

 

Coooooooooooooooooooooooooooooooooooooooool

 

Hi,

im trying to use Scion also with Tenkoku weather day/night system.

but when i activate Scion and make Tenkoku dark then the scene is still very shiny.
Even when disable all options for testing

 

Try playing with exposure, day and night will need careful tweaking.

 

Change camera mode to manual. I assume at auto it try to compensate increasing ISO or something.
It would be nice to have option e.g. max iso to use.

 

There is

 

Thanks that was it

 

Hello Everyone,

Just a heads up, I have been working on an extension for Scion where you can create transition zones in your scene.
The tool works with every feature in Scion and provides smooth transitions over specified time periods. I will be submitting it to the Asset Store this week, hopefully available very soon.

You can even take your existing Scion config and save it off as a zone for easy level creation.

Previews:

 

I just added a feature to allow both Color Blending and texture blending for things like Vignette color and Lens Dirt textures. I implemented a new blending shader which will mix between the textures on a render texture, which the blend amount is controlled programatically.

 

Hi everyone

Check my last work made with Scion

 

Can you link further posts to your dedicated asset thread please. Rules are it's one thread per asset. Thanks

(although the existing posts here are fine of course to raise awareness).

 

Yup, Will Do!

 

Hi, I recently updated Unity to 5.3.1 from 5.2.2, and now I receive the following errors in my console:

Assets/ScionPostProcess/Scripts/GUI/ScionWindow.cs(176,36): error CS0117: `System.IO.File' does not contain a definition for `WriteAllBytes'

Assets/ScionPostProcess/Scripts/GUI/ScionWindow.cs(243,36): error CS0117: `System.IO.File' does not contain a definition for `WriteAllBytes'

I've tried downloading and re-importing Scion but no luck. Any clue as to how I can resolve this? (I don't import the Standard Assets from Scion as they conflict with other things in my project).

 

I think this is the same error I've seen people report with Gaia. For some reason in some projects Unity switches the build to WebGL. Try going into your build settings and putting it to Standalone (or whatever build you are building for)... At least I think that is the same error. Looks VERY familiar.

I'm running on 5.3.1 and Scion is working fine for me on my Windows 7 machine.

 

Thanks, that sorted it out!

 

Hi, I get an error on unity 5.4.0b

 

There is an option to clamp the exposure, it's the min max exposure slider

I will look into it, I have yet to try the 5.4 beta.

 

Changing null to "" on the specified line fixes the issue.
- S.

 

Just tried out the Scion demo and had to run in here to scream AMAZING WORK @Aieth!

 

Assets/ScionPostProcess/Scripts/GUI/InspectorAttributes/Editor/InspectorAttributesEditor.cs(341,30): error CS0121: The call is ambiguous between the following methods or properties: `UnityEditor.EditorGUI.Vector4Field(UnityEngine.Rect, UnityEngine.GUIContent, UnityEngine.Vector4)' and `UnityEditor.EditorGUI.Vector4Field(UnityEngine.Rect, string, UnityEngine.Vector4)

I also get this same error in 5.4.0b1. Any help would be greatly appreciated.

 

Changing null to "" on line 341 in "InspectorAttributesEditor.cs" to fix the issue.
- S.

 

Looks cool with SpriteLights as well.

 

Love it !!

 

Hi Aieth,

Thank you for an amazing asset so impressed with what you have achieved!! I have a question will you still be looking at your own SSR implementation and also your own AA method?

 

Doesn't work on WebGL for me in Unity 5.3.1. Is it supported (planned to be supported) on WebGL? Anything I can do to make it work?

 

SSR no, there's little point in it now that Unity has its own SSR. As for AA, I will consider it if Unity implements motion vector support, e.g if Unity does it's own temporal AA (which is under way, though no motion vectors yet). It really depends on the quality of Unity's work though, AA doesn't benefit from integration like many other effects do.

I will look into it and make sure it works on WebGL too. It did run on Webplayer, but I never tried WebGL.

 

Thank you Aieth for taking the time! I just bought your asset best post processing pack on the store! Thank you so much for all the hard work!! Cheers

 

I can confirm version 1.3.1 IS working in Webplayer, and is NOT working WebGL (Unity 5.2.2).
I find a lot of stuff is broken in WebGL, for unknown causes. Does not seem to be a reliable platform in Unity as of yet.

 

Hi everyone,

Just an update on my Scion extension.
I have started a new thread for it here:
http://forum.unity3d.com/threads/new-extension-for-scion.376990/#post-2461008
It was approved and released today.

 

The image would not flip in Unity 5.2, but in 5.3 it does. Using "Skybox" or "Solid Color" does fix it, but that's not an option for me. It is specifically have Depth of Field Active that causes the flip, are you planning on a fix?

 

@Aieth:

First, let me begin by expressing the utmost respect for your efforts to bring top-notch post-production to Unity. Please understand that this point is made with the hopes of realizing a version of Scion that I would personally use in my projects, not to discard the great effort you have already invested in your asset.

I’ve wanted to express my thoughts regarding Scion for a while now, but wanted to consider them carefully before posting.

In short, I’m disappointed by Scion.

This is an unpopular opinion, I know, and from what I can tell, Scion has become one Unity’s must-have assets. Even so, I start every prototype by adding Scion, but as I tweak the prototype’s look, I find myself disabling Scion’s settings one by one until none remain. This is because while I have a use for many of its features, each one has a limitation or a flaw that prevents it from giving me the look I desire.

What follows is my list of lacking features / limitations for each feature:

Grain

• Grain size
  
• Grain softness
  
• Light / mid-tone / dark grain distribution

Vignette

• Blend modes (specifically, “soft light”)

Chromatic Aberration

• Filtering to prevent color banding
• Hard-edge softening
• Contrast threshold control

Bloom

• Brightness threshold control

Lens Flare

• Ghost brightness threshold control
• Halo brightness threshold control

Lens Dirt

• Separation from Lens Flare settings
  
• Contrast / transparency adjustments
  
• Brightness threshold control

Tonemapping – No Issues

Camera Mode

• The presentation of this entire section doesn’t seem to make sense. Higher ISO’s should increase brightness, but also graininess. Lower shutter speeds should increase brightness, but also motion blur. Lower apertures should increase brightness, but also narrow the depth of field (the depth of field would also be affected by focal length and sensor size, in real life).

Exposure Settings – No Issues, only confused by Camera Mode issues

Depth of Field

• Blurring is unnatural
• Brights appear ghosted
• Objects blur the same amount regardless of their distance from the camera

Color Correction

• Ability to fade in/out a single LUT without needing to add a default one (minor issue)

Given the list above, I find myself online using the tonemapping and color correction features, which simply leads me to using other assets altogether.

I have a background in professional art photography, so I know that I’m more particular than many users. I also acknowledge my ignorance of the performance cost of these additional features or changes. Even so, cannot help but feel disappointed to have purchased an asset with so much potential that ultimately lets me down on almost each and every feature.

I would love to discuss this further with you, especially if it might bring these feature versions of Scion.

Regardless, thank you for taking the time to read this post,
and I truly do appreciate all the work that you have already put into making Scion what it is today.

- S.

 

(to clarify my "like" of the above post, I am NOT disappointed by Scion, but most if not all of the features that @S_Darkwell asked for are things that I would like to see as well)

 

I think everyone likes new features

 

Isn't the fact that there is no threshold control the whole point of PBR effects though? SE made this point before I think.

 

Probably a good clarification.

As a clarification of my own, I think Scion is a good product. My disappointment is that in its current form, it's a good product that doesn't (but foreseeably could) meet my needs.

I'm not an expert (and I would say @sonicether probably is), but this would confuse me. Bloom is essentially simulating lens and sensor imperfections that only become noticeable under extremely bright conditions. Even our ocular interpretation of bloom is our eyes' inability to cope with extremely-high dynamic visuals. The argument could be made that there are perfect bloom settings to emulate the human eye (although, there is even some variance there), but lens and sensor limitations have have a far broader range.

Again, this is simply my understanding. I could very well be missing some important factor that renders my above understanding completely useless!

- S.

 

How do you change scion values through code? Trying to get graphic settings running so lower end systems can turn off some post fx that arn't needed.

 

Looks like there's a new overload for Vector4Field and it can't figure out which one to use based on the "null" passed in. Not 100% sure this is right, but for now you can double-click on the error to go to the code, then replace:

Code (csharp):

1. return EditorGUI.Vector4Field(controlPosition, null, value);

with:

Code (csharp):

1.  
2.             GUIContent guiContent = null;
3.             return EditorGUI.Vector4Field(controlPosition, guiContent, value);
4.  

to at least get it to compile.

 

I'm kind of in the same boat. I've bought Colorful FX yesterday in the sale and it seems that some effects have exactly the settings that I'm looking for. E.g. the noise can be adjusted to be less visible in the brighter areas, can either be monochrome or RGB noise, has an option not to be animated, the random seed can be set manually and of course there is a slider for the strength, like in Scion. That's pretty much how I'd wish it was in Scion.
That said, having the noise after the sharpen effect seems to look a tiny bit better so I might be keeping that outside of Scion anyway.

And I'll have to admit that I still haven't learned to get the maximum out of Scion. The lensdirt texture and settings have massive influence on how the end result looks and with some tweaking I just managed to get rid of some of the contrast lowering "blur" effect that I got from it (lensdirt texture needed to be a whole lot darker than I thought and rather grey as well). I'd prefer a slider to adjust the blurriness of the lensdirt separately though.
Imho the package would benefit a great deal from a wider array of bundled lensdirt textures and some professionally tweaked presets that can be easily switched through with a click (separate editor script maybe?). Personally I'm more interested in finer control and new features like anamorphic flares, but for new users getting the package now I think they might benefit more from a selection of presets and other textures. Presets could also help to avoid people being overwhelmed or setting things wrong when new features and finer controls are introduced.

 

I've always seen strange issues with flipping since Unity 5, and nothing I do seems to prevent all the edge cases. I will fix that edge case as well for the next version. It really does not make sense to me why the UV y component would end up inverted depending on what clear flag the camera uses. The literally only difference should be the inclusion of a clear call into the rendering API.

Thanks for all the feedback! I've done my best to address all your points. Looking forward to your response

This has been on the bottom of my todo list for quite some time now. The major issue with both these is keyword count. Scion already uses a fairly large amount of keywords (14), and I have no way of reducing that. I'm sure you know how this works, but I'll fill in any potential gaps for less technical people anyway.
The usage of a keyword means a shader is compiled into different shaders, with different behavior (depending on what you smacked inside each keyword). Think of it as an globally defined if statement with no performance penalty. The difference between a keyword and a global define is that you can change which keyword is active without recompiling. This works well if a gamer wants to turn off say Depth of Field. However, there are some settings where interactivity doesn't really make sense, and all we're after is a performance penalty free way of choosing a setting. Tonemapping is one of those, I highly doubt anyone wants to expose which tonemapping algorithm to use in their games graphics settings.
Unity however lacks a way to do compile time shader defines. They did add a system that works on materials, but a material and a post process effect have very different requirements and it doesn't really apply to this scenario. I've yet to make a decision on this but the options I have are basically

• Real time branching based on uniform booleans

The most flexible approach but it also means you are always paying the cost of a branch. It should be very minimal on modern systems though. I'm leaning towards this option

• Writing my own preprocessor for compile time defines

Was originally planning on taking this approach, but upon closer consideration it is simply not worth the effort. It would take a lot of work on my side, and I'm no longer a college kid with 8 hours a day to kill by implementing everything I come across

• Not implement anything else that requires keywords

The third and most unpopular choice

I'm not sure I understand these points. Bilinear filtering is applied to prevent color banding, the color banding you do see is simply a result of undersampling. You really don't want to up that though, 10 samples per pixel just for chromatic aberration is pretty wasteful.
The other two points you're gonna have to explain

The initial philosophy behind Scion was essentially KISS. In hindsight I took parts of it too far. That's the downside to producing technology used to create products, without actually making the products yourself. You miss use cases and take wrong decisions.

Not sure what you mean by separation from lens flare settings, they are already separate components. The lens flare settings that are under lens dirt determines how the lens dirt affects the lens flare. What do you mean by contrast/transparency adjustments?

The idea behind adopting the real camera values is to make exposure more intuitive and controllable, and I feel fairly confident that it accomplished just that. I don't understand what you mean by this though, every thing you say is already how it works. Higher ISO increases brightness. It doesn't affect grain since that would have to be implemented by a huge approximation and I'm pretty sure I'd have a lot of people being upset that things are happening and they can't control it. Lower shutter speeds do increase brightness, motion blur was not implemented due to lack of motion vector support in Unity. Lower apertures do increase brightness and it also does narrow the depth of field. It is also affected by focal length. Focal length is derived from the cameras field of view, but I implemented a manual override if people want to mess with it and create non realistic settings.

Could you illustrate by screenshots? None of this makes sense to me either, based on your description it sounds like you are using object shaders that do not output depth. The depth of field is definitely affected by an objects distance from the focal plane.
If you see ghosting, turn off temporal supersampling. It can have that effect, but I find its almost always worth the trade off (just look at UE4).

 

Look through ScionPostProcessBase.cs for the variable names. The names in the GUI kind of correlate with the variable names, intensity variable for bloom is named bloomIntensity (to separate it from lensDirtIntensity). Be sure to include the ScionEngine namespace as well. Below is an example on how to activate chromatic aberration on the games main camera.

Code (CSharp):

1. using ScionEngine;
2. public void ActivateChromaticAberration()
3. {
4.             ScionPostProcess scion = Camera.main.GetComponent<ScionPostProcess> ();
5.             scion.chromaticAberration = true;
6.             scion.chromaticAberrationDistortion = 5.0f;
7.             scion.chromaticAberrationIntensity = 10.0f;
8. }

 

To be honest i do feel the dof is pretty good but doesnt represent equivalent f-stops and i cant blow out the focus to the degree i like, you should be getting miniscule depth of field with any real distance being totally unrecognisable when getting to 1.4 or less at close focussing but i cant seem to get that effect. I also have a little experience in photography and would love to see the camera simulation expanded upon as its becoming a big part in my current project

Its mainly dof strength and character i feel where it falls short of particularly realistic but if you could get that working it would be great, maybe at some point a tilt/shift or 'macro simulator'

 

Thank you for taking the time to address each of my points so thoroughly!

While I do consider myself a "technical person", my coding knowledge is primarily focused in C# / PHP, so I greatly appreciate your explanation of keywords and shader compilation. It was both clear, concise, and comprehensive!

I can certainly see the pros and cons of each approach, and understand why this hasn't been at the top of your todo list. Do you have any idea on when you might implement these features (or, what other features must come first)? Of course, I understand the challenging nature of providing timeframes, so I appreciate whatever level of detail you are comfortable providing.

I think the image below may help. This is a new project and a default scene, except for the following:

• Linear color space
• MSAA disabled
• Deferred Rendering
• HDR enabled on camera
• Clear Flags set to "Solid Color" on camera
• Background set to black
  
• Created a cube rotated 45° on the X axis

Filtering to prevent color banding: I'd love to have greater control over the number of samples, even if it must come with a performance disclaimer. In the example above, the banding is rather obvious.

Hard-edge Softening: The rounding of corners the chromatic aberration's corners. You can see at the top of the cube that the edges are quite sharp, which is unnatural for chromatic aberration.

Contrast Threshold Control: Since chromatic aberration occurs at points of high contrast (typically edges, but sometimes in high-contrast patterns), it would be useful to have control over either the point or the curve that controls the application of chromatic aberration. This would be similar to adjusting the quality of the lens or the aperture, as lower quality lenses and lower apertures are more prone to chromatic aberration.

KISS is a fantastic philosophy, and it's certainly better to err on the side of simplicity than complexity. Can I take it that these features are planned for a future update as well?

Apologies. I mean that I would love the ability to have lens dirt that is visible even without lens flare. I like that lens flare effects it, but a very dirty lens will have visible dirt whether or not there is any lens flare.

In addition to your "Lens Flare Brightness" setting under "Lens Dirt", I would love a "Lens Flare Contrast" setting that would increase or decrease its contrast on the lens. I suppose this could also be called "Lens Flare Sharpness". It could have a similar effect to "Lens Flare Effect", in that increasing it would increase the visibility of the lens dirt, except without having an inverse effect on the visibility of the lens flare.

As I mentioned, I come from a photography background, so perhaps I'm overthinking this.

I completely understand why you don't increase the grain when increasing the ISO setting, and why the camera blur isn't included, but it makes having separate ISO and lens speed settings seem pointless. In real life, these affect the aforementioned image properties. In this simplification, they have the exact same effect as each other -- both only control the exposure.

Apologies for not realizing that Scion does take aperture into account when calculating depth of field.

It just all feels very off, though. Apologies for re-stating the point, but it seems more of an over-complication than a simplification to me.

For instance, if Depth of Field is disabled, aperture falls into the same pitfall as I previously mentioned for ISO and shutter speed. It then only effects exposure, so would in that case again be redundant.

Additionally, I agree with @lazygunn -- The aperture doesn't seem to mirror real-work equivalents. Here's a photo illustrating both foreground and background blur for example:


I captured that at 1/400s, f/1.4, ISO 200 at 50mm on a full frame sensor.

While there is some post-production, the background and foreground blur is unchanged. (This photo is also an example of an extremely heavy vignette applied using soft light mixing).

Also, another detail -- On an actual camera, exposure compensation wouldn't affect the exposure on manual mode. Exposure compensation merely affects the measurement of exposure by the camera, thus only affects auto/priority modes.

But, I completely agree that making these settings match real-word equivalents is likely far beyond Scion's scope, but that's also why I feel including ISO, aperture, and shutter speed are a bit misleading.

Let me take a step back, though, and say that this isn't actually particularly important. I'm only offering what I can from my photography knowledge. If most users find it more intuitive than an exposure and depth-of-field slider, then this may all be a moot point. My fear is that this may sound offensive, and that truly is not my intention. With a bit of effort, I'll be able to work with the current system just fine.

Blurring is unnatural
Brights appear ghosted

Here is a series of 1x1x1 cubes as an example. You can see the solid line where the cube is showing sharply through the cube.

I've tried it with and without "Temporal Supersampling." I absolutely agree, it looks better enabled, but it still doesn't resolve the issue. Enabled, it's far smoother, but still looks nothing like actual bokeh.

Objects blur the same amount regardless of their distance from the camera

Actually, I'm failing to re-create this issue. I think it may have been a glitch. However, while attempting to re-create it, I somehow made it so that only a small circle at the center of the screen was visible, and the rest was black. This issue would toggle with the Depth of Field effect (it went away when disabled, re-appeared when enabled). The only way I was able to fix it was to reset Scion to the default settings.

These aren't the first two times that I've experienced strange glitches that were only resolved by resetting Scion. I'm not sure whether that is related to Unity or Scion, though. Also, I realize saying, "Strange glitches! Cannot re-produce!" is rather useless. Apologies!

If it helps, my system specifications are as follows:
OS: Microsoft Windows 10 Enterprise
CPU: AMD FX-9370 Eight-Core Processor, 4415Mhz'
GPU: NVIDIA GeForce GTX980
Memory: 16.0GB

Again, thank you so much for the fantastic support. I think Scion is a great product, I'm just hoping that it is one that will meet my particular needs in coming updates.

Be well!
- S.

 

The only asset on the asset store that I've seen that seems to provide that level of real-world simulation and control is "Cinema Pro Cams - Film Lens & 3D Toolkit". From what I gather, it is high-quality and extremely accurate, but doesn't offer many of the other features of Scion, nor is it nearly as performant.

Hope that helps!
- S.

 

I've already loaded the boat on fps eaters! Need to keep things at 90fps+ on a gtx 970 to meet Oculus 'minumum spec' as advised by Carmack I think, cheers for the heads up though

Also likewise i'll chuck my photography boat in - although its hard to see because the subject fills most the frame



This was f1.4 with the subject about a meter away, the trees were a touch behind her and they're out, even her bag strap is leaving focus, on another photo ive taken that day where the subject is about a foot and a half away only her face is in focus, with her head quickly losing focus and behind very little to recognise at all, but you can't push scion that far

Here's another silly shot i took (the text was post) that shows again the kind of dof i'd like to get at

 

Hi @Aieth ,

Scion works well with Unity's new Cinematic Image Effects

 

I can make the define more easily accessible. If you want to change it right away you can go to the CombinationPass.shader file and change line 20 from "#define CHROMATIC_ABERRATION_SAMPLES 5" to however many samples you want to use.

The thing is, what we use for chromatic aberration in video games has very little, if anything, to do with the real thing. In video games we simply split the 3 color channels and offset them. In real life this occurs due to lens distortions and different light wavelengths. It is simply not possible to accurately simulate chromatic aberration at acceptable frame rates with todays technology.

Same as above, its just a straight up split of color channels. There is no point or curve and I'm not sure if it would be feasible to implement one.

Yes

Isn't it visible with bloom on? It should be

There are some complications with that approach. Contrast as seen in e.g photoshop assumes [0,1] input values. However we are working with HDR values here. So in order to contrast the lens flares we need an average brightness. I previously experimented with contrast tweaking based on the average brightness of the screen, but it is horrible. So the only remaining option is a user specified value, but that breaks down very easily and instead of increasing contrast it ends up forcing the entire thing darker or brighter.

Yeah it kinda is pointless from the users perspective. However, all the algorithms that have been developed for processing camera images all require ISO and shutter speed values. So I had the choice of either hard coding it behind the scenes or presenting it to the user, so I figured why not.

Here is a quick comparison I threw together with and without DoF on


I agree that your white box shot looks horrible. However... Now we're crossing into very technical territory. Bokeh is a uniform blur. It does not follow a normal distribution, every pixel of the kernel contributes equally. Therefore, it cannot use a separable blur. In plain English, the "blur" must be done in a single pass. And if you want to support larger blur sizes, this quickly becomes very unfeasible.
The naive approach with a 20 pixel radius would require 20 * 20 * pi = ~1250 samples. Assuming a 16 bit HDR buffer, full HD resolution and 60fps, we're arriving at a grand total of 1100 gigabyte per second. Way more bandwidth than even the fastest GPUs today have.
So instead we approximate. We do fancy stuff and tricks to try and stretch 25 or 49 samples, and make them representative of 1250 samples. What you are seeing is essentially a worst case scenario, and it will look horrible no matter how you do it. Scion is made with the intention of being useful in games and not for tech demos. As you can see in the above pictures, artifacts are either almost not noticeable (I know where to look ) or disappear completely when faced with complex geometry.

That makes sense Oversight

 

I haven't caught up on the ongoing discussion yet, but I wanted to quickly drop in and ask if anyone is currently tweaking the scion shaders to work on the bloom threshold thing we've talked about?

I'm currently screwing around in CombinationPass.shader in this function:
float3 SampleBloomDirt(float3 clr, float2 screenUV)

@Aieth: Can you tell me if it is sufficient to change some lines in this function or do I need to also change others like "float3 SampleOnlyBloom(float3 clr, float2 screenUV)" ?

Is there anyone else who has been or is currently working on this?
If I come up with something that I think is usefull, I'll share my results here.

 

My progress so far:

http://www.keinebilder.de/temp/screenshot-corridor-1-without-scion.jpg
http://www.keinebilder.de/temp/screenshot-corridor-1-vanilla-scion.jpg
http://www.keinebilder.de/temp/screenshot-corridor-1-customized-scion.jpg

Thoughts?

 

@Aieth:

Firstly, thank you for taking the time to respond to my points so thoroughly. I've observed your forum threads for quite a while, so I'm surprised -- rather, my trust in your excellent customer service is pleasantly re-affirmed. Thank you.

Easy-access is always much appreciated, but I'll admit that I've never actually opened the shaders. As mentioned before, my shader knowledge is limited, so I'm typically disinclined from opening the black box (though, I will now be more inclined to do so in the future).

That's fair.

Disappointing, but I can accept there there are limitations to any approach, and it sounds like chromatic aberration in a highly simplified approximation in general. It would be interesting if it could somehow be tied to bloom. Displaying chromatic aberration only on edges that overlap areas of bloom might actually be a decent approximation of when it could occur (but, I don't even know if there is a way to detect such things).

Nifty!

Oh. It is. My bad. Is it possible for lens dirt to be visible even when no bloom is present? For instance, being able to see it to some degree when a wall is any brighter than 50% gray? This certainly wouldn't always be preferable, but could be useful in certain cases.

Ahh. That makes sense. Attempting to adjust contrast in a scenario where we don't know the upper limit to brightness would be like trying to define a point 50% along an infinite ray. Without two reference points, there is no way to make that determination.

A simplified mode might be nice -- for instance, one that assumed an ISO of 100 or 200 (depending upon if you preferred Canon or Nikon as a reference; I use Nikon myself) might be nice, but I see your logic. At least I could theoretically get a correct exposure using the "Sunny 16 rule" with the current setup!

That is also fair, and makes perfect sense. I often find myself working in such scenarios just because given that many of my games are quite dark, my "graybox levels" often look more like black boxes with light objects. Depth of field is an effect that I haven't made much use of with Scion as-of-yet, but included it here as something I had noticed. I'll be able to comment on it more in actual use scenarios once my projects are further through development.

In defense of Scion, I applied another depth-of-field script that I had been fond of to the same camera, and frankly, Scion was noticeably better quality. So, +1 for Scion there too.

Cool! Found one.

Again, I deeply appreciate your willingness to discuss the limitations of Scion and the challenges of these scenarios in so much depth. In my particular use case, I think I will be satisfied once additional controls for the vignette, grain, and bloom have been added. Everything else is either something to which I can adept, or I only mention here for the purpose of being comprehension.

I hope you have a fantastic day, and I look forward to seeing those features in future updates!
- S.

 

Your example already matches much more closely with my tastes!

- S.