Small contribution. Lens flare effect that JME lacked. It is a target-based effect which means that it requires a model to track position. Because of this it cannot be used for model-less sun effects displayed on skybox. There is a much simpler lightmap based Lens Flare for that written by t0neg0d here:
but I am not a great fan of such effects because they are essentially beyond control. Lightmap-based effects are pure postprocessing effects which aren’t aware of the environment. Target based lens flare is more complicated as it needs a geometry on the screen to track. It uses raycasting for this. With this method you apply lens flare on things that not necessarily are bright and remain full control over the effect.
The effect is built as a state. It should be backed by a BloomFilter outside of the lib. In the test I used the core bloom, but it’s kinda crappy. I recommend using MipmapsBloom from ShaderBlowEx lib. Bloom effect hides deficiencies of the effect i.e when the model’s origin point gets occluded and raycasting says it’s hidden while almost half of it is still visible. It doesn’t matter with fast-paced games but if you are moving slowly you can tell the difference.
Features:
Target based - tracks specific model.
Fake bloom - adds fake glow on top of the target.
Anamorphism - vertical light distortion.
Streaks - sun rays - two types- regular and advanced.
@polinc I decided to use your code in my game. It looks good until I resize the window. When I do your filter stretches the scene instead of taking account for the window resize. Add the following code to the end of your simpleInitApp() method of your test program. Then run the test program and resize the window and watch your filter stretch the whole scene.
Display.setResizable(true);
setPauseOnLostFocus(false);
getFlyByCamera().setDragToRotate(true);
// Get rid of the default close mapping in InputManager
if(inputManager.hasMapping(INPUT_MAPPING_EXIT))
{
inputManager.deleteMapping(INPUT_MAPPING_EXIT);
}
It seems like I found the problem. It’s not the BetterLenseFlare code. It’s the FilterPostProcessor code in the 3.3.2 stable release. in the reshape(ViewPort vp, int w, int h) method on line 446 it calls cam.resize(w, h, false). This reshapes the camera but does not reset the aspect ratio so if I reshape the window from a square to a rectangle the camera is totally stretched. @sgold I don’t know if you are the correct person to look at this potential bug.
Not a problem. I just overloaded the method when I instantiate the FilterPostProcessor in my code, call the super method and then call cam.resize(w, h, true). I am good for now. I just wanted to let you know about this loose end so you don’t loose track of it
