ProFlares - Ultimate Lens Flares for Unity3D [RELEASED]

Even though I likely won't be needing it for a long time, I couldn't resist the big discount
Might just have to make a tiny project so I can put them to use haha.

 

Hi,
I got a problem, I'am surely doing something wrong. I got 3 cameras (player, menue and radar HUD) and I played a lot with layers but I am not able to see any flares. they are invisible in my scene. I tried several setups (create setup, creat setup on selected camera with my main cam). Your demos are working fine but in my complex scene i see no flares...
Can you imagine my failure? Any ideas?

(and flare is connected to ProFlareBatch)

Kind regards!
Tino

 

Just purchased ProFlares, product looks great but am having an issue.

I have a space scene with a ship which has engine emitters where I rig a child gameobject, placing a light, particle FX and a flare. This ship has 3 engine emitters. I have a single follow camera in the scene, which is behind the ship following the ship using a smoothfollow script. 1 unity unity = 1 meter, and the ship's scale is 1:1:1. The ship is a small fighter, approximately 20m x 18m x 26m and traveling at an average speed of approximately 150m/s.

The flares on the engines appear to be bobbing around, although when I randomly pause and examine their transform, their position is always 0,0,0 on their parent, and the parent position to the ship remains constant.

Thanks,

-Tim

 

Thanks and deal..

 

This sounds like you have a more complex than the average setup, if you PM me a example demo of your setup I can take a look and see what might be causing your problem.

David.

This will be more than likely due to something updating the cameras position after the flares position has been calculated. Both update in the LateUpdate part of the monobehavior.

If this is the reason, a simple fix is to modify the script execution order.

First go to Edit -> Project Settings -> Script Execution Order

Then hit the plus icon in the bottom corner of the inspector and add 'ProFlaresBatch'.

Then position it after 'Default Time', If you have any scripts that move the camera already set in this area please make sure 'ProFlaresBatch' is the last in the list.

As the Script Execution Order is part of a projects settings this couldn't be included in the package.

If the problem persists please get back it touch.

Thanks,
David.

 

I resolve al problem! Thanks ProFlares!
Look that Awensome assets at work!

 

David,

Thanks for the feedback. I have implemented your suggestion, added SmoothFollow and made it first item under ScriptExecutionOrder - Default section and then the ProFlaresBatch the very bottom item but am still experiencing the same issue.

I just tried disabling the SmoothFollow script and attaching the camera directly to the ship (with view from behind at (-10, 75, -150) for nice perspective). This gives same behavior with the flares bobbing around.

I can probably create a simple sample scene that demonstrates the issue and send it to you tonight after work, or over the weekend if that is something will help. It certainly does look like an update/late-update issue as you have stated.

Although most all of the steering and AI code is done via coroutines, the ship's movement is done via LateUpdate with the following code:

Code (csharp):

1. transform.Translate(Vector3.forward*currentSpeed*Time.smoothDeltaTime);

I just tried moving this movement code to Update as well, with no changes in behavior.

I have also added the script that contains this movement code into the script execution order, trying it as first as well as last item to execute with no noticeable change in behavior.

Thanks again!

-Tim

 

Hi David,

Looking at your Island Demo, getting ProFlares working in VR is a bit more complex than the above implies, do you have any VR-specific documentation? I'm sure I can figure it out, but I'm not clear on why things are set up the way they are in the demo.

Single camera flares were a doddle though and look awesome, really impressed with the asset so far.

 

Very nice, cant wait to start playing with them too

I have yet to implement Shader Forge and this asset in my game and i think both will make a big impact

 

Awesome looking game! Congrats!

Yes your right I have overlooked setting up the layers for the right and left cameras. This is similar to how I you would setup a single camera like in the video just repeated for each camera.

I will try to make a VR setup video asap.

David.

 

This may have been mentioned before, but just in case: Any scene with ProFlares in it gets constantly set to dirty, so I can't tell if I've actually made a change to it or not if I happened to have forgotten. Also, it creates major problems in collaborative projects when using version control. Judging from how the flares are created in the scene, this may or may not be something that can be easily resolved. But if at all possible it would be great to be able to prevent this. Thanks, and great product!

 

Oh, I had one other question: I've found situations where sometimes the flare geometry gets created in the local space of the flare prefab I've dragged in, meaning if I position the flare source far from the camera, it just shrinks as it recedes from the camera, rather than being drawn right in front of the camera as it is in the demo scenes. What have I done wrong?

 

Okay, I had to switch Pro Flares off in my current Prototype because it caused the Frame Rate to drop by about 30% and more.

which is okayish I guess, as I have 4 cars using about 10 flares each in my scene, with 2 cameras. So there are a lot flares in the scene.

Now, the problem is twofold. I could live with the low performance, if it only affected the scene as long as a lot of the flares are visible. But the Pro Flares Classes show up with around 10-15% CPU Time used in the Profiler even if nothing is in view (I did switch on the ray-testing, but an off screen flare and should not raytest if you ask me).
And then there is a very weird behaviour of the pro flares, where the flare classes go haywire from time to time and use up all the CPU for a second or so, showing a huge spike in the profiler. Seems so happen when the two bot cars are out of sight, and very far away from the cameras... maybe because of longer raytesting distances?

Anyway, any Idea what I could try to reduce the overhead? Should I just wait for permonance improvements? Any on the release plan?

Sadly its really hard for me to create a test scene for this...


Regards

Gian-Reto

 

Hi,

If you PM me your invoice number I can send you a beta version of the upcoming update.

David.

 

The ProFlare need collider to be able to occlude properly, this does not work with trees with big leaves. in your example, your trees are cone shape, that's where it works well.

Would it be better to use a shader based, reading the depth depth or zbuffer.

 

Does this fix the unity issues with flares?

I am having this issue: http://forum.unity3d.com/threads/245071-Lens-Flare-quot-Ignore-Layers-quot-not-working

and this issue: http://forum.unity3d.com/threads/175523-Lens-flare-not-ignored-by-culling-mask


Does it perform better than unity flares?

if the above is true, when is the next 50% off sale..

 

This is something I've experimented with and do plan to spend more time on. But nothing to announce yet.

Yep, ProFlares each have their own layer mask allowing you full control over what layers effect them.

ProFlares batches all flares into one draw call, also I'm finalising an update that increases performance significantly.

It was 6 months before the first sale so don't expect anything soon.

David.

 

what about having separate flares for separate cameras? Unity flares are not effected by camera culling. I need separate flares for separate cameras..

When will this new update be done?

 

Yes this would be possible, it may require a little work around but it would work.

Basically ProFlares has a batch node that renders the flares. You can have multiple ProFlareBatches one rendering one set of flares.

This might sound complex if you haven't used it yet but ... The work around would be having the auto connection feature not getting in the way. You could trick it by having two atlaes one for each ProFlareBatch. This would flares bring connected to the wrong flare batch.

 

Hey-- awesome asset! Really loving it. Thank you.

Question-- is it possible to cull based on layer, and not on physics? I'm interested in drawing some stuff on *top* of the flares. Doable?

Thank you!

 

I'm sure I've missed it, but Is there a quick start guide? The read me explained the demo scenes and atlases, but not how to set it up. In the scenes neither the came nor the lights seem to have any scripts attached. I bring the BasicSun prefab into my scene, but now what? Thanks.

 

Apologies for the delayed response, I've not been getting email alerts on this thread for some reason...

It's not currently possible but I have this on the to do list, but I haven't jumped in to deep yet so not sure how difficult it might be.

ProFlares isn't directly linked to lights at all, so you don't necessarily need to have any in your scene for it two work.

I have a quick start video that goes through the basics on how to do the required setup.

http://www.youtube.com/channel/UC5I4rAjOT0JvHLVb-G6dSxQ

Let me know if you require any more help getting started.

David.

 

Update v1.05 is now live!

• Major performance improvements, massively reduced CPU load
• Flare Culling System, Improves performance for scenes with lots of flares.
• Minor Bug Fixes.
• Fixed 4.5 deprecated code warnings.

The core of the ProFlareBatch script has seen some massive performance improvements so just updating ProFlares to v1.05 will see most use cases the CPU time spent reduce by half if not way more, and this is without the culling system.

The new culling system.

The new culling system has been designed to improve CPU performance for scenes that use lots of flares, and a which some of them may go off screen for a period of time.

ProFlares batches all flares that use the same texture into one draw call. It does this by keeping track of all the flares and building them into one mesh. This works great as it doesn't require any allocation per frame. The only down side is that flares that may be offscreen still need processing.

The culling system fixes this overhead. It detects flares that are off screen and removes them from the list. Rebuilding the list is expensive so the culling system tries to do it intelligently. If a flare goes off screen it has a good chance it might come back on screen in the next few seconds. So it will not be culled before a timer has ran making sure its off screen for at least a little while. Culling one flare won’t improve performance enough so its not worth rebuilding the flares list, so the culling system waits until enough flares have been of screen for long enough before rebuilding the flares list.

When a culled flare has become visible again we are forced to rebuild the flares list, but if we delay just slightly we may catch a second or more flares that might be now visible. Then the flares list is only rebuilt once.

Enabling the culling system.

The settings for culling system are found on you ProFlareBatch script. Turn on ‘Use Flare Culling’ to enable it.

‘Cull Flares After Seconds’ : This is the length of time a flare must be of screen before it can be culled.

‘Cull Flares when can cull # Flares’ : When the number of flares that can be culled is equal to or greater than this number. The Flares list is rebuilt and the offscreen flares become culled.


Should culling always be on?

As discussed rebuilding the Flares list does have its cost, so in some cases using culling doesn't make sense. If you only have a small number of flares and they remain mainly on screen, the culling system probably wont save you much CPU time.

If your scene has lots of flares that rapidly go on and off screen, you could get to the point when Flares list is getting rebuilt too often. Experiment with the culling settings so that flares don’t get culled too quickly.

Also each flare under its General Settings, has a ‘Never Cull’ setting. This will make the culling system ignore it.

The ProFlareBatch inspector now displays all flares and there culling state, which is great for culling debugging.

David

 

I keep getting NullReferenceExceptions in various points of ProFlaresBatch in the editor when it's trying to access an element of List<ProFlares> Flares. Once it happens I have to go into proflarebatch and force a refresh.

From the debugger, it appears that the Flare list somehow has managed to contain a null element. For example in this line 371:

Code (CSharp):

1. for(int i2 = 0; i2 < Flares[i].Elements.Count; i2++){

I've updated to the latest version and it still happens. Any ideas?

 

This shouldn't be happening, Do you have any more information on how you trigger the bug? So I can get in there and make sure it doesn't happen in future.

Regards,
David.

 

Looks neat! Waiting for a discount sale

 

Will there be an update to address the shaders running on playstation vita?
The shaders do not work on the Vita using unity3d PSM.
I just get semitransparent pink rectangles...

Thank you

 

Edit, I was out of line! I need to use it a bit more before I judge. Sorry

 

Hi there,
I am pretty sure I am running into a bug with flare angle falloff.
It seems to be using the angle of the camera to the flare to register whether the flare should be turned off or not.
It should be using the flare angle to the camera.
I can prove this by rotating my camera and some flares will turn on and off (while still onscreen), this doesn't make any sense for that to happen. It WOULD make sense if the flare were rotated (now this does happen, but in an unpredictable way as far as I can tell, which is why I think it's a bug). I think 'angle cull' should cull from the angle of the flare gameObject to the camera only. Otherwise you will run into scenarios where it is impossible to get the flare to angle cull properly without custom flare collision geometry. Let me know if you would like me to demo.

 

Hi,

Thanks for the bug report. If you have a test case ready please PM it me. As it will help me get the issue fixed faster.

Regards,
David.

 

Hi Everyone,

Version v1.06 is in the works and should be ready soon. Which contains a number of small improvements and bug fixes.

Also I will not be available for support questions, from the 31st of July till August 8th.

Any questions email me, proflaresunity ( at ) gmail.com and I will pick them up as soon as I get back. Please included your invoice number as this allows me to prioritise support.

Thanks for all your support.
Regards,
David.

 

Hi, I am thinking of buying this package, but I have one question in advance. Since I am only using Unity Free, I was wondering if I could make this kind of glow effects you have in your demo only with lights and lens flares, or are there also some post process effects which are unity pro?

Thanks!

 

All the demos contain no Post Effects*. ProFlares is designed with UnityFree in mind.

David.

(*)Accept the web demos that have only post process Anti Aliasing.

 

Having an issue where I'm hiding game objects with flares attached. Pro Flares still has references to these objects but Unity Editor keeps giving me a debug log saying "Shader requires normals". I have to manually click force refresh on ProFlareBatch for these logs to quit coming up. Any idea on how I can go about fixing this? Thanks! Great plugin!

 

Hi,

I can't say I have seen this one during development, Are you certain that it to do with ProFlares? If so could you PM me a demo scene or some simple instructions to recreate the issue and I can take a look.

Thanks,
David.

 

Hi

Be warned, I am still using an older version of Pro Flares, as I have not experimented with it in quite some time.

I have a problem with my Background setup. I use, besides the Skybox, some Background objects, which are set back quite far into the distance. One of them is a sun I try to use a flare for.

The sun currently is 14000 units in the back. My terrain and other foreground objects are 1024 units away max from the center.

I use a double camera setup, one camera for the foreground rendering, one camera as child object of the first one for background rendering (renders before the foreground camera). Background camera is set with clip plane up to 15000 units. And the background objects, including the sun, get rendered just fine.

Background objects are in a special layer so the cams can differentiate them from foreground objects.

Now, I created a flare which I assigned a new layer, Flare Player 1 (I need a special layer here, as I have a multiplayer splitscreen setup).
A Single camera Setup was added to the Background camera, and the Background cam is set as Game Camera.

I had to edit the Editor Scripts of ProFlares to allow me higher scale settings, but that worked fine.

Now to my problem:
As long as the flare is quite close to the camera (inside the max render distance of the Foreground camera), the flare is visible. But as soon as I either push it back in the editor, or I move out of the foreground render distance ingame, the flare gets clipped.

Now, is there any reason why that would happen? Might the Foreground Camera, which is the Background cameras parent, interfere with the render distance setting somehow?
If not, is there any max distance setting somewhere buried in the ProFlare code?


If I should upgrade first to see if that solves my problem: Can I just upgrade my project without removing ProFlares first?


Thanks for any help

Gian-Reto

 

Hi,

It sounds like you don't have the typical setup, if you could PM me a demo scene I will gladly look at it. To see if I can get it working.

Also could you include your Invoice number, this can be found on the email that Unity3D sent you when purchasing ProFlares.

David.

 

No problem, I will prepare an example on friday.

thanks in advance

Gian-Reto

 

Just saw this! Great, I will try it again when I find the time. Might be able to use more flares now in my night scene.


About the problem I reported some days ago: I found the cause while trying to reproduce the problem for the test scene so I could send it to you.

Problem is that the Flare layers seem to be always in the default layer, even though you can change the layer on the flare object itself. The created layers seem to ingore that.

Now, all my objects in the Background of my scene are in the "Background" layer I created. Done this way so they can be picked up by my special background cam. Of course I could switch around and have the default layer be the background layer, but seeing that I will have about 100 times more foreground objects I would not like to do that.

Any easy fix I could do myself to have the flares in the background layer instead of the default one?


Thanks for any help

Gian-Reto

 

I think your talking about the occlusion system, and which layers affect it. On each flare under the occlusion settings, you can select which layers can occlude a flare.

David.

 

No. Sorry, I did not write it clear enough.

I am not talking about occlusion. I am talking about the layer the elements of the flare are drawn in. My flare object is set to be in the "Background" layer, yet I can only see it on a camera if the "Default" layer is selected to be visible for this cameras culling mask.

So I guess the elements of the flare created are placed in the default layer instead of the layer the flare object is set to.

 

No problem,

When you create a new ProFlare setup, its creates a ProFlareCamera and a ProFlareBatch, these by default are setup to be on layer 8. The ProFlareCamera's culling mask is only set to Layer 8. The layer each Flare object is on doesn't matter.

Does your setup differ from this?

David.

 

Okay, now I totally forgot about the batch object that is a child to the cam! Damn!

I set the flareBatch object to the "Background" layer, now everything works as expected. Doing that I found the limitation of my setup... the flares are now below the foreground objects, of course. So I will have to add another cam to just render the flares on top of everything I guess.

Anyway, my problem is solved, thanks a lot!


Gian-Reto

 

Hi, i'm using pro flares for a project but running into a slight issue.
the proflareSetup object is in a prefab that is instantiated at run time, this prefab contains the camera i want the flares to appear on. I then have other prefabs that are also instantiated with pro flare components in them. I get no flares appearing when i run the game, unless i press the Force Refresh on the proFlareBatch element. The prefabs with the flares are instantiated long after the prefab containing the camera, so i'm not sure why the flares don't appear. Is there a way i can force a Refresh while the games running?

 

Hi,

Yes you can just call ForceRefresh on your new ProFlareBatch via C#.

David.

 

Cheers for the quick reply, sorry for the ignorance, but what would be the best way to do that in C#

 

No Probs, when you instantiate your ProFlare Setup cache a reference to the ProFlareBatch script.

Then call,

myProFlareBatch.ForceRefresh();

Should do the trick, Let me know if you have any more issues.

David.

 

I have a quick follow up on my problem from friday, and then a question.

I had to hack the Proflare code yesterday night because in the end, while everything else worked flawlessly with my camera setup now, the raycasting collision system got confused.
It seems, when two Proflare Batches are involved, the collision system somehow gets confused with one of them. One of them seem to register before the other and is then used for some kind of early ïsVisible¨ test.
Both raycasts are done as long as this Batches camera is looking at the flare. As soon as the flare is not visible anymore for this camera, no raycast is done anymore, even if the other batches camera is still looking at the flare.

My solution in the end was to duplicate the flare, make sure each flare is in a different layer, put the batch that should pick it up into the same layer, and then hack the batch code so only flares which share the same layer as the batches GameObject get picked up.

Works flawlessly now for me. Maybe something to bring back into the Proflares main code, as I might not be the only one who wants to use Proflares with a splitscreen setup.


Then on to my question:
You built culling into your system now which is brilliant for me (I guess my mad testscene with more than 50 flares might have conributed to that decision )... but what I read about is a culling of flares not visible.

Now, I am working on racing game, so the biggest gain for me would be to cull the flares which are out of range. Say the flare has a range of 150meters and is on a car in view, that is speeding away. After the flare is not visible anymore because the car got away more than 150meters from the camera, the culling should kick in. Chances are that even if the player tries to close the gap, he will have to spend some time to get closer than 150 meters to the AI car that just got away.

So my question is: Is visibility simply determined by the flare being outside of the camera frustum, or is the range of the flare also being taken into account?
If its not yet, I guess it would be easy (for me) to fix that, as there is already a range test somewhere in the code (to determine how big or small the flare should be because of the distance to the camera), and I just had to wire that to the culling system, right?

The second, maybe even bigger performance gain for my scene would be some kind of instancing for flares. Let me explain my idea in more detail:

My current car setup has the typical Rally car lighting setup with multiple front lights (for my current model its 10 Front lights). So its a lot! But they all share the same facing and the flares can look more or less the same.
The best way to save calculations would be to only calculate the exact placement, and rotation of the flare elements once and then multiply this flare with simple translations to fit all the places where the lights are mounted.

That might not be 100% exact, but instead of 11 flare calculations per car (10 front headlights and a searchlight on top) the amount would go down to 2 plus some simple translation calculations.

Now I am pretty sure this is harder to do, but would it be feasible somehow? Would it bring the massive performance improvements I am imaging?

 

Hello,

I am wondering if there is a way to adjust the size of the geometry of the ball which represents the flare in the scene. I have a lot of them very close together.

Thank you

Geo

 

Hi guys sorry for delay.

Your split screen issue shouldn't be happening I will take another look and see if I can make everything work as expected without having any work arounds.

Flares are already culled by distance.

I'm not sure your optimisation suggestion would actually save much in the way of calculations as all flares are batched so you would still have to modify vertex positions again anyway.

Yes if you open ProFlare.cs you can modify the size in the OnGizmo method.

David.