Minor Improvements to Lensflare Module about three.js HOT 5 OPEN

Let's focus in this issue on the first point. Meaning:

The "bug", so-to-speak, is in the vertex shader for the LensflareElement object. The gl_Position variable uses the z-coordinate of the screenPosition uniform. This means that sometimes the lens flare can be rendered behind objects in the scene, which doesn't really make sense since lens flares are optical effects that occur in the camera or eye.

It's best if you would demonstrate the behavior that you consider as buggy with a live example (https://jsfiddle.net/g3atw6k5/) so it's easier for us to understand what you mean.

from three.js.

Edit: Sorry, didn't realize the link changed:
https://jsfiddle.net/6d05xLrn/34/

The problem should be demonstrated at that jsfiddle link and should be apparent from the initial position values of all the objects. You can simply zoom out to see when the lens flare moves to the front of the scene. In the example I provided, this becomes an issue when using the logarithmic depth buffer for the renderer. Simply changing line 351 of the Lensflare module as I described should fix this. The change to the lens flare element's vertex shader also doesn't appear to cause a problem if NOT using a logarithmic depth buffer from my local testing. I would need to copy and paste all the LensflareElement stuff from the Lensflare module into the jsfiddle to demonstrate that there (which I thought was overkill at the moment).

As for the other issues, simply exposing a property to be able to change the size of the lens flare including ALL of its elements on the fly I think would be a marked improvement in functionality and would require adding only 1 line of code in the constructor (this.flareScale = 1;) and modifying one existing one (Line 251, size = this.flareScale * element.size / viewport.w;).

(this.scale and this.size run into name collision issues)

from three.js.

I have changed the following line by replacing screenPosition.z with -1.0

Right now, I don't understand how using - 1.0 solves any issues. It does not seem right to use a fixed value instead of the real clip space z component.

from three.js.

That's strange. I tested it in the fiddle, too, and experienced the same problem you're facing, but in my personal project it does seem to make the difference. I will try to find out what the difference is between the two and report back.

As for the rationale for having the clip space z-component fixed, a lens flare is a phenomenon that occurs inside the camera/eye, so in real terms the z-component in clip space for any glare/lens flare would be fixed in the camera/eye. The only thing that would get 'rendered' on top of a lens flare is CMOS/film/retinal damage or aberration, any of which would be handled in a post-processing step anyway.

from three.js.

Okay, I seem to have figured out the discrepancy, though I'm still not sure why the discrepancy is happening. When I pull the entire contents of the Lensflare module into the jsfiddle, changing the gl_Position value made a difference for me. When importing from the CDN, it doesn't, though. Maybe it's a caching issue? In any case, you should now be able to switch between the two gl_Position values in the jsfiddle linked to below and see the difference for yourself. The line in question is 355 in the fiddle.

https://jsfiddle.net/0ehac19w/20/

from three.js.