Quick information request: 2D Lights & Sorting Layers

Edit: Update at bottom of thread - this may have been fixed/improved.

I'll try to keep this quick, even though I'd love to ask a lot of questions

The 2D Lights system appears to be doing calculations (creating a "LightMap"?) for every Sorting Layer that a light is targeting. It does this even if there aren't any sprites or anything on that Sorting Layer to get lit.

For organizational purposes in my project, we have been using around 25 Sorting Layers. I wasn't aware that having lots of Sorting Layers would be affecting the lighting performance. We're using lighting with normal-maps, and it looks amazing when we have around 5 or 6 lights in a dark scene. However, the framerate for the project is really suffering, and I'd like to figure out anything I can do to improve it. We're dipping below 100FPS on my reasonably higher-end PC.

I'm hoping to get a little bit of info so I can plan ahead on what to do. So my question is:

Is there currently any plan to change how the lighting system works with Sorting Layers? AKA will it always be the case that the lighting system will be making a separate LightMap for each Sorting Layer that is targeted by any lights? I don't know what is going on behind the scenes with the lighting, but I'm trying to understand the reasoning behind each Sorting Layer having its own LightMap instead of rendering everything into a single one. I assume its something to do with each Light being able to target different Sorting Layers, but it still seems kind of strange (and inefficient?) to me. At the very least shouldn't it be checking if there are even any sprites on the Sorting Layer to be lit? If I place 5 point lights in a completely empty scene that target all of my Sorting Layers, I'm getting 171 batches.

If this is how it is intended to work, and won't be changed, then I can build my project around that. I can combine chunks of my current Sorting Layers into singular Sorting Layers and heavily use "Order in Layer" to sort everything that got combined. If I do that, I could probably manage to go from our current 25 Sorting Layers down to maybe less than 10. It would be very tedious to switch over to this setup, but I can't think of any other solution unless the lighting system itself is changed.

Would love for any info from the devs or anyone that could help, thanks!

 

Bump - I really like the 2D Renderer / 2D Lights systems, and I want to continue using them - just hoping to get a bit more info

 

I was also posting about this issue before. I discovered this when I looked into frame debugger and found that light buffer was being rendered per layer it was affecting it. I mean huge 1920x1080 light buffers per layer!!! That was a real surprise and I had to forget about using any layers at all than just one. I asked about this many times before here and othere threads, but none was answering from Unity about that. So disappointed...

 

Is this limited to Sorting Layer? Is Order in Layer not affected? If unaffected, could a workaround be use large Order offsets, emulating the layers, instead to some extent? Or are there features that only make use of Layer that I'm forgetting?

 

Sorry for late reply, didn't see the notification that you responded to the thread - yes, you can use Order In Layer. Thats why I'm really trying to get a little bit of info from the Unity guys, as to whether or not this "lightmap per layer" is going to be permanent or if they are going to be changing it.

For me to use Order-In-Layer instead of lots of individual Layers would be much more tedious when setting up maps, and less forgiving if I had to make a change to the setup. But its definitely possible, and I would do it if I knew that was the best thing for long term. But If I spend the next couple months setting up my entire game map using Order In Layer, and then they post an update that changes it so we can use basically unlimited Layers, I'm going to be sad that I wasted all of that time

 

Was thinking about it a bit yesterday, and I can see why each Layer would need its own lightmap (the fact each Light can target any number of layers). I don't see that changing, so based on that I've decided I'm going to start figuring out the best way to reduce my number of actual Sorting Layers to the bare minimum, and handle setting & keeping track of order-in-layer ("OIL") instead.

TLDR, I'm going to define OIL ranges for what used to be each of my individual Sorting Layers, and going to create a custom Editor Window that will make setting/nudging the OIL for my Renderers much more manageable. I'll report back on the success/failure of my attempt If anyone else is in the same situation, I'd love to get a convo going.

 

Quick update: I set up a system to purely use Order-In-Layer on a single Sorting Layer. It basically has 3 tiers: level, group, and adjustment - and those are all combined to calculate each Renderer's SortingOrder. I made an Editor Window that lets you select gameobjects and set their level/group/adjustment. Works great.

Switching from having the 2D Lights target ~25 sorting layers, to this new configuration where they only target 3 sorting layers (background, "main layer", and foreground - we need at least a couple layers so that we can have lights target the "main layer" but not the background layer, etc) doubled my FPS. My in-editor FPS was ~80 and is now ~170. Hard to gauge the difference in my standalone build FPS because I can't easily convert old scenes over to the new layering system - but in the quick scene I set up I was getting over 300fps (I had been getting around 100 in a fully fleshed out scene with my old setup).

I'm working on adding more functionality to the Editor Window that I use to control the Order-In-Layer, but I essentially designed it to be similar to how you can select "Sorting Layer" and "Order In Layer" on Renderers. Instead you just select "Level", "Group", and "Adjustment" (adjustment being similar to how Order In Layer would be used normally, to nudge the sorting up/down). If anyone is interested in the code let me know - its a bit specific to my game but would give you a good reference for making your own version.

 

Update: I saw a note in the changelogs that basically mentioned that when rendering a new layer, a new LightMap would only getting generated if the lights that targeted that layer were different than the previous layer. So all of this may have been fixed/improved.

 

Have you had a chance to confirm

Have you had a chance to confirm this yet? I had to bring everything down to a single Default Sorting Layer to make it performant on mobile months ago, and it's now starting to become a nightmare for the busier scenes, without tooling as you made. Being able to bring back multiple layers would be a godsend, but I wont be able to test it for awhile and just curious if you've found anything interesting before I invest time into setting it all back up.

 

Hey Squallio I just tested it real quick and it seems to be "fixed" aka:

So long as the previous Layer that was rendered and the current Layer that is being rendered are affected by the same Lights, then 'nothing extra' is done (aka they use the same lightmap and don't create a new one).

So you still have to be careful with making sure you don't have a bunch of lights that each have their own individual unique Target Sorting Layers. But they definitely fixed a new 'lightmap' being drawn for every single Layer. So if you have X layers and Y lights that affect all of them, the lightmap will only get drawn once.

 

Thanks for your help again, as always.
Spent some time sorting a new scene last night, and I gotta say, it appears to perform better? Image that... haha

 

Hi xiangtingsu! I'm not sure that I 100% understand what you're asking with the first question - I always start by making a prefab of the 'type' of light that I want with it's basic settings (medium radius with a white color, and set its Target Sorting Layers as needed for the prefab's purpose), and then I use that base-light prefab inside of any other prefab that needs a light (like a lantern or something). So if I need to make any changes to all lights of a single 'type', I can just edit the base light prefab for it. Let me know if that answered your question

I haven't had any difficulty with configuring the lights themselves, and feel that setting them up and making changes to them seems pretty good and straightforward.

If you're looking for any type of feedback, I would say my main request would be that the "Use Normal Map" functionality seems a bit strange. It seems like when you select Use Normal Map, that the light is converted into a 3D light source.
1) If you have a light that does not have Use Normal Map selected, and you set its Inner Radius and Outer Radius to the same number, the light is uniform brightness all the way across:



But if you turn on Use Normal Map then it has some built-in "falloff" towards the edge:



And if you turn up the Distance, it slowly returns to the original "uniform brightness" all the way across. One major problem with this is that the Normal Maps are more noticeable (in a desired way) when the Distance value is low. But when the Distance value is low, you get a dimmer light with a lot of that built-in "falloff" that you can't control. And so you have to crank up the Intensity well above 1, etc, to try to make it work.



2) Moving a light, with Use Normal Map selected, along the Z axis affects the brightness of the light (as though you were moving it closer or further away from the surface).

3) Rotating a sprite on the X/Y axis causes the light to fall on the sprite as though it was in 3D-space (already submitted a bug report for this and it seems like it's being looked into https://issuetracker.unity3d.com/is...g-normal-map-and-sorting-layer-is-not-default)

By the way, I appreciate your inquiry and would be more than happy to give any more feedback This is the game we're working on in case it helps to know the context of the 2D Lights usage: https://perennialordergame.com/ It's more on the high-detail/resolution side of the spectrum (not a mobile game, not pixel-art).