Shadow Volumes Toolkit (now with stencil buffer support)

Great one, thanks Gustav. Here some first impressions.

Version 2.0 is for 3.5 and higher only, right? Importing it in 3.42 into a blank app throws me some errors:

Upgrading to 3.5 throws me some errors then too. Five or six of these ones here:

Thast`s why i guess the new version of your toolkit is for Unity 3.5. Definitely worth a note for those who stick with Unity 3.42 like me for the moment. Because the new version overwrites the old one. I am still at developing in Unity 3.42 because of the drawcall issues.

But creating a new 3.5 app and importing the toolkit is also not flawless. First thing i see is an error.

Let`s have a look if i can find the time to do some more tests today

 

Yes, thank you for reminding me of this. If you still want to use the new version on 3.42 you can remove the "BlendOp RevSub" line in all shaders that throws an error (should be 2) and always set your Compatibility Mode to No Blend Op, for all ShadowVolume and ShadowVolumeRenderer scripts. This is an ugly solution but it should work, the best solution is obviously to use 3.5

This I didn't expect and never experienced myself (I've imported the package in a few projects). This thread seems to indicate that it's a problem with having several versions of Unity installed at the same time. Do others experience this as well?

This error is harmless. The editor wants to render a preview of a shadow mesh and since it doesn't have uvs or vertex colors it throws a warning. I don't want to provide uvs/vc since they're not needed for the shadow meshes, so for now, just ignore these warnings

 

Thanks Gustav

 

So, can this work with multiple shadow sources?

Also, any word on iPad (2) performance? My game has pretty simple graphics, but torchlight (and resulting shadows) are pretty important. I have a solution that'll light up the ground, but if performance is ok this would be much nicer.

 

Not at the same time. You can have multiple shadow casting lights in a scene, but only one can be active at any moment.

I just signed up for the apple developer program and was about to test the toolkit on my iPhone 4S (similar performance to iPad 2 I believe) the other day, but I encountered the "splash screen" error using the latest version of XCode. I'll post the results as soon as I get it working..

 

Darn. My use case is that I have a small group of guys running around with torches, and no other light sources, and I'd really like to get it onto iOS while keeping a comparable visual effect.

 

Gus, would this system play well with toon shaders on iOS?

Thanks
AaronC

 

It should work. Every shader that writes to the depth buffer will work.

I haven't had the time to test the toolkit on iOS yet but I'm planning to examine mobile use more thouroughly some time in the future.

 

Hey! Decided to have a good go at using the toolkit in a game effort but i suppose my needs are a little nonstandard, i want something to navigate round shadows with the camera in an orthographic perspective and al action essentially '2D', so basically some way to detect if there's shadowed area behind the object. I was thinking if there was a mesh i could generate a sort of collision mesh and update it and do raycasts but its shaders so i'm not entirely sure how or if it can be done. If you had any ideas id be very grateful!

 

I would avoid creating colliders for the shadow volumes in real time, it would be really slow

You could shoot a ray from the object to the light source: if it hits any collider, the object is in shadow, otherwise, it's not. This solution requires that all shadow casters have colliders attached and in order to avoid conflicts, you could put all of these "shadow colliders" in a separate layer and only query this layer when calling Physics.Raycast().

 

The thing is that the object isnt in shadow its just testing if the bg area behind it is, its a great idea, mind, but the object i'm checking is moving on a 2D plane using an orthographic camera so the plane the object is moving on is actually far from the shadow volume itself, where the shadows are being cast are at an angle so to appear with any 'perspective' at all from an orthographic camera so i cant attach a child object behind the object to check

I have been trying to create another camera that only sees the shadow, putting it to a texture and ostensibly using getpixel on the texture and if its black where the object is in screen coords, its touching a shadoe area, but readpixels only captures what is visible rather than the camera that can only see the shadow

It would be nice to work this out, it would be a neat effect

EDIT: Ooop for anyone wanting to do the same, i kinda figured out a solution thats a bit clunky butt does the trick, which is what i said above, disabke teh second camera and just shoot Camera.Render() every so often its not fast though

 

Perhaps it's a good idea to add the following two items to the thread's poll?

- "The shadows look good (iOS / iPad 2)"
- "The shadows look good (Android)"

 

Now that unity 3.5.1 is out and the "splash screen" bug is fixed, I tried the example scenes on an iPhone 4S and I can confirm that the toolkit works and performs well! Just remember to enable a 32bit display buffer in the build settings.

Even though I have not yet tested it thoroughly, I believe the toolkit can be used for simple scenes, or on selected objects (characters for example) in more complex scenes, in games targeting the higher end iOS devices. (iPhone 4S, iPad 2/3)

Here are things you can do to improve the performance on mobile devices as well as desktop:

• Use as few shadow casters as possible / Remove unnecessary shadow casters (even if the shadow is not seen, it might impact performance)
• Use simple shadow volumes wherever possible (toggle in the inspector)
• Use low polygon shadow meshes wherever possible
• Try to minimize the number of screen pixels that the shadow volumes occupy, for example by using directional lights close to zenith

I think a new poll would be ideal really, otherwise the new options would impact the success/fail rate of desktop votes.

 

@gustavolsson,

My Android test device (Amazon Kindle Fire) arrived today and first thing I did was testing Shadow Volumes Toolkit on it. Unfortunately it didn't worked. Here are some details for you just in case those might help.

- Unity 3.5.1f2 on Windows 7 x64 with latest toolkit (2.0)
- Kindle Fire with latest software on it (6.3)

I have complied included demo scenes with following settings.

- Both Standard No Blend Op mode
- 32 bit display buffer checked unchecked
- 24 depth buffer checked unchecked

Combination of all above complied for ARMv7 + OpenGL ES 2.0 + Android 2.3.3 (API Level 10)

Best thing I've got was dark purple outline of the scene...

Any suggestions?

 

I'm sorry to hear that. Android is really difficult to work with when the graphics drivers differ so much from device to device. The toolkit only uses features that are part of the OpenGL ES 2.0 specification but some android devices just don't seem to implement it correctly. (The pink suggests that the shader won't compile on the platform)

Does the scene always show up as purple/pink? Even if you choose to use NoBlendOp mode on both the renderer and all the shadow volumes? Is it still pink if you remove all the shadow objects and only have the renderer in the scene?

 

Thank you for your reply. Actually I had an update to it but forum had a problem earlier today so I couldn't post.

When using NoBlendOp with 32 bit display buffer enabled (not sure about the 24 bit depth buffer now) I had a non-purple scene. But it was very very dark, only barely visible thing was the green box (that was animation demo scene).

I can try to post a screen shot if that helps...

 

I have the exact same setup (3.5.1f5) and I'm considering to purchase shadow volumes. Please post the screenshot so that this can be fixed.

 

He has the screenshots and looking at it. Apparently shadows are working with NoBlendOp mode but something else causing the screen goes dark.

 

Took me a while to come back to this problem. I am trapped at the moment in converting my old shadow setup to the new setup. I find the new way to setup things even more confusing described. Or better said still confusing described. So here are some thoughts. I hope you don`t mind

First, it doesn´t work to simply install the new toolkit and my shadows are back. They are gone with the new toolkit. And i get a bunch of errors. And even after going through them i have one or two that i cannot get rid of. See screenshot for the warnings. I wish i could attach an example scene. But my project has grown above the 1gb border now. Which is a bit too big for an attachment. But i want to redo all my objects anyways. So there is no real need to.

Back to the description in the readme. I think you should spend a few moments to write a better manual. Maybe with some images what to do where. I read a thousand times the word Shadow, and am not sure what to put where. Good would be for example to write where the scripts are located that you need to drag n drop around. Like

"Drag drop the ShadowVolumeRenderer script onto an empty game object (preferably called "Shadow Renderer")"
versus
Drag drop the ShadowVolumeRenderer script from the /CoreMain/Scripts folder onto an empty game object (preferably called "Shadow Renderer")

And as told, a little shot would be helpful here too. Saves me as the user lots of searching

Oh, and would you mind to create a little movie that shows the rigging of a skinned mesh too?

 

Hm, i run into some weird ingame flickering when the object angle is nearly aligned with the sun. Everything seems to be fine in the editor though. Here is no flickering. I can`t remember that i had this problem with the old version.

A workaround seems to scale the shadow object a tad bit smaller. From 1 to 0.9999. But then it doesn`t exactly fit anymore. Which is no go for my skinned objects.

EDIT. correction, i have also some odd Editor flickering when i go close to the alignment with the sun. See the shot with the diagonal lines. For that i need to go really close to the alignment angle though. While for the ingame flickering it is enough to go close for 10 or 15 degrees.

 

My bughunter blood strikes back

The tooltip for the extrude bias setting is cut off

 

Since I rewrote the whole toolkit for version 2.0, you'll have to remove the old package from your project, remove all scripts that referenced the old package and then import the new package and set up your shadows again. This should hopefully be much more convenient this time around, though.

Thanks for the feedback. I wanted the read me to be short and to the point but I can understand if it's difficult to follow. This is why I made the instruction video I'll update the website and the read me when I have a little more free time. I'll also see if I can make video on how to set up a skinned shadow mesh, even though it isn't very different from a non-skinned set up.

This is called depth-fighting and will occur whenever two surfaces line up close to each other. It's usually visible when the game uses a strange projection matrix. Select your camera and make sure that the Near and Far values are reasonable. A near value of 0.1 and a far value of 1000 should definitely work. Try lowering the far value if it still doesn't work on mobile devices. If you need a large far value because 1 unit is not 1 meter in your world, increase the near value appropriately. Also increase the rotation of the sun by a tiny amount if it completely lines up with the boxes.

The reason that it is visible more often in the editor (to me it is at least) is probably because the editor has a long viewing distance.

Also, if there is similar aliasing on surfaces that are nearly perpendicular to the light direction, increase the Extrude Bias on the ShadowVolumeSource script to fix it. (It does not seem to be the case in your project, though)

That's nothing I have control over I'm afraid Try scaling the Unity window and see if it helps, otherwise look in the ShadowVolumeSourceEditor.cs file for the tooltip.

Hope this helps

 

Thanks for taking the time to reply Gustav

Near and Far clipping. I was already at 0.3 and 1000. Reasonable. And my whole game follows the meter system. Means my character is around 2 meters tall. Lowering the far clipping doesn`t change anything. Increasing the near clipping value does change something. But i have to go to 3 to get rid of the flickering that way. And then the objects clips away too early when i pass them. I have to go back to 0.3. Rotating the sun doesn`t really help neither. The cubes can be moved and rotated around. Increasing the extrude bias gives very visible results though. Same goes of course for scaling the shadow geometry smaller. The shadow doesn`t really match the geometry then anymore.

The funny thing is the flickering is definitely less visible with the old shadow system and in 3.42. There it is this small that i haven`t really noticed it before. Odd.

 

Strange.. what platform are you targeting? Does it work better when switching to another?

 

My target platform is Windows Standalone. But that shouldn`t influence anything at the moment. The shots are from within the editor. The flickering is of course also visible when i build an exe. And i cannot really switch to another target platform. I don`t have an android or iOS

Hm. The farer i am away, the stronger is the flickering with the new system. Maybe something is involved that has changed with 3.5?

EDIT, i have rotated the sun away a bit now. That way i can somehow live with it.

 

Different platforms have depth buffers of varying quality. Low quality depth buffers are more prone to depth fighting and flickering. The editor has a camera with greater viewing distance than a typical game (I believe) which is probably why it's more noticeable there.

That's because there is less precision towards the end of the depth buffer, it has nothing to do with Unity or the toolkit. Objects further away are more prone to depth fighting

Hm, are you sure the problem is more severe in the new set up? I haven't changed the shadow generation code from the earlier version, so it should behave the same.

I haven't really noticed the problem much, and it should definitely not be unbearable. I'll have to look into this more thoroughly

 

At least for me it looks like that. I have the same scene in 3.42 with the old shadow system, and 3.5 with the new shadow system. And in 3.5 it is more visible to me. Would be interesting to hear from others if they have the same problem.

EDIT, hmm, i take that back. I made some further tests, and there it was equal strong in 3.42 and 3.5. Odd. Sorry for confusion and trouble.

But don`t stop to look into the problem. A better solution is still very welcome

 

Would it be possible to make a layer and/or tag system so the shadows dont cast on an object with a tag/layer? I'd like that.

 

No, unfortunately.

However, if your object uses a transparent shader (that does not write to the depth buffer) it will not receive shadows, even if it's completely opaque. For example, transparent water won't receive shadows. You can use this to your advantage

 

Android demo works perfectly, on my 1.2 GHz tab, OpenGL 1.1, 512mb ram, Android 4.0.3

 

How would I prevent things like this from happening? I made a lowpoly version of the car. That's why i need the shadow to not cast on certain objects.

 

I got loads of pink errors - was dropping all the files into an existing project, and everything was turning pink and throwing a fit at me.

Then I did what Joakim suggested and started a new project, ticking the ShadowVolumes Toolkit box as I did so, and all worked fine - thanks for your comment Joakim. And Gustavolsson perhaps you could add something to your readme to encourage others to do this? It did cost me a good few hours today... Cheers tho - very nice work!

 

This will affect all shadows, but try increasing the Extrude Bias of the ShadowVolumeSource slightly (under the Advanced tab).

It should also be possible to lower/scale down the shadow game object.

Yeah, I will add this to the read me. Thanks

 

Thanks Gustav

After a bit more work with the toolkit, I realised that after I have started a new project and ticked the box for the ShadowVolsToolkit, then if I wanted to import another set of scenes and assets that I was previously working on and wanted to add shadows to, I could only get them to come in perfectly if I took the project that I was trying to import, and packaged it up, and then imported it into the new ShadowVolsToolkit project as a package.

Previously I had tried just dropping in all the assets and scenes as a bunch straight into the new project, but of course all of the meta-data (links showing what the textures on the surfaces where etc) was lost when I did this.

Then, just to see if it would work, I tried making ShadowVolumesToolkit.unitypackage to see if I could do the whole thing the other way round - build the game I wanted, and then add the shadowVolsToolkit at the end, imported as a package. This didn't work - everything went pink in the basic example - not sure why - but would be cool if this could be made to work, or you also shipped the ShadowVolumesToolkit.unitypackage file with the rest of the files.

 

This sounds really strange.. I have a ShadowVolumesToolkit.unitypackage that I import into my projects all the time and I never get any errors.

Your game project settings are probably set to low for the shaders to execute, make sure that you have at least OpenGL 2.0 enabled in the build settings and quality settings. What platform are you targeting?

 

Any more possibilities to making it faster? I went from 250+ fps to only 50 fps with 4 shadows when I enabled the shadow renderer.

 

Nope. Shadows are generally quite performance hungry and the toolkit has a bit more overhead than normal shadow volumes since it is implemented using the alpha channel instead of the stencil buffer. (The stencil buffer is unavailable in Unity)

Make sure that you use the Standard compatibility mode and that you've tried to minimize the following:

One thing I forgot to mention is that the resolution of the game influences the performance quite noticeably when using the toolkit. This is because shadow volumes are essentially raytracing (not traditional raytracing) every pixel to determine if it's in shadow or not as opposed to shadow mapping, where it is possible to have a shadow render texture that is smaller than the viewport.

So, try running your games at a fixed (lower) resolution, like 1024x768, if you're experiencing bad performance. This also applies to the editor, so if your game is fullscreened when the play button is pressed, you'll get worse performance than if it is not.

 

My game runs standard at that resolution. Also all my shadow meshes are extremely low poly. but performance still isn't the best.

 

Hi gustav - sorry but could you tell me how to check my project settings for shaders, and find the OpenGL setting?
I'm on OSX, and just using the in-unity game test for now (not even compiling yet). 2009 MacBook Pro, Snow Leopard, Unity version 3.5.1f2

I just reproduced this effect again - I'd upload you the unitypackage I've made, if it wasn't for the licensing / open forum etc. - let me know if I can send it to you directly.

 

My turn on Android

I'm getting blank screens / purple screens also - just like what was described a few posts back on the kindle fire.

My deets
- Unity 3.5.1f2 on Mac Snow Leopard x64 with latest toolkit (2.0)
- Sony S tablet with latest software on it (Icereamsandwich - 4.0.3)

I have complied included demo scenes with following settings.

- 32 bit display buffer checked unchecked
- 24 depth buffer checked unchecked

Combination of all above complied for ARMv7 + OpenGL ES 2.0 + Android 4.0 (API Level 14)

With 32 bit unchecked, I just get a black screen, with nothing happening at all (whether the 24 is checked or not)
With it checked I get pink objects as if the textures have all been lost at project import, but worse the shadow casting looks wrong too. I can see all of the objects on the screen tho, and the star is animated (moving around) as it should be.

I don't know where to find "- Both Standard No Blend Op mode" as Pixel Envision described within unity I'm afraid.

I can share some screenshots if that helps? Thanks

 

The Compatibility setting is located on each ShadowVolume script as well as on the ShadowVolumeRenderer script. Try building with the following settings:

- 32bit display buffer
- OpenGL ES 2.0
- The Compatibility property of all scripts set to No Blend Op

The other values should not matter. Hope this helps!

 

Thanks Gustav, working now. S

 

I am unable to get the shadows for my character which has animation in it. I am able to get shadows for other static objects. Any help would be appreciated.

 

Some Configuration for your reference:
a. Unity 3.5.2
b. Mac OSX Snow Leopard

 

Hi Gustav,
We had bought your shadow solution and tested on iPad 2 and iPhone 4S. The shadows show up on both the devices.

However, when I used the shadow mesh created from our character model using the "shadow mesh creator". I see only self-shadow and little shadow under the feet of character when character is approximately an inch away from the ground.




On the other hand if I use the same character mesh as shadow mesh, I get a shadow, but then there are holes in that shadow and some silhouette edges missing etc.

I tested the the shadow on the animated star mesh that comes with the test assets and it works fine.

Note that,
- I followed the procedure mentioned in the readme.txt to get shadows.
- When I used shadow mesh creator to create shadow mesh from our character model, it created a very small model (as small as a dot, from what I see in the preview window )
-The parameter extrude bias only offsets the self-shadow and changing extrude amount has no effect.

Please help. I am in the process of evaluating performance metrics for our projects that will help us determine budgets and if we did it with working shadows we'll know how much head space we need to create for it early on.

 

This might have to do with the scale of the character mesh. Do you scale it manually using a game object or using the import settings of the model? I would suggest not scaling it using a game object, only in the import settings. This way, the new shadow mesh will be the correct scale already, and the shadow shader will work properly (the extrusion of the shadow works in local space). Also make sure that you've connected the MimicSkinnedMeshRenderer script to the shadow SkinnedMeshRenderer and set it up properly.

If it still doesn't work please contact me directly at my website

 

Could you elaborate a bit more on the problem? What is it that does not work? Have you followed the instructions in the readme file?

You could also contact me directly at my website, see the above post

 

I had some holes in my shadow on my skinned character as well.
http://forum.unity3d.com/threads/141064-Shadow-Volumes-artifacts?p=963896#post963896
The link is the thread with more details.

 

Does the edge of the shadow appear jagged when the mesh is not animated, when it stands in it's T-pose? To find out, use a non-skinned shadow volume game object in which the mesh filter uses the skinned mesh in question.

I believe that the problem occurs when the skinned shadow mesh is transformed. Ideally, special care should be taken to the normals of the mesh in order for it to be extruded properly, but since Unity handles the skinning it's not possible. I will look into the issue but I'm afraid it's unfixable as it is.

 

It didn't make any difference.
It's not that noticeable to someone just playing the game so it shouldn't be too bad.