SE Natural Bloom Dirty Lens

Sonic Ether's Natural Bloom Dirty Lens


I have depreciated this project and made it open-source. https://github.com/sonicether/SE-Natural-Bloom-Dirty-Lens


Sonic Ether's Natural Bloom Dirty Lens is an image effect for Unity Pro that simulates subsurface scattering of light inside of a lens and renders a per-pixel dirty lens effect.

SENBDL is bloom done right--no threshold or brightpass. This image effect makes bright objects stand out in your game by producing very large and perfectly smooth highlights. The best part? The rendering cost is less than the cost of 2 default Unity bloom effects. You would have to stack at least 6 default Unity bloom effects to get a similar and still inferior approximation.

This asset includes 16 high-quality lens dirt textures that specify how light is scattered on the surface of the lens and includes emissive and particle shaders that help emit very bright light for creating brilliant highlights in your game. This effect is energy-conserving, thus, you won't see lens dirt or bloom where there aren't sufficiently bright pixels in view.

 

How does it descide what to bloom ? does it analyse the image for sharp changes in bright colours or does it just look for which objects are lights ? I was wondering whether this would be suitable to create bloom for particle systems ? Is the cost of the effect independent of the complexity of the scene or does it get more expensive to render with lots of particles for example ?

 

Can't say for sure, but I'm assuming it's a screen space effect (so amount of geometry/particles/etc doesn't effect it) that uses brightness to determine what to bloom. Play with the existing bloom filter to get a feel for it, it's likely much the same principle, just better implemented and adds the dirty lens stuff as well.

 

Neither. It can be difficult to explain, but I'll try to explain it this way.

This effect simply "spreads" the input scene's color. In a way, each pixel loses a bit of its own energy and obtains a bit of the surrounding pixels' energy. Imagine a scene wherein all input pixels' luminosity (brightness) are between 0 and 1. We'll consider 0 to be "black", and 1 to be "white" on your display/monitor. Let's say that each pixel loses 2% of its own luminosity and gains 2% of nearby surrounding pixels' luminosity. This will probably be nearly unnoticeable in a scene where its pixels' luminosity are within a range of 0 to 1, because a pixel can only gain a maximum of 0.02 luminosity from its neighbors in this scenario. Now, suppose in the center of this scene, we add some very bright pixels that have a luminosity of 1000. In a scenario like this, any pixels nearby this bright cluster can obtain an additional luminosity of 20 (2% of 1000), which is a very large increase (20x brighter than "white") and should be quite noticeable.

This is how this bloom shader works, and pretty much how bloom works in cameras and in the human eye. Each pixel loses a bit of its own energy, and gains a bit of surrounding pixels' energy. It is always operating on all pixels, regardless of brightness, but by the nature of how it works, it is only noticeable when very bright pixels (much higher than surrounding pixels) are within your scene to spread their energy to other pixels.

Absolutely. You can create bloom with literally anything that is sufficiently bright enough in comparison to other pixels in view. If you consider pixels with 0 luminosity "black", and consider pixels with 1 luminosity "white" in your scene, any pixels that are significantly brighter than 1 will likely cause visible light bleeding into nearby pixels. It doesn't matter whether this comes from bright pixels on a surface due to a bright light source, a bright sprite, an emissive texture, or a particle. Included in this asset are a surface shader and particle shader that have additional "emission gain" properties that will help provide high brightness objects/particles.

This image effect is per-pixel and works on absolutely every pixel in your scene, regardless of source.

This is a simple post-process effect that is completely independent of scene complexity. The only thing it is dependent on is render resolution.



I hope that answers your questions!

 

Great job Sonic Ether!
I'm a Unity Indie-an so I don't use Pro features but the live demo is outstanding.
Keep up the great Unity work.
Truly amazing stuff you are doing with light lens filters (I saw the HQ Bloom thread you did).
I'm so jealous that you topped the Assets Store Front Page!

 

Great stuff! Will be grabbing this very soon.

Hope to see more of your work in the future, your other work looks amazing too.

 

Looks amazing

I dont have Pro yet, but i will buy to support the asset, plus i plan to get Pro soon anyway

Is it possible to add a with/without the effect option in the demo btw ? Would show better how the effect works

 

I'm pretty sure you can just scale them to 0 for the same result.

 

Hey sonicether,

that's a really impressive effect you made there. It runs at a solid 60 fps on our indie game companys Nvidia GeForce GTX 570 machines.
We consider purchasing it since Unitys old BloomAndLensFlares Image Effect probably becomes outdated sooner or later (and you're offering an awesome price-performance ratio )
Could you tell me if it has an integrated masking option via alpha channel, too (to exclude bright objects from blooming)?
BloomAndLensFlares does include that option and it's really useful since our game project takes place in a rather bright environment and we'd like to make only specific objects bloom.

 

Cool project, just checked out the demo. Awesome work.

How is the performance on iphone 4?

 

I will probably add a toggle key that will switch the effect on/off and a key that switches between my image effect and Unity's default bloom.

Only objects that are many times brighter than surrounding objects (or "white" on your monitor at your current exposure level) will cause visible bloom/lens dirt. With the way this effect works, combined with the use of the included "super-bright" emission shader, getting only certain objects to glow should be no problem without the need for a masking system. I know that the demo scene isn't the best example of a typical game environment, but consider the following things. The "glowing" objects are many times brighter than "white" at the current exposure level. The main emissive cube's glowing parts get thousands of times brighter than the surrounding icosahedrons. Since HDR rendering can handle this range of colors, there should be no need for masking, because bloom will be unnoticeable for any colors that are below "white". If you look closely at the demo scene, the icosahedrons themselves basically emit no glow whatsoever (the non-glowing glossy black ones). Adding a masking system would cost additional resources to address a problem that using a proper bloom in the proper way already does.

The included documentation has a section dedicated to describing how to properly use bloom such that you will have total control over what glows in your scene, and how the proper workflow combined with this shader completely eliminates ugly bloom. One of the awesome things about this effect is that it doesn't show itself when it is not wanted like most bloom/lens dirt effects do.

I'm not sure, and I have no way of testing this. You may be able to put together a scene that uses perhaps 2 to 3 default Unity bloom shaders on the main camera and see how things run. That may give you an idea of how this effect will run. In my very limited understanding of mobile graphics hardware, usually high quality post process effects don't run too well. If you decide to put together this test scene, please post here and let me know how that went.

 

Oh I see, that sounds impressive. Now I kinda understand better why your demo looks so awesome. I guess the hdr rendering is a big contribution to the look So you mainly control which objects bloom and respectively their intensity by using your "super-bright" emission shader? In that case is is possible to use our own custom shaders to control the bloom as well?

Our current project is highly depentent on a proper shading. We go for a completely texture-less low poly look realized by a set of custom shaders.
For example one of our surface shaders writes the meshs vertex colors to the alpha and emissive slots making it bright in a dark environment and bloom using BloomAndLensFlares.

We'd like to keep that look if we switch to your bloom so could you tell me how (easily) possible it is to make our custom shaders work with your bloom?

I hope what I describe is not too weird since I'm really interested in what can be achieved with your effect. Please take a look at this image. It shows some blooming mushrooms created with the described shader and might show a bit better what kind of look we're going for.

View attachment 97850

 

Is it possible to say how your very very nice looking effect differs from say GlareFX, I do want to get a system either yours of glarefx but would like to know the difference if any. The other one says it is mobile friendly as well, will your system perform on mobile devices or do you plan on adding support if its not there currently?

 

Getting custom shaders to work well with SENBDL is very easy. If you're writing surface shaders, look for something like this:

Code (csharp):

1. void surf (Input IN, inout SurfaceOutput o) {    fixed4 tex = tex2D(_MainTex, IN.uv_MainTex);
2.     fixed4 c = tex * _DiffuseColor;
3.     o.Albedo = c.rgb;
4.     o.Emission = _EmissionColor * (exp(_EmissionGain * 10.0f));
5.     o.Alpha = c.a;
6. }

Line 4 is where the "magic" happens. I simply have multiplied the o.Emission output by a value higher than 1. In this case, I am using a slider that ranges from 0 to 1, and use exp(x * 10) to give a nice exponential curve to the slider so it is easier to tweak. Go ahead and type "exp(x * 10)" into Google if you want to see a graph of that.

All you really have to do is find the appropriate variable to scale up, and you'll get bright objects/shaders.

From what I can see of GlareFX, there are definitely differences. GlareFX "distorts" the source texture (color in your scene) to simulate light reflecting inside various parts of a lens, and then multiplies that result with a dirt texture. It seems to blend additively and thus not conserve energy. It also does not include a bloom effect, from what I can see. SENBDL's main feature is a high quality bloom effect, and adds a "dirty lens" effect as an additional feature and does not distort the incoming light to simulate inner reflections within a lens (that is something I may consider adding in the future). Both effects within it conserve energy (move energy around instead of just creating it magically, which never would happen in the real world). GlareFX probably also uses a "brightpass" or "threshold" which means it encourages a workflow and scene that is not truly HDR and causes hue shifting and improper colors. You would also likely run into situations where you're seeing dirt in a scene where you wouldn't expect it (something that's not very bright causing visible lens dirt).

SENBDL is probably not mobile-friendly. I may consider creating a mobile-friendly version to be included with the asset.

 

There are so many projects on Mobile nowadays.

+1 for Mobile.

 

Had to post here. Sonic Ether, I could kiss you right now. This effect is over-the-moon stunning.

For some background: we've been working with PBR shading in Unity for almost 3 years now, and have had one consistent recurring problem with no obvious solution (until now): the older model of bloom simply doesn't handle the luminescence range of PBR well. Unity's default bloom is fine for 0-4 intensity values, but with a PBR shader one easily gets into the 100s if not 1000s with very smooth materials. This ends up creating what I tend to call the 'sparkle magic' effect where single pixels blow out the bloom and you get these silly looking blurry circles everywhere.

I just tested your natural bloom in several of my testing scenes, and I have to say its just friggin flawless. The atmosphere to the air it creates with high intensities is incredible. The occluding behavior is amazing. I haven't seen any visual artifacts or corner-cases. I'm just beside-myself-happy.

12/10 would buy again

 

Congratulations! I'm glad that your getting the recognition that you deserve! You are one of my inspirations to start doing shading for Unity! I will buy the asset as a form of thanks for all the hard work you do. I don't actually develop games I just make Unity look good.

I wanted to ask you however, what would be the best way to get in contact with you? I understand you are a busy guy, and I know this isn't the best place but I just wanted to get your attention somehow.

I noticed you made volumetric lighting for Minecraft and it inspired me to do the same for Unity. I have the "airlight" and inscatter part of it almost complete, the part I might have needed to ask for help is the raymarching part. But anyways, I'm just really hoping we can briefly chat somehow and have nice discussions about shaders

 

Woa, looks really good!

I have a few questions/hints:

1. The website link you put in the description of the asset (asset store) points to a site that is currently down, so I was desperately looking for a contact email, or a link to this page (that I only found by googling it).
   I suppose other people may be interested as well in having a direct link to this thread easily reachable from the asset store, or a direct email to send private questions/clarifications to.
   
2. The asset doesn't specify if it requires Unity Pro. I suppose it does, but many are going to make you this question if you don't clearly specify so.
   
3. Does it work with HDR on, off, or both? (I suppose HDR on only) In which color space (Linear, Gamma)?
   
4. How does it perform in outdoor enviroments? Could you please add another demo with a simple outdoor scenery (terrain, grass, sun, trees) to better evaluate the product?
   
5. Are you going to add more functionality to this asset to include lens flares (or sort of lens flares)? Some other plugins around do mix lens dirt with lens flares, obtaining a smooth mix of both (lens flare distorted or spread within the dirt, eg: GlareFX)
   I'm talking in particular about other types of bloom, such as the included one in Unity Pro, which does "ghosting" or "streaks". Do you have any plans to add your version of them?
   
6. For some reason I see this plugin getting along well with HDR, lens glare and Tone Mapping - Are you considering to mix these effects altogether in some more advanced filter (maybe a separate one in the same asset, so that people can choose functionalities over speed)?
   
7. Are you going to provide support to the asset at least to Unity version 5?
   
8. I still haven't bought the asset, but judging by the fact it's your first asset in the store: could you please promise us you'll be developing more Post Process FX at this quality level (while still keeping some love for this first one)?
   (like, neat looking, fast, volumetric, maybe directional, light shafts? SSAO Variants? *hint* *hint*)

Thanks for your time

 

Just to let you know at present this doesn't appear to work correctly with mobile. In opengles 2 it doesn't error compiling but just displays a black screen,

If compiled to opengles 3 it works but constantly flickers between a black screen and displaying the correct colours. It also appears to be darker than it should and the screen goes completely black in the example scene when the pulsing light are quite dark. Are you using a linear function that the mobile devices don't like or something ? If so you should create a separate mobile shader and emulate the linear lighting functions in the same way go linear does to make it compatible.

Strangely it appears to work perfectly on vita which I think only has opengles 2 hardware. I think the vita emulates linear functions automatically so that might be why.

Also would it be possible to add an option to run the image effect at a lower resolution on low end devices to improve performance.Have an option to make it add the bloom at half the resolution of the screen for example. Just a thought

 

I really love this asset. The quality is amazing.
Here are some screenshots of what i achieved with this





Do you have any more assets of this quality planned for the future?

Edit: Probably way too much lens dirtiness on the first two screenshots :/

 

I'm interested in this asset but one of the reviews on the store brings up some points of concern for me.

I already have HDR enabled on my cameras, so no issue there. But they mentioned you need to apply a special shader to whatever you desire to have bloom? Is this correct? I was sort of hoping it would work similarly to Unity's bloom effect where it just sits on top of the camera and takes care of things on it's own.

Doing it the other way may mean I'd have to modify all my shaders to support it, which may be a bit of an annoying task.

By the way, this is on a project with no PBR, all normal shaders.

 

It is an image effect, and does work similarly to Unity's bloom. But it looks for some really high values that most shaders don't output (which is why it requires HDR, since LDR can't hold those values). You could modify existing shaders to output higher values. Currently it includes two shaders, an EmissiveTextured shader and a ParticlesAdditive shader. Just using those two, it's easy to make a lot of things bloom very nicely. But if you want to modify custom shaders, just cranking the emissive WAY up will make it work. See his post on page one on one easy way to do it.

 

Something everyone should be aware of. Unity has some _major_ buffer precision issues with super high values. Mixing super high luminances with either normal maps or grab-passes (for translucent distortion effects) will produce NaNs. We've clamped the internals of our shader's output at 100 to prevent these from happening. Just FYI

 

Our suspicion was that it was related to the crunched normal buffer (their are other artifacts related to PBR shading that we've dealt with that relate to the normal buffer's precision). As was mentioned earlier, Unity is really only kinda-sorta an HDR engine. I've lost count of the corner-case lighting/shading issues I've run into..

 

I was also quite interested until I saw the comments in that review.

Would be great if the author could post up a little video tutorial of exactly what's involved in getting the asset working?

The results definitely look great

 

I'm using alloy shaders. Alloy guys - Did you have to modify your shaders to get this to work? I see your screenshots and want to get this but don't want to waste another 20 bucks on the asset store on something I cant figure out in less than 2 hours...

 

It seems as though there is a lot of confusion going on regarding this effect. Let me clear things up.

Guys, this is still a bloom shader. If you're familiar with how to use any standard bloom shader, you're pretty much familiar with how to use this effect. Granted that your scene has enough range of brightness within it, all you have to do is slap this effect on the main camera and you're set. The included shaders are not necessary, but are only there as an additional helper tool since an HDR workflow can at times be tricky in Unity.

This effect literally works with anything and everything as long as you give it something bright! The brighter something is, the more it'll glow! It extremely easy to use. Here are the steps.

1. Make something bright.
2. Put SENBDL on your camera.
3. Profit

The included shaders take care of step 1 for you, but if you want to use your own shaders and modify them to output brighter colors, it's simple. Open the shader, find the value that needs to be brighter (usually "o.Emission" inside "void surf" for surface shaders) and multiply them by a value higher than 1. Go check out the Unity Shader Reference if you need help with basic syntax of surface shaders.

If you're using physically based shaders, you probably won't have to work as hard to get a wide range of brightness on specular reflections because of the energy-conserving nature of the shaders themselves.

If you need bright lights or particles, just use the included shaders. They've got an easy "emission gain" slider that boosts brightness as much as you might need.

We're all game developers here, right? I'm sure you guys have come across many many obstacles that stood in your way on the path to creating the game you're dreaming of, and I can say with confidence that I don't think that SENBDL will be an obstacle that will cause any trouble for anyone with patience enough to understand the importance of HDR lighting.

 

I think most of us were just worried about the review on the asset store. (Or at least that was what caused my concern.) I've now purchased the asset and am glad that I did. Looks great and works well for me. Thanks for the asset.

 

This...

 

I think those of us concerned were mostly checking our bases. It isn't uncommon for people to put stuff out on the Asset Store that looks great in pictures/demos but is a huge pain to implement into your project properly. Glad to know that isn't the case here.

 

Thanks for the more detailed explanation of how it works.

In this day in age, it would be nice to have a demo version with a water mark in order to try out the product. This way, more people could test out the asset on various devices. This is a great way to find out the performance on many devices. Demo version = Free beta testing.

 

I'm very interesting in buying this, as it looks absolutely gorgeous. However, not working on mobile is an absolute dealbreaker for me. I'm not even especially worried about performance (we're primarily going to be deploying this on modern iPads that are completely controlled by us, so it's not like it needs to work perfectly on a broad range of hardware), it just has to work.

If a mobile-friendly version is developed (or if I can assist with testing to make one happen, or whatever), please message me.

 

I can't seem to make this thing look right. It seems to wash everything out gray indiscriminately. Blacks get totally washed even if there isn't much bright in the scene. The brighter I push my sky, the more gray it gets. I'd think turning my skybox intensity up to 16 and my sun up to 8 would make my scene go white (that's what happens in other HDR and bloom setups I've use) but this one just keeps getting grayer! I'm using deferred and linear. Could some (perhaps Sonic Ether) explain what's going on? I've attached a screenshot from my game comparing Unity's default bloom with this one.

 

Since bloom is an effect of the lens and/or atmosphere, the "graying" is what one would expect as light leaks to contaminate its surroundings. This lowering of the contrast is the light energy balancing out.

It looks good and right to me vs. the Unity bloom which looks unnatural. Of course if you prefer the high-contrast look, but want to use this bloom for some other reason, then maybe add a contrast enhancement effect on top.

 

Oh I'm surprised you like the soft one better. There are certain qualities I like about the effect, but I can't help but feel I must be doing something wrong. A bit of lost contrast is one thing but this graying is bringing my deepest blacks up to around 20 or so and that's even with extra black crushing the the post processing. I suppose what's confusing me is that it never comes close to blowing out my scene even with a sky intensity of 16. I've also noticed that this gray wash never goes away even with very low light values. At the point that I've reduced the effect enough to prevent washing out my scene I've also lost any trace of blooming that might have been.

 

yeah, I have to agree with nsxdavid on this one ... I definitely like the top one better - looks much more realistic. In "real life" nothing is 100% black or 100% white ... just by the nature of how our eyes work

 

Instant coolness. Well done!

I have not seen many projects which implement the light source bloom realistically. Most of them make a light source appear like a painted piece of fluffy cotton. But yours actually appears very bright to the eye. Next test, to see if the bloom (not the dirty lens) is usable for VR.

 

I am having problems getting it to work from scratch. I get this message:
"The camera is either not HDR enabled or there is an image effect before this one that converts from HDR to LDR. This image effect is dependant an HDR input to function properly."
But the camera is set to HDR and there are no other image effects (clean scene).

Steps to reproduce:
-Start a new project.
-Import SE Natural Bloom Dirty Lens Version: 1.011 from the asset store.
-Go to Edit -> Project Settings -> Player
-Set Color space to Linear
-Enable HDR on the main camera
-On the main camera, click Add Component -> Image Effects -> Sonic Ether -> SE Natural Bloom Dirty Lens.
-The error message pops up on the Inspector.

Edit:
I noticed that switching to Game view, then back to Scene view gets rid of the error message.
Perhaps you can fix this?

 

did it work in VR? thats what Im interested in as well... does the dirty lens have an offset value so we can push it in VR?

 

I didn't test it yet. I have an DK1 (DK2 on order) but I blew up my PC video card and my laptop isn't up to scratch. Will let someone else try and post the results.

 

I picked it up and im using in in my Dk1, applied it to both cameras with the exact same values... The bloom works very well, looks fantastic! I havent tweaked any shader values. The dirty lens doesn't work, we need an offset value for each camera, so we can decide where it sits in space.

 

Hey SonicEther,

I bought the asset this afternoon and was playing around with it. I'm using Unity's color correction in my game and noticed an issue, I think.

It seems as if the effect doesn't play nice with Unity's color correction effect. The bloom sort of gets very muted and almost looks like it gets "capped" at a certain brightness whenever the color correction is on. Here's some screenshots to show what I mean:



The brighter image shows no color correction. The darker image shows the effect with color correction.

I'm using the emissive shader that comes with the package for those lights. If I turn off color correction and turn the slider all the way up on the shader, it gets VERY VERY bright as I would expect. If I do the same but turn on color correction on my camera, the effect looks as in that screenshot, no matter how high the slider goes.

Any thoughts? Color correction is actually pretty important to the atmosphere of my game.

Edit: A couple of images to show the effect at highest slider value

 

Do you have color correction before SENBDL in the chain of image effects on your camera? That may be the cause of this issue.

 

Is your skybox HDR? It is hard to tell from the screenshots, but it looks as if there's a lot of color clipping in your skybox itself. Could you perhaps post a raw unprocessed screenshot of your skybox?

 

I'll investigate this issue. Thank you for informing me.

For use with VR, I'll add some texture coordinate offset/zoom sliders so you can select where to place the lens dirt plane in 3d space. For now, it may be best to use a different dirt texture for each eye. This will kind of simulate my everyday experience in a way... I wear glasses, but my lenses are slightly corroded, so it's like a permanent lens dirt effect IRL.


EDIT: Sorry for triple-posting... Guess I'm a total n00b.

 

Let me try moving SENBDL to the very top of my camera component stack.

 

If anyone is trying to get it to work in VR, there are a couple of things to note.

-The OVRCameraController prefab has 3 cameras, but only CameraLeft and CameraRight should be modified, NOT the camera on OVRCameraController itself.
-Enable HDR on CameraLeft and CameraRight.
-Add the SENaturalBloomAndDirtyLens script to CameraLeft and CameraRight.
-If you want to adjust the bloom settings, you have to modify both SENaturalBloomAndDirtyLens scripts at the same time. To tweak the bloom values at runtime automatically for both cameras, you can use this script:

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class BloomControl : MonoBehaviour {
6.  
7.     SENaturalBloomAndDirtyLens[] bloomShaders;
8.     private float bloomAmount = 0.04f;
9.     private float lensDirtAmount = 0.3f;
10.     private float deltaTime;
11.  
12.     // Use this for initialization
13.     void Start () {
14.    
15.         bloomShaders = FindObjectsOfType(typeof(SENaturalBloomAndDirtyLens)) as SENaturalBloomAndDirtyLens[];
16.     }
17.    
18.     // Update is called once per frame
19.     void Update () {
20.    
21.         deltaTime = Time.deltaTime / Time.timeScale;
22.         GetInput();
23.         UpdateShaderValues();
24.     }
25.  
26.     void GetInput()
27.     {
28.         if (Input.GetKey(KeyCode.RightArrow))
29.         {
30.             bloomAmount += 0.2f * deltaTime;
31.         }
32.  
33.         if (Input.GetKey(KeyCode.LeftArrow))
34.         {
35.             bloomAmount -= 0.2f * deltaTime;
36.         }
37.  
38.         if (Input.GetKey(KeyCode.UpArrow))
39.         {
40.             lensDirtAmount += 0.4f * deltaTime;
41.         }
42.  
43.         if (Input.GetKey(KeyCode.DownArrow))
44.         {
45.             lensDirtAmount -= 0.4f * deltaTime;
46.         }
47.  
48.         if (Input.GetKey(KeyCode.Period))
49.         {
50.             Time.timeScale += 0.5f * deltaTime;
51.         }
52.  
53.         if (Input.GetKey(KeyCode.Comma))
54.         {
55.             Time.timeScale -= 0.5f * deltaTime;
56.         }
57.  
58.         bloomAmount = Mathf.Clamp(bloomAmount, 0.0f, 0.4f);
59.         lensDirtAmount = Mathf.Clamp(lensDirtAmount, 0.0f, 0.95f);
60.         Time.timeScale = Mathf.Clamp(Time.timeScale, 0.1f, 1.0f);
61.  
62.         if (Input.GetKeyDown(KeyCode.Space))
63.         {
64.             bloomAmount = 0.05f;
65.             lensDirtAmount = 0.1f;
66.             Time.timeScale = 1.0f;
67.         }
68.     }
69.  
70.  
71.     void UpdateShaderValues()
72.     {
73.         foreach(SENaturalBloomAndDirtyLens bloomShader in bloomShaders){
74.  
75.             bloomShader.bloomIntensity = bloomAmount;
76.             bloomShader.lensDirtIntensity = lensDirtAmount;
77.         }
78.     }
79. }
80.  

 

Ok yeah it looks like by moving the effect up the stack, things look as they should.

Thanks!

 

I noticed that semi transparent sprites give artifacts when used as an emission texture.


Edit:
This might have something to do with Unity. Still investigating...

Edit 2:
Pretty sure that artifact is a Unity thing. Not sure how to fix it though.
On a positive note, I noticed that the emissive objects punch through fog, just like real lights do. There are some real hidden treats in this software package!

I made a video to demonstrate this. The object on the left has a vertex lit shader and the one on the right has an emissive shader.

Edit 3:
Unfortunately the emissive lighs are not affected by the custom fog created by this package:
https://www.assetstore.unity3d.com/#/content/11080
Any ideas how to fix this?