Experimental 2D Lights and Shader Graph support in Universal RP (previously LWRP)

[castor76]

@Ruskul

Yes, we really do,

I have a solution for you (unity’s solution found from a video they released), and an alternative more powerful solution of my own devising:

Currently, you can specify a custom light blend mode and base it on a mask. Basically, if you want an object to flash a particular color in response to a particular light, you can do. The light just has to use one of the blending modes you set up in your 2d renderer asset. The down side to this method is that anything with the same mask, in the same layer, will also respond to the light, meaning you have to use shader graph to create a material that changes its mask on and off. There are still severe limits, for example, if I want to create an emission color instead of using the diffuse map or light color, I can’t.

So, I prefer a clever workaround that kind sucks, but here it is: You can create transparent sprites. When two sprites are alpha blended you get an average of their colors, basically. But what we want is additive blending for the emissive sprite, which can be done with some clever alpha blending.

If you double the intesity of lights and layer up sprites with %50 alpha… when they lerp the result is the same as adding them, had they been lit normally. You have to put the emmisive sprite ontop of the diffuse sprite and each in their own sorting layer, but this way they can be affected by different lights, etc…

Using this method, I currently have a space scene where I have sss, fresnel glow, specular highlights, and emission on all my sprites… with of course 2d lights. The problem is that I need a seperate light and sorting layer for each category, and every sprite object is then layered together, so overdraw is pretty high… but I’m still getting 500fps so, meh, whatever.

This seems too hackish and not flexible enough, not cost effective to just do a simple emission channel…

[castor76]

@Chris_Chu

Secondary textures were actually made with the 2D renderer in mind. The names are specific if you want to use normal maps and mask textures, however if you have your own shader you can use whatever name you want.

There are some docs on using secondary textures here
https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@9.0/manual/SecondaryTextures.html

Can we please have an emission channel on the lighting side so we can add secondary texture for the emission?

[castor76]

@Chris_Chu

Secondary textures were actually made with the 2D renderer in mind. The names are specific if you want to use normal maps and mask textures, however if you have your own shader you can use whatever name you want.

There are some docs on using secondary textures here
https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@9.0/manual/SecondaryTextures.html

Also, does 2DRenderer Tilemap Renderer supports Secondary texture? Or it only works with Sprite Renderer?

[Ruskul]

@castor76

This seems too hackish and not flexible enough, not cost effective to just do a simple emission channel…

Unity’s method isn’t flexible. You are stuck with the colors of the lights, and layering issues arise. My method, is 100% flexible. Objects pretty much have to all be prototypes (which I admit mine are anyway, so the I could bear the cost), but you are right. A simple emission ch would be most lovely.

Objectively, I can’t see why we don’t have it.

[Ruskul]

@Chris_Chu

Secondary textures were actually made with the 2D renderer in mind. The names are specific if you want to use normal maps and mask textures, however if you have your own shader you can use whatever name you want.

There are some docs on using secondary textures here
https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@9.0/manual/SecondaryTextures.html

Unfortunately, using secondary textures and your own shader graph still doesn’t allow for proper emission. In the examples from unity, they use additive light blending, which, if you you have a stack of sprites all needing emission, the lights stack, unless you layer it and light them separately, which is not scalable. For a single object overlapping itself n times, you need n sorting layers.

Take the following example:

I have a bioluminescent plant. It emmits a soft blue glow in spots and has purple subsurface scattering emitting around the glow spots. The diffuse map, however is a grey. If we had an emission ch, I could simply create a secondary texture and plug it in. But as it stands, I have to find a way to add the emission ch color to the diffuse color. But here is the thing. If there is no light shining on the plant, it shouldn’t have any of its diffuse color contributing to the scene.

Unity’s way suggest I create mask ch, set up an additive light to respond to that mask ch. Now, this is fine, if you only have one object contributing an emission map. Here is why. an additive light, will only contribute the color of the light to the scene. This means in order to get a colored emission in a scene with no regular lights, I have to have my additive light set to the color of my emission. This falls apart when I have two objects overlapping that have different emission colors. Which means, I need to either use a multiply light instead of additive (so I can get the color from the shader), or I have to to have n sorting layers (refer to explanation above).

Basically, If I use a multiply light to act only on the emission mask ch, then I have the problem that I can’t calculate how much diffuse color should be added to the color output because I have no way of knowing if my object is lit by a regular light or not.

Basically, its highly impractical to have one light operate on one texture map, and then add that texture map to another separately lit one. As I mentioned in a previous post, I have an game with glowing plants, that have a surface color different than emission color, that have specular highlights, and subsurface scattering. I achieved this all by layering up multiple sprites set to 50% transperancy, sitting ontop of each other, in specific sorting layers, affected each by specific lights with their respective intensities doubled, quadrupled, or whatever as calculated in order to get the effect of adding the sprites together, even though they are being alpha blended.

Long story short, Every light in my game has to be 4 lights, and every object has to be layered up from multiple sprites. This is the only work around I have found.

TLDR. If I could access 2d light data in 2d shaders, I would be golden. But I can’t.

Adding an emission ch would help fix part of the issue, and would simplify my hack of a workaround. Seriously though. We need 2d light data in shader graph and an emission ch.

[Ruskul]

Also, quick question, I already asked, sorry it am being impatient…

Is there a plan to add pnumbras / soft shaders to the light system?

@Ruskul

Is there any plan to add soft shadows and light widths to the 2d lights? Basically penumbras.

So many of the 2d light assets packages supported penumbras, but most aren’t supported anymore because… you know, its not profitable now that unity has a solution.

The other hope I had is that we could access the “light” layer(s) directly and influence what they do. I would very much like to render a set of lights and modify the light so that it is banded or cell shaded and then apply it.

[Ruskul]

Also, can we have it so the shadow caster shape can be pulled from the 2d collider. Its kind of silly to have to enter the same shape more than once.

[castor76]

I have questions about SRP batching ( or just draw call batching in general) in 2Drenderer. To my dismay, I have not seen any SRP batching happening for my scene, where I pretty much use the same shader for most of the objects. The shader itself is made using Shader Graph, using the default ( and only ) Sprite Lit Master node.

Any information about SRP, or on how any batching works for 2D Renderer? I am familiar with other types of batching techniques from legacy rendering era. I am pretty sure my scene had a lot of SRP batching on just normal URP, but moving to 2DRenderer, it all seems to not work anymore.

[Ruskul]

Further expanding on the need for an emmision ch and texture in the 2d master node:

My hack arounds are ok and all with basic sprites… until you start using things like sprite shapes or 2d animated rigs. Then things start to really suck.

[Taurdenga]

Any estimate as to when _CameraOpaqueTexture (or the Scene Color node) will work with the 2D renderer?

Also, is there any way to fade 2D shadows based on distance, right now shadows generated from a Shadow Caster have the same transparency all the way until they end with the light. Any way to make them fade over distance from the light source? Thank you!

[Grafos]

@Chris_Chu

Ah I see. I don’t think this has a simple solution and would likely require additional engineering. If I’m able to come up with something simple though I’ll post and/or message you about it.

Any updates on the light shafts?

[WonkyDonky]

Does Normal Maps work with sprite atlases now?
+
Any timeframe on full release?

[castor76]

Writing to normal buffer does not respect depth buffer! Please fix this!

[castor76]

We should be able to choose the light buffer and shadow buffer (if this also exist) sampling type. For pixel art style, we would very much like to have pixel perfect 1:1 pixel ratio to what is set on the main camera.

We also want to have the shadows’s intensity to be controlled not only by the light but also by the shadow caster as well. This is because we want to control the intensity of the shadow, but at the same time we need ability to block light completely so we can control the leaking to the other side of the wall for example.

[castor76]

Also when you are drawing shadow, it seems like the objects that are outside of range of particular shadow casting light is also drawn into consideration… I am looking at the frame buffer, and draw call increased whooping number of multiples when I started using shadow. I can understand some more draw call is needed , but most of the objects that are well outside the range of the light is still casting shadow for some reason. This has to be a bug? Maybe this is kind of thing that Unity is talking about to fix and currently working on?

[HuldaGnodima]

Hello!

I’ve been trying out your lighting-features and they are AMAZING.Thank you for making such wonderful tools.

I saw the Unity tutorial on how to make “light shine through leafs”. In it you take theses sprites:
and make Sprite-Lights of them and make beautiful light-patches on grass:

Trying to make an ‘inverse’ cloud-shadow effect:
I thought perhaps I could do reverse effect, where I make a reverse sprite to make “shadow patches on grass” that resemble clouds passing overhead. I have done this and the sprite looks like this:

(it’s like an inverse version of your light-patches sprite). The effect that I get with this on a Sprite Light 2D is beautiful, see here in this video:
gcxqra

However, with this solution, as you can see in the video, one always has to consider how to handle the edges of the where the “Sprite Light 2D”-sprite ends. You can see this edge of sudden light/dark appearing around the sprite when the “cloud” moves downward in the video above. Due to this the Light Sprite 2D becomes difficult to use here and probably for other similar purposes.

My Question:
Because of this I am wondering if you are planning on adding something like a “Shadow Sprite 2D” (much like your “Shadow Caster 2D” script)? What I mean is a feature where a sprite becomes a 2D-shadow (unlike your wonderful Shadow Caster 2D that casts a shadow). And if not, would you consider it?

If it existed for example I, and others in a similar position, could simply use sprite like this:

And use it to become/“cast” a shadow in the world.

I think it would be a very powerful tool for developers and enable even more flexibility (especially when you’ve created such a powerful system for manipulating light.)

Thank you so much in advance!
Hulda

[Lo-renzo]

@HuldaGnodima

snip

Some people accomplish an effect like this by putting a screen-sized sprite in front of the camera with a shader that animates the clouds so they swirl in and out. The shader takes into account the worldspace position so that as the camera moves about the position changes so the swirling clouds appear to have a real worldspace position independent of being of the sprite, which stays locked in front of the camera. Other weather effects, like rain, can be done in a similar way. As someone who didn’t gravitate to shaders as a solution because of their unfamiliarity, Shader Graph makes stuff like this way easier than it used to be. Might be worth investing some time in.

[essimoon2]

@Chris_Chu

This is a known issue. Its something I’d like to address soon if we can, but I can’t give you a time frame at the moment.

Is there an update on the state of the _CameraOpaqueTexture? If I’m not mistaken it’s still broken in then 2D renderer

[Chris_Chu]

Unfortunately, you are not mistaken. It’s still making its way to the top of the list of things we need to do.

[Cambesa]

@alex174

Hello!
Unity 2019.3 beta
Inside the sprite shape renderer, the “Color” parameter does not change!
If the material with the “Sprite-Lit-Default” shader is applied to the sprite shape, then the sprite color cannot be changed! And if it is a single sprite (NOT a sprite shape) and the same material and shader, then the color changes.
Will this be fixed? In general, did I ask this question here, or are there special places for such topics?
Thanks in advance!

Make your own shader based on the Sprite-Lit-Default and in every pass, multiply the value by the _Color property before returning.