[RELEASED] Super Fast Soft Shadows

I don't have this asset, but I read though the forum and I'm going to refer to post #22:

 

@bluescrn

I'll look into that editor issue. There are already a number of workarounds for problems like that. It's probably not possible to make it work perfectly in the editor, but we'd like to get close.

As for perspective camera support. It's on my todo list, and it should be possible, but I haven't looked into it too closely yet.

@binaryprogrammer

I've never used ShaderForge, so I don't really know anything about it. The "SF" prefix is just a coincidence. (Super Fast Soft Shadows) You can use your own shaders, but they need to sample from the screen space lightmap textures. I have no idea if you can do that with ShaderForge.

SpriteLamp: That means you have normal mapped sprites. To use normal mapped sprites you need multi-pass forward rendering. Unity's renderer is not extensible so we can neither make SFSS work with the existing multi-pass lighting, nor can we implement our own. Unfortunately that means that you can have normal maps or shadows, but not both.

 

Hi,

Look like it's exactly what I'm looking for, but here are few questions:
1. Will it run on Unity Free (most important for me)
2. How will it behave in 3d? Will all objects be affected, regardless of depth? I'm making 2d game, but everything is set in full 3d, and there is lot of parallax done that way.

 

1) Yes, it will run on Unity 5.x Free. (It does need Pro if you are still using Unity 4.x)
2) It doesn't currently work with a perspective camera, assuming that's what you mean by "3D".

I'm looking into fixing #2, though the effect is decidedly un-3D to begin with. It's still going to operate in screen space, so an object's depth in the scene won't affect how it's lit at all.

 

Would this work with 2DToolkit and Ferr2D?

 

Thnks for answer. Unfortunately, I'm still using 4.x, and we will probably stick with it for a while .

 

I'm not sure why it wouldn't work. You might have to change a shader on your sprites, but that's about it.

Bummer. : (

 

In my project I'm using a Tilemap that uses PolygonCollider2D components that contain multiple paths of points and the SFPolygon script doesn't support this. Are there any plans to support polygons with more than 1 path?

If not, then is there any major performance issues with having a large number of StreetFighterPolygons in the scene? (500+)

 

@BehemothPro: For supporting multiple loops, we recommend adding separate colliders for each loop. Of even if one loop is really large, it might be beneficial to break them up for geometry culling reasons anyway. I think there are plenty of situations where more smaller Street Fighter Polygons would be an improvement over large world-sized ones. You might have to find a balance, but I'd start with the easy thing and optimize from there. (Presumably the easy thing is one collider per tile)

I also wanted to share a screenshot and blog post from Escape Industries. Fingeance is another game that is using SFSS, they've written a blog article about their experience livening up the backgrounds of their games with shadows:


http://www.escapeindustries.net/updating-backgrounds/

 

Thanks. I'll try doing that.

Another issue I'm having is when I have any image effect attached to the camera the lighting appears to flip vertically.

 

Yes, I have the same problem. This is what you mean, right?



I've discussed this over PM with @Andy.Korth and was referred to http://docs.unity3d.com/Manual/SL-PlatformDifferences.html which is indeed the source of the problem. However I don't have a complete fix yet.
I've managed as far as fixing the shadows but the 'Scatter' color is still flipped. Here is a screenshot where the SFLight has a very small radius so the issue is more prominent:



The scatter color is rendered in SFRenderer::OnPostRender() and I thought I could also flip the quad in that code but that didn't seem to fix it.

 

… and while I'm here, a few more suggestions/feedback/requests:

1. In addition to SFPolygon, maybe add an SFCircle. Defining a circle with the SFPolygon takes a lot of edges and is hard to scale. A circle shadow could be as simple as a segment of SFPolygon (just two vertices - no looped) that is perpendicular to the light source. In fact, this is how I'm doing at the moment (SFPolygon segment with a Look-At script) but that doesn't scale with multiple light sources. Seems like it would be cheaper to support this natively.
2. SFPolygon opacity. For places like a glass window where you don't want to block all light nor let all light pass through it would be nice to be able to specify an opacity.
3. The SFPolygon editor or gizmo could use an indicator whether it's inside-out or not. I was chasing a bug for a long time before I realized it had to do with this toggle. Now I have to go fix all of the polygons and I have to go one by one and test one by one because I can't tell from the editor whether the polygon is flipped or not.
4. When editing the SFSS objects in the inspector, for instance toggling the 'Inside Out' property, the object is not marked dirty. Let's say you open a scene. Toggle a couple of SFPolygons and forget to save and load a new scene. Unity is not going to ask you to save and the work will be lost. Marking the object dirty after a modification is a one line change.
5. Support undo. Also a one line change in the editor class (times the number of places where the object is modified).

Cheers!

 

@Manny Calavera @BehemothPro We put out an update about a month ago that was supposed to fix that issue. What version are you on?

@Manny Calavera #2 Hmm. Interesting idea. Now that you mention it, it should be possible to do colored transparency too. #4 and #5 We do have code for handling undo and marking dirty. Dirty marks still work on Unity 4.x, but they don't on Unity 5.x. Undo doesn't seem to work on either anymore.

 

@slembcke2 I'm on latest Unity with latest SFSS. If you are referring the code within #if/endif that only fixed a clipping issue. The shadows are still flipped on DirectX platforms.

 

@Manny Calavera Do you have a reference to "_SFProjection" anywhere in the project? Since SFSS isn't a image effect, Unity's recommended fix doesn't work to unflip their flipped projection matrix doesn't apply. Our fix was to ignore the projection matrix that Unity gives us and pass a clean copy of the matrix as _SFProjection instead.

 

Hi @slembcke2, I just created a new project on 5.2.1f1 and downloaded and imported SFSS. It says on the Asset Store window that it is version 1.2 (Aug 21) and if I click on 'release notes' it does mention the fix for the flipped shadows.

However the issue is still present. Repro steps: New project, download and Import SFSS and Standard Assets, Add Anti Aliasing (or any other effect) to the camera, Edit -> Project Settings -> Quality and set Anti-Alias to Disabled.

I don't see _SFProjection. Should I? Is is a local variable or field? In which file?

 

Just confirmed that the version on the Asset Store does not have the DirectX flipping fix. According to Git, it was fixed on August 25th, so apparently it didn't get submitted. Sorry about that. :-\ We'll make a new release for it tomorrow along with the other minor fixes and features from the last month.

 

We've submitted version 1.4, which includes fixes for those DirectX flipping issues. It also includes improvements for users who might be using a perspective camera.

Sorry about the confusion. I think I must have messed something up when trying to submit version 1.3. It was submit while version 1.2 was still in review, and I guess it never went through. 1.4 will be up as soon as the review process is done!

Also a question for our users: How many of you are still using Unity 4? Is support for Unity 4 still a priority? I've so far been doing testing and submission in 4, just to make sure it'll work for people who are on that version.

 

I haven't got the latest version yet (haven't touched the project for a while), but I did run into a flipping issue on iOS (Metal) - which I solved by enabling the 'DirectX flip' logic in RenderLightMap() when using Metal

Only tested it with Metal, haven't run it on a GLES2 device yet

 

any news about SFSS? new feautres or something?

 

nothing?

 

I'm having a problem getting a blue colored light to show on my green grass background. It seems that the lights are multiplying the colors and there's no option for additive lights. Is this a feature your planning to support in the future and is there some quick fix I can do somewhere in a script or shader to get additive lighting? Thanks.

 

Green objects are green because they reflect green light and absorb other colors. If you shine a blue light on a green object, there will be little (or no) green light for the object to reflect. You *must* mix a little white light in with your blue if you want to light other colors.

 

I'm trying to have a fully lit scene with an oversaturation of blue coming from a light.

My SFRenderer settings are:
Linear Light Blending: False
Shadows: True
Ambient Light: 128, 128, 128, 255
Global Dynamic Range: 2
Light Map Scale: 8
Shadow Map Scale: 2
Fog Color: 0, 0, 0, 0
Scatter Color: 0, 0, 0, 0
Soft Hard Mix: 0

I have a SFLight in the scene set to the color Blue (0,0,255,255). It looks like this. Barely visible as you said.


I put a little white color(49, 49, 255, 255) in the light, and it now looks white:


What I'm aiming for:

This is a additive texture (Default-Particle) placed over the forest sprite.

I can also achieve this effect by changing the SFRenderer to these setting:
Ambient Light: 32, 32, 32, 255
Global Dynamic Range: 8

which gives this result (Scene View on the left, Game View on the right):


but as you can see my scene view is not liking that Global Dynamic Range value. So I would be going with my last example except I can't work on the scene. Any other suggestions of what I could do? Thanks.

 

@BehemothPro Ok. So what you are trying to do makes sense, but the problem is that it's not lighting. What you want is to have the air glow instead. Fortunately the fog effect will let you do that. There are three fog related parameters on the SFRenderer component. On for the fog color, how much of the scene is blocked by the fog (set that to transparent). The other is the scatter color, or how much light the fog reflects from lights (set that to blue). Lastly, adjust the soft/hard mix to adjust how prevalent the streaks are.




Unfortunately I noticed a bug in the process. The fog doesn't apply the global dynamic range value, which you'll probably want to use. It's an easy fix though. In SFFogLayer.shader make the following changes.

Code (csharp):

1.  
2. // Near these lines:
3. sampler2D_SFLightMap;
4. sampler2D_SFLightMapWithShadows;
5. float_SFGlobalDynamicRange; //  Add this line
6.  
7. // In the FShader() function, change this line:
8. half3scatter = _Scatter.rgb*lerp(l0, l1, _Scatter.a);
9. // To this line:
10. half3scatter = _Scatter.rgb*lerp(l0, l1, _Scatter.a)*_SFGlobalDynamicRange;
11.  

 

I made the changes but by doing so it causes the whole screen to go more blue. I only want the light to be more blue. I think I've gotten it more or less the way I wanted it by simply combining a light + an additive blue halo sprite on top of it, not perfect but it does the job. Thanks for the help.

 

Do you have ambient light enabled? That will cause the fog to glow as well.

 

Thanks slemche2, I got it the way I needed it. Our designer made a short video showcasing the soft shadow system in our project. Thanks again.

 

This looks great! Awesome work @BehemothPro!

 

Does the lighting system work with 2.5d setup? I've got an ortho camera looking down a RPG-Maker style tile map with some 3D models and mostly sprites. Mainly, I want to lit 2d tiles and sprites so lighting on 3d models can be passive as long as it doesn't generate graphical glitches.

Edit
Couldn't wait for an answer so I decided to give it a try. It worked with some effort. Nice!

 

@noanoa Glad you got it working! It looks like you have a single layered scene with an ortho camera, like you mentioned- the camera's at an angle. For others in similar situation, I think the main thing that you'd do differntly was to be sure you adjust your shadow geometry if you are unhappy with how it looks. Ortho cameras should be pretty easy and it'll project your shadows onto the x-y plane automatically.

 

How well does this handle a multi-layered procedural tilemap mesh on a PC game? Each map is going to be roughly 240x320 destructible tiles, consisting of 8x8 chunks, along with a background and foreground layers as separate materials. There are roughly 10 chunks being displayed horizontally at once in a 1920x1200 window, with possibly up to 10 lights being visible. How much of a performance hit would've this been?

I've looked through the docs, and it appears that it only needs an array of vertices for each polygon, which shouldn't be a problem, as the chunks are already using Unity's polygon colliders, which can be divided into several sets per single GameObject. Does this system support something similiar?

 

On a desktop, that should definitely be no problem.

The shadow geometry uses SFGeometry, which is a simpler and lighter weight than the Unity colliders. But they can be automatically generated from the colliders. Or you can make your own if you want something to cast shadows without having a collider on it.

From what I understand, it sounds like you'd want to simply add the geometry to each one of your tiles or chunks. Breaking them up that way should be easy and provide very good performance. Good luck with your game!

 

You can also use SFSS to create a directional light sort of effect. I was helping a customer earlier today with their setup so they could create something like this:



If you want something like this in your game, we recommend you set up your scene with a single light that follows your camera. Remember, you can set the source of your light to be outside of the bounds of the light's cookie. In this case, it's way off screen to the upper left.

Also, try a solid white cookie, or a subtle gradient. Here's how the scene is set up for this example:

 

SFSS 2.0 is now submitted for review!

Version 2.0 includes a bunch of new features, such as:

• New sampling shaders- shade an object by sampling the shadow map at a point or across a horizontal line.
• New ambient light blending options
• Four new example scenes, including a directional light example
• Built and uploaded in Unity 5
• Full Undo support

Thanks for all your patience and support!

​

 

I've been reviving an idea that allows light to bleed into a surface by a bit. This can greatly enhance atmospheric effects. It also helps hide aliasing artifacts caused by subsampling, allowing the shadow map resolution to be reduced, and performance increased.

The implementation adds only a little extra logic to the fragment shader, so it shouldn't affect fill rate performance by much.

 

SFSS has been fairly focused on working as well as possible on mobile, but I'm also adding a couple of changes to enable HDR rendering on platforms that support it. Now you can use linear light blending without worrying about overexposure. You just need to enable HDR rendering on your camera, and optionally add the tone mapping image effect. \o/

 

One of the local Global Game Jam teams used SFSS for their game, Neon Ritual. It turned out pretty nice for a game made in 48 hrs. I think the shadows helped give it a lot of flair, but I might be biased. ; )

 

Hi, I'm thinking about buying SFSS but I have some questions.

1. Is it possible to try out the asset before buying (some sort of free/demo version)? I have already tried 5 different 2d shadows systems and none of them do the job well. So I really don't want to buy before knowing if I will be able to use it.
2. As I understand, SFSS doesn't use any raycasting to draw shadows?
3. How fast is this system? I've read performance depends a lot on lights number. Does objects/shadows number affect performance a lot? Could it handle something like 100 objects/shadows with 1 light at 60 fps on mediocre android?
4. Does it support shadows on particle systems?

 

1) Not currently. We were talking about making some demos last week. Web and Android should be pretty straight forward at least. People generally seem quite happy with it, but we have given somebody a refund when it didn't work well for their pseudo-3D game.
2) The shadows are rendered using GPU friendly triangles and a fairly inexpensive fragment shader. No raycasting (expensive on the CPU) or image filtering (expensive on the GPU) is used.
3a) The largest cost by far is almost always pixel shading. So the total screen space area of the lights and shadows has the most effect. You can adjust the shadow map resolution easily to adjust the performance if you need many large lights at once. You can also disable shadows on lights that don't need them.
3b) There is a small CPU cost per shadow caster for the culling. Inactive (unlit or offscreen) casters are nearly free. There is also a small per vertex transform/batching cost for active casters.
3b) Our $100 android tablet can run #87 just fine without dropping frames. 6 nearly fullscreen lights and a dozen shadow casters using 4x downsampling. Our older Nexus 7 and iPad 2 handle it fine as well. It's not really meant to be a stress test though. I'd expect a few dozen lit/onscreen casters (< 30 verts each) with 2-3 lights to be completely reasonable on the same devices. The number of offscreen casters or lights wouldn't matter much.
4) Not easily. You would have to add shadow geometry to follow each particle, and that would get expensive very quickly.

 

Hi. I love the asset but I'm having a minor problem as shown in the included gif. When a light source overlaps a shadow, the shadow suddenly disappears. Is it difficult to implement something like fixing the shadow size at certain size(e.g. at an angle of 180) and making it rotate around the light while the light overlaps it?

 

@noanoa This is something I've thought about for years, and I don't really have a good solution for it. The best hack I've come up with is to create double sided geometry and sort of fade the light as it passes through. It's significantly more complicated and I've never been able to get it working right. It also doubles the amount of geometry you need to create since everything has to be two sided.

The best solution is to prevent your light from passing through solid objects using colliders since you can't move a light through a solid object in the real world either. Pushing the light around the outside of the shadow polygon is also going to look weird I think.

 

My current solution for this is also the one you suggested(using colliders) and it works fine. I should just stick with it until one day you magically come up with better work around. Thanks for the reply!

 

@slembcke2, #91
Thanks for detailed answer. So I have bought the asset after all. Here's some feedback:

• Setting up everything to work correctly was quite difficult. I'm still confused by all those colors (Ambient light/fog color/scatter color).
• Performance is great, what matters the most to me. Runs smoothly on my phone.

Overall, I'm really happy with final result. The asset is quite expensive, but definitely worth the money.

 

It doesn't work anymore. Looks fine in the editor, but after compiling, background mesh is solid black, no matter what color I set (so lighting and shadows also cannot be seen). What could it be?

 

Yeah. "Better documentation" is something that is never done. :-\

Not entirely sure what would make it work in the editor but not a device. Some thoughts:
* Did you change Unity versions, renderer settings in build properties, or phones?
* Is it possible that a setting on a shared material used by your background gets changed?
* Is it possible that your light's color/intensity gets set to black/0 somehow?
* Is it possible that the SFRenderer component gets disabled somehow.
* Is it possible that the SFRenderer.globalDynamicRange property gets set to 0 somehow?
* Are you trying to run on an iOS device with Unity's (very buggy) Metal renderer?
* Do you have an earlier version or build you can revert to and see if that still works?

 

After lots of testing I've found out what's been causing it: I moved shaders to other folder (To Assets/Shaders from Assets/SFSoftShadows/Resources). Still can't understand why it works in the editor but not after building it.

 

Ah. It's because we are using Shader.Find() to load the shaders. Less to go wrong that way without requiring magic inspector values.

 

I just spent a good portion of the day pulling my hair out while debugging shadows that just disappear when the light source moves around. Reread the docs, rebuilt the polygons, messed with the clipping code... Turns out it's due to the camera being in perspective mode.

Any news on supporting perspective cameras? Is it just the clipping/projection that is off or is there something inherently different about it?