Lens Flare Occlusion and Rigidbody Mesh Colliders in Unity 5

How do I occlude lens flares with geometry and not colliders to get pixel perfect lens flare occlusion?

The problem:
Geometry does not block a lens flare. If you have a lens flare and move an object in front of it, the lens flare remains visible. Visible geometry has no inherent property in the rendering engine which blocks line of sight to a flare. A lens flare can only be blocked with a collider.

If you have a simple shape, this is fine. However, if you have a collision mesh that obscures parts of a model in such a way that lens flares placed on it that should be visible, are now inside that collision mesh, that flare will be blocked. To see that lens flare, you would need to fly the camera inside the collision mesh.

The old workaround:
This problem is a big pet peeve of mine, so I had developed a workaround. I use a Mesh Collider on all of my visual models. This "visual hitbox" as I call them, doesn't collide with anything and is used only as a means to perfectly block lens flares based on mesh geometry. I have a separate model with a simple covex Mesh Collider as my "physical hitbox" and all other collision detection that lens flares can go through.

Why that doesn't work anymore:
In Unity 5, non-convex MeshColliders can no longer be used with non-static rigidbodies. This means that now, only the convex, and highly imprecise, mesh collider will block lens flares. Lens flares that were previously visible using my old system are now occluded because the flares are inside the convex physical collision mesh.

Because this is a very visual problem, here's a visual depiction of the problem:

 

Use a compound collider, then it can be either several convex colliders or primitives and act as one.

To create a compound collider (ie several colliders acting as one) is trivial and simple, and not at all slow either - especially if primitives are used.

1. rigidbody on parent.
2. child gameobjects each have a collider without rigidbody.

This is still way faster than a mesh collider.

 

It would cover the general shapes in broad strokes, but still isn't as precise as I think it should be. You would still end up with lens flares being occluded (or not) in places that they shouldn't be because your hitbox won't line up perfectly with the geometry, particularly in convex areas.

This is a really simple model, so it's really not unfeasible for this specific example, but for a more complex model with more details you're looking at really complex and time consuming to build compound colliders. You would need to separate out the geometry in specific ways and end up with a model that's made of a ton of tiny, separate parts.

That Unity relies on colliders rather than visible geometry for lens flare occlusion has been a big pet peeve of mine for years, but up until now I've been able to work around it.

 

The way I've outlined is the *only* way, short of importing your own physics engine and writing dlls for it, or doing raycast-to-mesh code, again doing it all from scratch.

It's not particularly a painful process to use several convex shapes instead of one. You might even be able to find a utility to generate multiple convex shapes for you.

This new behaviour is desirable because it is much higher performance.

 

Hm, that's unfortunate, but thank you.

 

I love finding topics from four years ago that ares still an issue. It almost seems like Lens Flares were written forever and a day ago and they have zero intention of updating them to be supported by the current workflow.

My best guess is the easiest way to accomplish what you want is to write a screen space shader.

 

Oh wow this is a blast from the past.

Yeah, lens flares seem to be a legacy feature that are barely supported and woefully out of date with the current rendering engine(s). E.g. I'm pretty sure they don't support HDR rendering in any way.

When I need lens flares, I make do with either regular post processing bloom, or I write something very simple with old fashioned billboards just ignores any kind of occlusion issues. I try hiding them depending on camera angle, e.g. only show the flare when looking down a flash light, and sometimes that can work, but it's not great.

The post processing stack's bloom has kind of taken the place of the old lens flare system, even though it's not quite the same thing. While it is a low priority in the grand scheme of things, I do wish for some kind of natively supported rewrite for stylized lens flares that can also occlude properly based on geometry. If nothing else, a TrailRenderer/LineRenderer style overhaul to modernize them and make them more robust.

 

Hi Guys, I am having the opposite issue, using a collision mesh, or the model itself, results in lens flare from being obscured along with the source light (the sun), which is not so good with a space scene and a spacecraft with windows. To my knowledge is it nothing to do with the 'glass' texture/material, I use a PNG 32 bit texture, set alpha from the texture Alpha channel, using a Mobile>Particle>Alphablend shader (or any other combination of shaders, none work anyway), I get a glass window complete with smudges and minor scratches which the player can see through even at the Sun, but neither the Sun or its lens flare shows up unless they leave the confines of the collision mesh.

I have tried using a 'Venetian blind' style collision consisting of thin bands, which world to keep the player in, but now the sun and flare show up in the Editor, but still not the scene.

 

Just grabbed this from the Unity Manual Doc:

• Lens Flares are blocked by Colliders
  . A Collider in-between the Flare GameObject and the Camera will hide the Flare, even if the Collider does not have a Mesh Renderer
  . If the in-between Collider is marked as Trigger it will block the flare if and only if Physics.queriesHitTriggers is true.

Sort of begs the question, why?

 

Whether or not the legacy flares were considered visible was done through a raycast from the camera to the sun. The only thing that blocks raycasts is colliders. Visible geometry itself has nothing to do with the occlusion check. It's done this way because it's the simplest thing that can possibly work. There are fancier things that could be done, but lens flares are a very out of date system. They're just as likely to get be completely deprecated and removed in the future than they are to see any updates. We just don't know at this point.

For all of these reasons, I've generally been avoiding using the legacy lens flares in my space scenes/games. I either use post processing bloom, or create a "lens flare" billboard that just renders like any other opaque or transparent geometry.

 

Hi Why485,

The billboard seems the most likely but difficult to attach to the 'sun' in a scene. Maybe attaching the billboard as a component to the Directional Light maybe one option. It will have to be quite large, therefore suitably large resolution.

As lens flares are only associated with refraction into a camera lens and not a real eye, is probably why it hasn't attracted much attention, it is actually an undesirable effect of using lenses, when mimicking the use of a human/animals perspective view., but that's photography. As a photographer and machinamist, I have always used lens flare to add a bit of atmosphere, drama or additional depth to a shot.

 

I have found the solution, ignore the flare options in both the directional light and the Lighting Tab, add a Flare component to the directional light, and add your settings there. Create a layer and call it something like Colliders, add the collider that is blocking the flare to that layer, then back in Directional light, select that same layer in the exclusion drop down list in the flare component.

OFC you are not limited to just adding the flare component to just the directional light, the same solution applies to any light source

 

Perfect solution, thanks

 

Thank you!!