Swift Shadows [RELEASED]

Honestly, this type of optimisation is critical, if every plugin just created 28b of garbage per frame, it would soon add up, not only that during the optimisation phase of a title this would be an annoyance in the reports.

Get rid of it. no brainer. Unity agree with me

 

It is true in general that garbage is evil with the ancient Mono GC that Unity uses, but really, 28 bytes per frame is nothing even worth thinking about. Just a single empty OnGUI call will produce 50x times more garbage without actually doing anything
In any case, it's just impossible to write good C# code without some allocations.unless you're OK with making your code ugly and hacky. Some situations can be solved by introducing pooling/caching, but in this case, it is more like "okay, I can allocate 28b of garbage and keep the code crystal clear, OR I can avoid any allocations by writing a heap of boilerplate code that has little sense".
Having said that, I'll see what I can do with it, it'd probably be much easier to fix than I think now

 

I come from a compact framework background. on limited resource devices these things matter. I find it odd that you say "Lightning fast" but then posit that optimisation is not king.

Good on you for improving it. It'll likely be one enumerator, foreach, weak ref or ephemeral throwaway iterator (at 28b a pop) and will take minutes to amend as you suggest.

I will buy look to buy your product once you have. I need better / faster / cheaper shadows on mobile and whilst it was possible to whittle something up very quickly that does edit: [strike]this[strike] /a similar/ job in just a few lines of code ( I did, via an optimised 3rd party projection shader and a blobby sphere) I am hoping you took this to the logical conclusion of highest optimisation. The write up certainly suggests that so, happy day
Kind regards.

 

Optimisation is the king, but there has to be a limit somewhere. If I was going for absolute optimisation, I'd probably be going for handwritten native assembly code, but that code would be very hard to maintain. Which is also the reason why I am sometimes somewhat reluctant to sacrifice code readability for better performance.
But yes, 28b allocation ended up being just one enumator, so it's fixed now I'll hopefully push it (along with some new features and other optimisations) to the Asset Store somewhere next week, if everything else goes smoothly.

 

excellent. I am wondering if it would work with http://forum.unity3d.com/threads/polyworld-for-unity.239365/page-8 polyworld. A vertex lit path would be taken.
Will check the docs. exciting!

EDIT: Just to confirm this works okay in a vertex-lit path? Many thanks

 

Just tried it, and yes, it works just fine with vertex-lit path. Not that it was intentional, though And vertex-lit path will most probably be dropped in Unity 5, as it doesn't has a lot of sense these days anyway.

 

ah, this could be a problem. I will go investigate. many thanks for the heads up!

EDIT: Wait. no, what am I thinking. That's not going to happen.
Vertex lit is the Unity recommended path for mobile.

You must be thinking of desktop machines perhaps.

 

@twobob
Well, here's the official forum thread about this:
http://forum.unity3d.com/threads/official-dropping-vertexlit-rendering-path-for-unity-5-0.275248/
86% of votes are for dropping vertex-lit, so... From where did you find that vertexlit is the recommended path for mobile? It probably was 3 years ago, but personally, I haven't actually ever used it. And seems like pretty much no one is using it these days anyway, because, as said in that forum thread, VertexLit is just a subset of Forward and has no real advantages whatsoever.

 

Vertex Lit
Vertex Lit is the rendering path with the lowest lighting fidelity and no support for realtime shadows.
It is best used on old machines or limited mobile platforms.

Which is what I have. They also espouse - at length - how adding a vertex only path is a great thing to do in one of the recent Case Studies. I said Unity recommended. Not Vox populi.

Only time will tell if they pander. As you say, you haven't used it, and "it doesn't has a lot of sense these days anyway."
You don't see the point of collecting every scrap of garbage, Which makes me think you are mentally focused on much higher spec machines than in my world. Horses for courses, I always aim to make the very best with the least.

Thanks for the info.

 

Well, it's not exactly that. I have done stuff for low-end mobile devices, and I always tried to squeeze maximum performance when it is reasonable, but I've never used VertexLit because it is extremely limited. You can't achieve anything better than 1998 level graphics with VertexLit, and there is pretty much zero control about rendering. It's true that VertexLit is still the preferred path in some situations, but... it seems like it isn't really Unity recommended anymore, as it is them who proposed to remove VertexLit in the first place. That's why I believe it makes sense to move on and abandon the technology that will soon be finally killed anyway.
Anyway, this got slightly off-topic. The point is - despite of my personal beliefs, Swift Shadows do work in VertexLit and I'll make sure they'll stay that way.

 

Good point. back on topic. Apologies.
Will check it out when the new polyworld drops then. hero.

 

Just wanted to share a little something that I was working on: planar shadows. I plan to add this feature in some future release.

(click to zoom)

As the name suggest, planar shadows are still rendered only on one plane at a time, but hey, these are actual shadows now Small comparison with Unity's built-in shadows:
Pros
- Still much faster that Unity's built-in shadows, especially on mobile.
- Point lights can cast shadows too. With Unity's shadows, this is only possible in Deferred rendering path, which is pretty much out of question on mobile at the moment.
Cons
- Each shadow takes a draw call to render. I'll see it it'd be possible to leverage dynamic batching, but basically, draw calls are doubled. This happens with Unity shadows too.
- Shadows only fall on one plane at a time. This also means no self-shadowing.
- Shadows are rendered in screen space, which is fine for most cases, but in this case it also means that shadows will be rendered after the fog, which will look weird.
- Shadows do not fade with distance to light source, they are always of the same color and opacity.
Pros/cons
- Shadows are always "hard" and pixel perfect, which is impossible to get with Unity shadows. This may be desirable, but probably won't look good in all situations.

What do you think about this? Would planar shadows be useful in your projects?

 

I would say so certainly. In fact I would simply author situations where they were!

Nice one

 

Definitely. I'm currently using Swift Shadows but having to generate bits of my characters and what they carry so the shadows look right. This would make my life easier!

 

Great asset ! We are glad to have bought it.

Why do you attach SS_CameraEvents to every camera in the scene ? When you only need to have it attached to the right camera.

Code (CSharp):

1. UpdateCameraEvents(Camera.allCameras);

Have it attached to every camera actually costs a lot and does nothing, or at least nothing more in our project.

 

How come it costs a lot? Do you have a lot of cameras?..
This component has to be present on each camera that draws shadows, because shadow culling and drawing must be done per-frame and per-camera

 

We have lots of cameras. We have change that line of code to only have SS_CameraEvents attached to the only camera that needs it. It works great so thx.

 

Ah, makes sense, thanks. I'm asking because I've redone this part of code quite a lot, so now I'll probably make it easier to select what camera needs shadows rendering until it's too late

 

Hey i have a weird issue, in the editor i can see the shadows while in play mode, but when i build and install it on a samsung galaxy s3 the shadows are not visible? I am using static vector as "light direction from", and i have no lights in the scene.

 

Hm, that's strange. Could you please try it on a different device and see if it works there? Or perhaps even a standalone build.

 

I tried on a Samsung Galaxy s5 also but stilll same thing, but i didn't have this isse before on the same project, it just appeared suddenly.

 

So does it only happens on Android, or on standalone desktop or webplayer builds too?
If possible, could you please PM me your project so I can investigate your issue? I'll have a better chance to find out quickly what's going on that way, as I can't investigate an issue that I can't reproduce, and I haven't encountered this problem before.

 

The shadows didn't show on standalone either, but i have tried removing some gameobjects from the scene now , meshes for example, and now the shadows work again on android, so it might have something to do with the memory or draw calls?

 

I'm sure it has nothing to do with memory or draw calls, especially when you say shadows were missing on standalone as well. But you know, I can't find out the real reason when I don't know to reproduce the problem. I'd be still grateful if you send me a reproduction project so we can find out the source of the problem without resorting to randomly removing objects

 

Oh this was actually caused by another asset i had in the scene that generates terrain in front of the player, i removed it and now they work fine !

 

Hi, I am having a problem with the shadow generator. While it is open I get this warning, Unable to find style " in skin 'DarkSkin' Repaint UnityEngine.GUIStylep_Implicit(String). Every game object I add to it only shows a black box. Happens in 4.6 and in the 5 beta. Any thoughts on this? Thanks a lot!

 

Just checked it. That warning is annoying, but harmless, it'll be an easy fix.
There were some fixed issues with the generator that resulted in black boxes, but the update is not released yet. Meanwhile, could you please try to create a new scene, add a standard cylinder at (0, 0, 0) position, and see if Shadow Generator works with it?

 

Thank you for the reply! The shadow generator worked with an empty scene and a cylinder, however once I added a more complicated object it went back to just generating a box.

 

Just as I suspected... This issue should be gone with the nearest update that I'm planning to release soon.

 

Sounds good, thanks a lot for the replies. Looking forward to the release.

 

Hi everyone,
update to version 1.1.0 is now live on Asset Store!

Changelog:

• Fully compatible with Unity 5, WebGL, and IL2CPP.
• Shadows now work in edit mode.
• Added option of shadow size scaling depending on distance to the ground.
• Added smooth shadow rotation option.
• Added support for assigning sprites as a shadow texture. Sprites must not be packed, and the materials' main texture must be the same as the sprite texture.
• Added a simple shadow atlas texture generator that also automatically creates sprites. Useful for assigning sprites as shadow texture.
• Rewritten shadow texture generator, handles uncommon cases much better.
• A lot of performance and GC allocation improvements.
• Having cameras that don't render shadows doesn't affects the performance now. Attach new NoShadowsCamera component on Camera if you want to be extra sure.
• Removed "Frame Skip" option since it wasn't working correctly and seemingly no one used it anyway.
• Improved inspector UI.
• Dropped support for Unity 4.2 and older.
• Dropped support for Flash platform.
• Moved the code into LostPolygon.SwiftShadows namespace.
• Code cleanup.

 

Patch update to version 1.1.1 is now live on Asset Store!

Changelog:

• Fixed an error when using “set to static if not moving” option.
• Disabled normal generation for the shadow mesh, since they aren’t used anyway.
• Fixed an error when there were no visible shadows.
• Minor UI improvements.

 

Did you ever finish the planar shadows thing? I know I should just check but I am currently failing to multitask...

 

It's planned, but without any ETA at the moment. However, I can't think of anything else to do improve with the current quad-based shadows, so planar shadows will probably be added in the next feature update.
After that, I'll probably try to add some more tricky fake shadows rendering techniques, with the idea of making Swift Shadows an ultimate fake-but-performant-and-still-looking-cool-enough-shadow-rendering asset. But that's a far-stretched plan

 

well I will tell you why.
I am currently tinkering with the guts of http://forum.unity3d.com/threads/50...wth-multithreaded-dynamics-prefab-use.287512/ and whilst obviously using your shadow solution is not going to be a "CORE FEATURE" I see no reason why it couldn't be a "happily supported extra"

However, without going into too much gory detail it is near impossible to know exactly what the mesh is going to look like before one starts the generation. It is, after all, moderately random.

This can cause some real heartache and headaches when doing very complicated and detailed trees.

One, current, pretty decent, solution is to not actually add Unity shadows to all aspects of the mesh as it is constructed/grown(whatever term you like). This keep the calls in the moderately sensible range but obviously will never work for mobile.

The demo is right there. You can see what I am thinking. A VERY rough set of planars just made once and scaled for the "less than a second" they are required would go a long way to a) make it be almost transparent in terms of performance and b) reduce the insane draw swamp that unity currently invokes and c) is the perfect test for a "fake-but-performant-and-still-looking-cool-enough-shadow-rendering"

No ? Right?

What do you recks?

 

Not sure I understood you correctly - how will the trees be rendered after they are grown? Won't it be the same amount of draw calls between a tree that is fully grown and a tree that is in the process of growing?

 

Ah, it seems like the tree meshes are combined into a single mesh after tree has finished growing. So I assume it's okay to draw Unity shadows on a fully grown tree, but not while it's growing, because a growing tree requires a lot of drawcalls? Well, in that case, I think you can actually do what you've asked with a current quad-based approach. Basically, just render a single frame of a growing tree into a texture, and use that texture as a shadow texture for Swift Shadows. It'll look as it should if set up correctly.
Planar shadows, however, can't be baked once - the whole point is that they work for dynamic objects just like Unity shadows do. Also, planar shadows won't reduce the amount of drawcalls - it'd be the same as with Unity shadows, but, of course, planar shadows are much lighter to render.
Oh, and, of course, all this will only work if you grow trees on a flat plane.

 

no they are combined at that point.
I was just wondering if you planar system would be a good solution for the interim meshes. I sense it would.

EDIT: ah yes I see you have noticed.



Yeah well "flatish", I would probably attempt to just partially mangle to any normals (I did read at length your original post on the matter) pretty good would be better than great and slow

Okay I will look to implement at some point then

 

Well, yes, I think it'd also be possible to render interim meshes with planar shadows, and switch to regular shadows once a tree has finished growing and its mesh is combined. That'd definitely add performance on mobile.

 

Hi, I just downloaded the Swift Shadow script and seems easy enough to implement but I seem to be getting some weird result. I was hoping you could help me solve this issue. I get a solid square shadow with a faded circle gradient in the middle.
any help will be appreciated.

 

Hi there,
that's a really strange issue indeed, shadow image alpha is inverted for some reason. I wasn't able to immediately reproduce it, and I haven't seen it before.
What OS do you use? Could you please try creating a new scene, create a standard, standard cube, attach Swift Shadows to that cube and see if it works correctly then?
EDIT: could you also show me a screenshot of Inspector for "Assets\SwiftShadows\Resources\Textures\SS_BlobShadow" image?

 

Hey thanks for getting back to me. Windows7 . created an new scene and got the same results. not sure what what is wrong.

 

Ok, I think I got it... For some reason it seems like the texture assigned to the Shadow Multiply material is from a set of textures that come with Standard Projects. That texture is indeed inverted compared to what it has to be in order to be used with Swift Shadows. Just reattach the standard "Assets\SwiftShadows\Resources\Textures\SS_BlobShadow" texture to the Shadow Multiply material and it all should be fine.

 

Yay ! totally worked Thanks.

 

I got the following error when I imported the plugin.

Assets/Standard Assets/Character Controllers/Sources/Scripts/MouseLook.cs(34,14): error CS0103: The name `SS_GUILayout' does not exist in the current context

 

Seems like in your project there is a GUID conflict between MouseLook script from the Standard Assets package and MouseLook script from the Swift Shadows package. The simplest way to fix this:
1) Re-import the Standard Assets package that contains the MouseLook script.
2) Save "Assets/Standard Assets/Character Controllers/Sources/Scripts/MouseLook.cs" somewhere else on your drive.
3) Delete that file from your project.
4) Re-import the Swift Shadows package.
5) Copy the MouseLook.cs file you've saved into original location.

 

Or add a namespace...

 

The issue isn't about the namespace. The script from the SwiftShadows package is actually named SS_MouseLook, the problem is - my SS_MouseLook and MouseLook from the Standard Assets both have the same GUID, since I've originally derived SS_MouseLook from MouseLook. So Unity just overwrites the file with the same GUID.
BTW, this behaviour is changed in Unity 5, such a problem is non-existent there.

 

I have an issue, sent an email to support but never get a reply so I will post here:
After add an ITween path the swift shadows behavior became weird. Check the video:

Tried everything to fix but no success. I hope you can help me. If you need my Invoice asset store number send me a PM.

 

@Zetax
Hi there,
just checked my email and couldn't find any relevant message for some reason. Probably something fishy on my side, sorry for that.
It's hard to say for sure, but it seems very similar to the issue @Zaddo67 was having at the first page of this thread. I'll quote myself: