[RELEASED] Super Fast Soft Shadows

Huh. Not sure when that got broken. :-\ I guess nobody was using that feature. (Including us!)

 

Hi! Thanks for the great plugin. Unfortunately, I've run into two problems which make it not work in my project:
1) When I change the material on my background sprite from `Sprites-Default` to `SF*`, it breaks the layering with my Spine-Unity assets. Suddenly, all of my Spine assets appear behind the background sprite.
2) When I add a SFPolygon to a GameObject programmatically, it does not immediately begin casting shadows. Weirdly, if I simply click on the game object in the hierarchy it starts casting shadows.

 

Hi @inZania

1) Can you change the layer it's in or the sorting order? SFSS works fine with those controls. It uses the same render queue flags as the default sprite shader too, so I'm not sure why it would change the rendering order by switching shaders.

2) Are you adding them progmatically in the editor mode or while the game is running? If the game isn't running it might not be getting a repaint call to happen until you click on a game object and force a redraw to show the bounding box. A google search recommends calling SceneView.RepaintAll(), but I don't see any docs for it. Seems like a Unity editor bug maybe since it should redraw when gameobjects are changed?

 

Greetings from Finland!

Could you please do a demo showing similar (metaball style / bloom effect) glowing as in Zippy Lights 2D (https://www.assetstore.unity3d.com/en/#!/content/59866)? The effect is best seen at 1:55 in the video. Then I will be glad to buy your product!

 

Does this asset work with top down games? If so, I'll buy it. Also, do you have any top-down demos?

 

@Haapavuo
That metaball effect is just a particle effect with additive particles set to emit from the source of the light. Do you know how to set up a unity particle system and choose the "Particles/Additive" shader for them?

We don't have in SFSS that would help you create particles where the light is hitting objects. That effect is most pronounced at 1:40 in the video, so I *think* that's not what you are looking for.

Hope that helps!

@1brianjones
Yep, the asset works in top-down games! Our asteroid / space shooter demos are top down, as well as the tree demos.




Also, check out what some of our users have done:
http://forum.unity3d.com/threads/su...system-in-progress.331154/page-4#post-2658679

 

@Haapavuo
I made a particle system:

Here's how I set it up:


Hope that helps!

 

Thank you for your response!

I am not really experienced with the Unity Particle System so I was not sure whether that could be easily created using particles. If you know a decent tutorial or example for this, I'd be glad to see one!

Does SFSS also affect the emitted particles by the way? I am still kind of hoping to see a demo that really works with the bloomed / glowing source of light!

Correct. I am not really interested in the effect where the system creates particles on object that the light rays hit. Just the glow at the source of light.

EDIT: Woah! That was fast! Seems like SFSS is exacly what I want! Thanks for great support! Happy to do business with you.

 

Glad you like it Haapavuo! SFSS Version 3.3.1 has been submitted to the store. Once approved, it will have that demo scene in it!

If you have a script that adjusts the intensity of the light, you could also adjust the emission of the particle systems. That way, when you turn the light off, you can turn the particles off as well. Thanks!

 

Yes, indeed.

However, I have now faced one major problem with SFSS. My player casts a cone of light in front of him (similarly as in your platformer demo). I want that light to enlighten an object in front of the player but that object is actually closer to the camera than the player is, meaning that the player will be behind the object when passing it (the object does not have colliders, and it does not cast shadows). Here, SFSS now still renders the light on top of the object and not behind it.

Do you have any suggestions how I could enlighten the object when the player is not behind it, and make it dark when the player is behind it? I guess I would need z layer information here to be passed to SFSS somehow.

Here is a quick illustration showing the issue: https://docs.google.com/drawings/d/1iXajU4YMbT98DFsVGPtVeG13crbIk2UnKQvFcncQ9Hs/edit?usp=sharing

Pink is the player, blue is the other object. The 2 upper cases now happen for me. I would like to end up with the bottom case.

 

Hi Haapavuo: That's a very difficult thing to achieve. In the top image the player is in front of the light, in the bottom image the player is behind the light. In Unity (or in real life), you can't really have things be both in front of and behind something.

Personally, I think the transition would look very strange. Imagine a flashlight shining on the front of a rock, then the flashlight is occluded by the rock and the rock suddenly becomes dark. How was the flashlight shining on the front of the rock when it's behind it?

However, if you really want to achieve this, you could do so by changing the Material of the foreground object. The foreground object would need to detect the distance to the player's light source (or some other occlusion criteria of your own), and then switch to an unlit material. (You can use a SFSS ambient only light like this: http://kortham.net/temp/upshot_12ViTpM9.png ). Then the light won't appear on that foreground object. You can also animate the lit/ambient change to 1.0 over a short amount of time so the light on the foreground isn't extinguished immediately.

If the shape of the foreground objects are irregular, it might be a challenge for you to determine if the light source is occluded by it or not.

Additionally, that approach only works if you have a single light source in the scene. The foreground object would become unlit by all lights once the player's light goes behind it.

Hope that helps!

 

Thank you for your explanation.

I personally don't think it would look weird, at least if I can use normal maps to determine how the light affects the object (imagine a rounded rock that only partly receives the light).

Is there any example using light normal maps for sprites with SFSS?

A more general Unity sprite illumination example using normal maps: https://www.codeandweb.com/texturepacker/tutorials/2d-dynamic-lighting-tutorial-for-unity#

 

Hello!

I bought and tried Super Fast Soft Shadow but I have a question.
Is there a way to have soft shadow in the XZ coordinates instead of the XY ?

I'm working on a project that need to be in XZ projection.

Thanks!

 

@Haapavuo Normal maps could look pretty cool, but I don't know of anyone who has tried using them with SFSS. I'm familiar with the sprite illuminator approach- it's pretty awesome. If you have success, please be sure to post screenshots!

@Bulwark-Studios Unfortunately, changing from XY to XZ isn't trivial. Here are some pointers that might help you if you do go through with the modifications:
https://forum.unity3d.com/threads/s...system-in-progress.331154/page-3#post-2595737
https://forum.unity3d.com/threads/s...system-in-progress.331154/page-3#post-2596014

Let me know if you have any questions that aren't answered there. Thanks!

 

@Haapavuo Unity's lighting is not very extensible, so SFSS is implemented independently. That effectively means we are locked out of doing any sort of multi-pass lighting needed to do normal maps, layer masking, or some concept of z-ordering.

Instead what SFSS does is to render all of the lights together into a light buffer for the screen. Sort of like how a deferred renderer works, but simpler. Then when a lit sprite is drawn, it checks how much light there is in the light buffer and applies that. Since all of the lights are blended together, they all effectively have the same z-ordering, and you can't pick which lights shine on which objects. It also means that you don't know which direction the light is shining from and can't apply normal mapped lighting. On the bright side (pun intended), it's quite fast and doesn't require nearly as much texture memory.

BUT!

Since Unity lights, and SFSS lights are mutually exclusive, you can use both types, just not on the same objects at the same time. You can use normal mapping on your background and foreground objects while only using SFSS on the middleground objects (or etc). This should allow you to achieve the look you want. To have a rim of light around your foreground objects, while still using SFSS on the objects that are on the same z-order as the lights themselves.

 

Thank you both for awesome support!

I guess I'm going to have to try to mix SFSS with Unity lights, and maybe implement normal mapping myself.

I realized one more thing I would like SFSS to have: Opacity for SFSoftShadow shader (the opacity of the rendered sprite should be changeable using a script). Would that be easy to implement? I don't have much previous knowledge of any shading language.

 

Do you mean:
Opacity of sprites: You can change the sprite color's alpha like any regular sprite.
Opacity of a SFPolygon: They have an "Opacity" property.
Opacity of a shadows in general: If you make a material using the SFSoftShadow shader, there are sliders to adjust shadow strength, and overall lighting strength.

Anything else I missed?

 

I've made some progress on supporting perspective cameras lately, and have gotten the shadow masking to work in perspective.


Light volumes don't really work yet. I was hoping it would be as simple as switching to projected texture reads, but no such luck. Since the pass that draws the light volume is combined with the pass that clears the shadow mask (for performance reasons), it's more complicated than just drawing a sprite. :-\

I'm also going to need to rewrite the culling code from scratch, but I can burn that bridge when I get to it.

 

Actually, yeah one more thing! Meshes.

I have a procedurally generated mesh that uses SFShadowed material (SFSoftShadow shader). Here I cannot see the color option: http://i.imgur.com/xZWDWZe.png

Color is only for Sprite Renderer but I am using Mesh Renderer, thus I will need the option for the material instance itself. And yes, I am talking about the color of the sprite texture. I need to change the alpha of the texture (sprite) of the mesh.

Could this be added? Thanks! If this is too hard to implement for textures, I could also do with just scriptable single color fill material for meshes that supports soft shadows.

And good job there with the perspective projection!

 

Hi Haapavuo! That one wasn't too hard. I updated the shader so it can take color tints and alpha from a material, in addition to the color on the SpriteRenderer. (So people who are using the SpriteRenderer colors can continue to do so, but if you are using meshes, you can change the color on the Material).

In the current version, you do have the option of changing the vertex colors on your mesh. But it isn't very convenient to change that in Unity, especially if you want to animate it.

Here's a working screenshot!



This will be in version 3.1.2!

If you want the changes now, you can replace your SFSoftShadow.shader file with this one:
https://gist.github.com/andykorth/09b41d841f4a546a9101701af73fefdf

 

Awesome job! Thank you once again!

Seems to work just like it should.

 

Sorry, it seems that I cannot stop bothering you with stupid questions..!

Is there any way to make some lights affect only on certain layers? I have a SFShadowed background sprite for which I would like to have only lights A and B to affect. I also have various other sprites and meshes that use SFShadowed, but I want lights A, B, C and D to affect them. Is this currently possible?

Unfortunately it also seems I cannot get Shadow Layers option to help me with this...

 

Unfortunately no, for the same reasons as normal mapped lighting. That would require us to be able to modify Unity's builtin forward renderer, which is not possible.

Shadow layers only affect which polygons cast shadows for certain lights.

 

Perspective camera support has progressed somewhat slower than I was hoping. :-\ I really don't want to lose the performance of clipping the viewport to just the visible portions of a light. Since you can't do scissoring in Unity, it's annoyingly difficult to get the projection math right though. :-\

On the upside, we SFSS is a featured asset this week.

 

So a feature that probably isn't too widely known is that lights in SFSS are actually modeled as ellipses. Consider that in real life, lights are often not circular bulbs. For instance, you wouldn't want to use a big circle to model long light surface with SFSS, because then you'll have problems with objects intersecting the light area and causing problems.

For example, you have this simple scene with a room and a box in it. If you wanted to make that light softer, you need to make it bigger.


SFSS (and Unity's built in 3D lighting) assumes that objects are one sided, and that they don't overlap your lights. When they do, the objects sort of get turned inside out, and weird things happen. So if you can't make the light a huge circle, then how do you make it softer?


Elipses to the rescue! Really, you don't want to make the light bigger, you just want it to be longer. By scaling the light in only one direction, you can get the effect you want. The shadows from that light will be softer like you want, but without making the light huge and causing clipping issues.

 

Hay! I finally figured out a significant hurdle to supporting perspective cameras in SFSS. How to correctly project the rendering from one arbitrary plane onto another:


So now you can project shadows from an object that isn't on the lighting plane and be able to get parallax shadow effects. More importantly, the light cookies which are drawn in screen space so I can combine it with a light mask clear pass, render in the right places. \o/

Remaining steps are rewriting the culling and scissor test code to work with a perspective projection, both of which I have code to do in another project that I can pull from.

 

Everything seems to be working in perspective on Unity's GL renderer. Culling and scissoring has been rewritten to respect the perspective and performance seems to be roughly equivalent to the current version. Tomorrow I'll test DirectX and Metal. \o/

 

I tried out the latest Asset Store version on Metal (iPhone 6S) using Unity 5.5, and had to debug some strange shadow glitches (flickering/popping, and it looked like it was drawing one shadow mesh multiple times at different offsets).

As far as I could tell, it doesn't like the use of one shared mesh that's modified then drawn N times during one frame for the shadow geometry. I modified it to allocate one mesh per light, as in older versions (so each mesh is only updated/rendered once per frame), and that seems to get it working again

 

That's new. :-/ (More Unity bugs to file. Yay?) Was just about to start doing Metal and DirectX testing of the perspective rendering features today, so I'll try and replicate that too.

 

The good news is that the perspective support is working with Metal. The bad news is that I did replicate that bug using Unity 5.4.1 and 5.5.0. We did a bunch of Metal testing when 5.4 first came out. Not sure if we missed the bug (since it doesn't happen all the time), or if it's a newer Unity bug. Either way, I'll work on a workaround.

Worst case, like you say, I just need to cache a separate mesh per light. As long as it's cleared after rendering it shouldn't waste much client memory. My first attempt was to call Mesh.UploadMeshData() and see if that helped, but apparently that makes Metal not draw the meshes at all...

6 months ago I had very little to say about the Metal renderer that was nice. It seemed to be just chock full of bugs. About a week ago I was telling somebody that it seems to have finally stabilized. Now to find two more Metal bugs this morning. -_-

(edit: Yup. Seems like keeping a mesh instance per light is the workaround for now.)

 

Hey, i have some problem with shadow flickering on mobile, in editor it works great, but after exporting to my phone (Galaxy S2, Android 4.4, pretty old) those glitches with shadows are showing up. However not in every place, here are some screenshots




and this is the area where it looks good


here are my settings


Maybe i am doing something wrong (to many sprites in one place?). I tried tweaking shadow map scale and it does help a little (still visible flickering) but performance drop is to high
Unity 5.5, latest version of SFSS

 

When you say "shadow flickering" do you mean these speckles here?


Unity defaults to low precision framebuffers on some Android devices, and varies from GPU to GPU. There is a lot of dithering in the screenshot you shared, so I'm assuming that you don't have a 32 bit framebuffer. SFSS uses the default framebuffer format for creating its lightmaps. That's probably a mistake, and it should explicitly create a 32 bit one instead. Find this line in SFRenderer.cs:

Code (CSharp):

1. RenderTextureFormat format = (camera.hdr ? RenderTextureFormat.DefaultHDR : RenderTextureFormat.Default);

Try replacing the "Default" at the end with "ARGB32" or "BGRA32". If one of those fixes your flickering issue then we know it's due to the framebuffer precision issue and I can make it select the correct one at startup instead of letting Unity use the default format.

 

Yes,
Unfortunately replacing default render texture format does not help, but... I came up with something interesting.
The region where shadows displaying correctly is close to Vec3(0,0,0), so i shifted the area where glitches were the most visible to this (0,0,0) position and voilà! No flickering, no glitches on the edges. So maybe this would help you, if not i will have to move whole level instead of character

 

Oooh... I think I know what is going on then. It's the floating point precision used by the light penetration effect. The distances are calculated in the fragment shader based on a global value. I bet it's using a float16 value to do it in the fragment shader (which is allowed by the OpenGL ES 2 spec). Let me take a look and see if I can do something in the vertex shader to offset those values.

In other news, I remade the forest example scene today to use two piece trees so the trunks and tops can be lit separately, and it looks pretty nice.

 

@matthewhxq I think I have a fix for you to try:

Open SFShadowMask.shader and find this line:

Code (CSharp):

1. OUT.worldPosition = float4(mul(MATRIX_M, projected).xy/lightPenetration, 0.0, clipPosition.w);

Add these lines just before, and see if that helps.

Code (CSharp):

1. MATRIX_M._m03 = 0.0;
2. MATRIX_M._m13 = 0.0;
3. MATRIX_M._m23 = 0.0;

Instead of calculating the light penetration in world space, that will use coordinates relative to the light and should require much less precision.

 

@slembcke2 yup it works, thanks!

 

WebGL demo of the new perspective support:
http://files.slembcke.net/temp/SFSS_Forest/



Give it a go!

 

I have one more question, how can I render UI elements on top of SFLight, it seems no matter what order I try, the light is always on top of everything.

Nice demo!

 

We've got another new demo that shows off a cool effect you can do with multiple overlapping lights.

​

Try the WebGL version!
http://files.slembcke.net/temp/SFSS_Chroma/

 

Hi all!

Wanted to share this little script with all SFSS users. It binds the "_renderInSceneView" property of the renderer to the sceneview control bar. (the little sun toogle, to be specific)
So you don't have to navigate to the renderer and change the property manual to test stuff or have a clear view of the scene. Just add this script to your project and your good to go! (But note, that the property is now bound to the control bar and can't be changed with the inspector)

Code (CSharp):

1. using UnityEngine;
2. using UnityEditor;
3.  
4. [InitializeOnLoad]
5. public static class ToogleSFSSSceneRendering {
6.  
7.     const float sfRendereUpdateRate = 30; //secs.
8.     static SceneView view;
9.     static SFRenderer sfRenderer;
10.  
11.     static ToogleSFSSSceneRendering()
12.     {
13.         view = SceneView.lastActiveSceneView;
14.         EditorApplication.update += CheckSceneStatus;
15.         sfRenderer = GameObject.FindObjectOfType<SFRenderer>();
16.     }
17.  
18.     //Runs every time the editor update
19.     static void CheckSceneStatus()
20.     {
21.         if (sfRenderer == null)
22.         {
23.             //Only look for a SFRenderer at a predefined frequency, to avoid overhead
24.             if(EditorApplication.timeSinceStartup % sfRendereUpdateRate < 0.1f)
25.                 sfRenderer = GameObject.FindObjectOfType<SFRenderer>();
26.             return;
27.         }
28.  
29.         if (view == null)
30.         {
31.             view = SceneView.lastActiveSceneView;
32.             //Still no scene view
33.             if (view == null)
34.                 return;
35.         }
36.         //Update the rendere in scene bool according to the sceneview toolbar.
37.         //Warning: As SFRenderer doesn't support multiple sceneviews with different settings, so does this script.
38.         sfRenderer._renderInSceneView = view.m_SceneLighting;
39.     }
40. }

Hope you'll find it useful.

 

Hello!

I just upgraded to 4.0.0 and noticed that nonlinear light blending causes lights to "go through" SFPolygons that have opacity of 1.0 and light penetration of 0.0. The light mask shows up as a black overlay when it is penetrating / has penetrated the SFPolygon.

I have the following settings for my SFRenderer:


The effect is also visible on lower exposures than 1.

The wall itself has the following material:


It might be hard to see here but if you have a monitor bright enough, you can clearly see the darker light cone passing through the wall from left to right:


This might have also happened on versions before 4.0.0 since then I had linear light blending turned on and thus it was not visible.

Here is one more screenshot when linear blending is turned on:



Could you please explain what here causes the light mask to go through objects and show a black overlay on them? That is really not a desired behavior and it forces me to turn on linear light blending. :/

 

@Oribow Hey, that's pretty neat. I hadn't really thought of making it work with that button. It is sort of annoying to have to turn it on and off using the inspector. I'll experiment and see if there is a nice way to integrate that into SFSS.

@Haapavuo Linear blending is preferred whenever possible. If you can combine it with Unity's HDR linear rendering, you can get some very nice results, especially with tone mapping. The "non-linear" blending mode is a hack that gives you HDR-like lighting using a blending mode that works similar to Photoshop's screen blending mode. It doesn't require HDR buffers so it's much faster. The downside is that colored lights cast tinted shadows.

The fix is to use linear light blending, and that's why it's not the default blending mode. To work around the saturation, you can increase the dynamic range using the exposure value. Higher values will add more banding though, so use it lightly. Alternatively, I think only colored lights cast tinted shadows using non-linear blending, while white ones should not. I can't easily verify that right now though.

It might be possible to support framebuffer fetch on most mobile platforms to fix the issue, BUT the fallback for unsupported hardware would either the tinted shadows or linear blending. That's hard to work around.

 

Hey, I'm really interested in this asset.
Is there a way to get it to project shadows as if they were coming from a source a near infinite distance away for example to create a direction light like the sun/moon?
All the examples i've seen show behaviour similar to point and spot lights.

Thanks

 

@pixxelbob
Kind of. We made a patch for somebody that implemented it, but infinitely far away lights can cast a lot of shadows, which can become a lot of performance problems. In their specific case, the shadows faded out after a certain distance so we could do some sane culling, but that only works for certain games. Do you think that would work for you?

 

Great job with this asset! Quick question: does this work with Unity's global illumination?

I change my game's ambient light based on the time of day, so I'm wondering if there's a way to make tiles with the SFSoftShadow shader experience this change, or if I have to manually change each object's Self Illumination alongside the scene's Ambient Color.

 

By "global illumination" do you mean RenderSettings.ambientLight or https://docs.unity3d.com/Manual/GIIntro.html

If you meant the former, then mostly yes. SFRenderer has an ambientLight property, but it's not shared with Unity's. The reason for that is mostly historical, but it would be a one liner to set SFSS's ambient light to match Unity's.

 

That's interesting. I'm making a 2d endless runner which has procedural terrain generation. The shadow casters are just landscape such as trees and buildings, the visual style is fairly simple, I expect their to be between 10-20 static casters on screen.

Additionally can it cast a dynamic object such as a vehicle?

 

Well, that's the pretty much the best possible case. The problem is when you have a large map where objects that are very far away can cast shadows onto the screen.

SFSS works with both dynamic and static objects.

 

Hey! I am very interested in this.
Would it be easy to know if an object it's inside a light radius? I guess, if the lights are meshes, that I can check Colliders?