Shadow Volumes Toolkit (now with stencil buffer support)

I'm happy that you got the shadows to work!

Now, if I had only read the other thread that covers the new stencil buffer support more thoroughly I would probably have found the solution to the problem much earlier The following fix solves the iOS stencil buffer support according to noisecrime:

Could you try the above fix with the Stencil Buffer backend and see if this solves the problem for you?

 

Well what do you know...the only checkbox I didn't click! I had the cursor over it and decided that wasn't going to help...you know why? Because I misread it and thought it said 'display buffer', and by my logic if 32 bit didn't work why would 24 bit?

Haha well this is actually awesome since it dropped my drawcalls down from 32 in my test scene to 19, so Stencil is a definite win.

Thanks again Gustav and good find man!

-Steven

 

Great! I will add this to the readme and the website.

As for the difference between the backends, here is a short simplified summary:

Basically, the idea of shadow volumes is to extrude geometry that is not facing the light away from the light, creating a volume. This volume is then rendered from the camera's point of view in order to, for each pixel affected by the volume, determine if a ray from the camera enters the volume and intersects the world before leaving the volume. If it does, the pixel is in shadow. Note that everything, including the intersection tests, happen on the GPU using the normal graphics pipeline, so performance is great.

To determine if a ray from the camera intersects the world before leaving a volume, a variable for each pixel is used to keep track of how many front facing volume triangles the pixel/ray has entered and how many back facing volume triangles the pixel/ray has left. In the toolkit, the Alpha Channel backends store this variable in the alpha channel of the display buffer and thus requires a 32bit display buffer (8bit red, 8bit green, 8bit blue, 8bit alpha). The Stencil Buffer backends store this variable in the stencil buffer. The reason the toolkit performs better when using the Stencil Buffer backends is that the stencil buffer is more flexible when it comes to manipulating and checking the stored value.

Special care has to be taken when extruding the volume (The reason there is a shadow mesh) and when the camera is located inside a volume, but I think this pretty much sums it up

 

That is an excellent explanation thank you!

I must ask, and again if this was discussed earlier I hate to have you repeat yourself, but do you have any tips for both optimal performance and 'things to avoid'?

I'm already seeing potential problems, having to create a 'shadow mesh' for each object I want to cast shadows. Obviously I would minimize the number of shadow casting objects, restricting it to say, larger set pieces, or pre-combing meshes, but I also want to enjoy the benefits of using prefab instances to quickly construct my worlds, and of course what comes from frustum culling and batching of smaller individual objects. What would do you think would be an ideal approach?

Thanks so much for your time, really.

-Steven

 

No problem

You only need to create one shadow mesh asset for each unique mesh asset in your game. The shadow mesh asset is saved to your project folder structure next to the source mesh asset. Frustum culling and batching will just work, no need to do anything.

So, say you have a game object that uses a pyramid mesh asset for rendering and that you would like the game object to cast shadows. You only need to create a shadow mesh asset once for the pyramid mesh asset, no matter how many pyramid game objects you would like to have. Once the game object has a ShadowVolume component that is linked to the new pyramidShadow mesh asset, you can duplicate it or make it a prefab without having to worry about "losing" the shadow mesh. (The key here is that the shadow mesh is saved as an asset, not a runtime mesh)

Now that the pyramidShadow mesh asset has been created, you can also create a game object from scratch: just attach a MeshFilter component (select the pyramid mesh asset for rendering), a MeshRenderer component (select some material) and a ShadowVolume component (select the pyramidShadow mesh asset as "Shadow Mesh").


In short: Just use the Quick Shadow Setup dialog and make prefabs whenever you want to

 

Great.

Now it's still safe to assume that each Shadow Mesh is another draw call(or more?) correct? Are they effectively 'meshes' that too can get batched and culled?

All in all I'm quite happy with how this turned out.

-Steven

 

Yes, they're just submitted to the renderer as any other mesh but they are rendered using custom materials/shaders of course. I think shadows will be batched as long as the vertex count of the shadow mesh asset is below 300. I'm not sure since the line on multipass shaders in the documentation on batching is quite unclear.

I'm happy that you like the toolkit. Feel free to post a screenshot of your game with shadows in the future

 

Yea the vert count (of the shadows) is the only thing of course stopping it from batching with each other.

Maybe I should stop being lazy and test this myself huh? Haha, and yea I'll definitely give you a heads up with your Shadows in action when I finally reveal what I'm working on.

Thanks again Gustav

 

Hey Gustav, quick question.

Is it possible to have a mesh 'not' receive the shadow geometry?

As it is now, while I do enjoy having self-shadowing, and in fact prefer it, some meshes don't respond very well to them (with stencils). This is more a me thing (art) and not your shadow implementation, but regardless, being able to turn off shadows on a per-mesh basis would be ideal.

Thoughts?

Thank you!

-Steven

 

Yes, this is the way I do it in my current project:

I use 2 cameras, one to render shadowed/receiving geometry (static game objects in my case) and one to render unshadowed geometry (dynamic game objects in my case). The 2 cameras are parented to the same game object so that I can control the view without having to change 2 game objects each time.

Here are the settings I use for each camera:

Main camera: Culling Mask: Everything except the "Dynamic" layer; Depth: -1;
Dynamic camera: Clear flags: Don't clear; Culling Mask: "Dynamic" layer only; Depth: 0;

Because shadows are rendered in the "Default" layer, dynamic game objects will not receive shadows. The next update of the toolkit will let you choose which layer the shadows are rendered in as well, in case you need to use more complex camera setups. Note that while the self-shadowing is gone in the game view, it is still present in the editor scene view since it only uses one camera. Also note that while dynamic game objects do not receive shadows, they can still act as shadow casters!

Hope this helps

 

its cool. i get like extremely high fps. is it possible to blurr the shadows and than getting a result of soft stencil shadows. it would be perfect for indie developers!(maybe).

 

Here is what I wrote on the previous page:

 

Looks like an amazing asset. Thinking of buying it for use in my project! .
I have one query though, looking at the webplayer , the shadows were quite harsh/hard shadows. Using this asset, are you able you get soft shadows?

Hawx
Unity Indie Version

 

Unfortunately, not in Unity Free. It is possible to smooth the shadows (I'm currently evaluating it) but it has to be done in a post-processing pass, which is only possible in Unity Pro.

Thanks for the interest in the toolkit

 

Hey Gustav! Quick question, and I promise I searched first!!

...but is there a way to keep the shadows from being culled when they are off camera? Obviously this is important for large shadow casting objects like mountains, buildings and large trees.

Thanks again for you time man

-Steve

 

Sorry I wrote that quickly and poorly:

I meant to say when the shadow casting object is off-camera, not the shadow itself of course.

Thanks man

 

...hmmm looked again and I realized it must be something I'm doing. The shadow does stay visible even when the shadow caster is well off camera and culled. Certain camera angles though seem to cull the shadow (I'm assuming it's being culled as it disappears completely), but the angle is arbitrary.

The same rotation angle on X (Pitch) lets say, but any direction around on Y (Yaw) will give varying results. Two 'sweet spots cause the shadow to disappear but otherwise every other direction around Y it's fine. There's nothing unique at all about those two directions. Pitching up or down of course changes the results as well, so it's very odd this appears so specific.

Anyway any insight you may have on culling or anything else relevant to your system probably will still be helpful.

Thanks yet again

 

Try increasing the "Bounds margin" value in the Quick Shadow Setup dialog and recreate the shadow meshes. This will extend the bounding box of the mesh so that it will not be dynamically culled even if the actual original vertices are off camera. The default value is 2, which means that all shadow mesh bounding boxes are extended by 2 units in each direction.

Increase it to say 100 and see if this solves your issue. Let me know how it goes

Btw: My first experiments with soft shadows for Unity Pro users seem promising. Compared to Unity's built-in soft shadows, these are smoother and less noisy. The drawback is that the penumbra/umbra is not correct. A bit more work and it will end up in the next version of the toolkit

 

Dang that didn't do anything. Rather there was no noticeable difference to conclude that it's the bounding margin.

Is there a limit to the size? I tried 250 but again seeing no difference I thought perhaps it wasn't actually working at that point.

Boy I hope this isn't going to be a problem. This tool has been a huge boon to my development.

Cheers

-Steve

 

Setting Bounding Margin to 1000 (one-thousand) seemed to do the trick! That or I was updating my shadow volume information incorrectly.

Now, and maybe this was me all along (no surprise), but when you recreate the shadow mesh, do I need to delete the old one or anything else for that matter? What would be the correct procedure to ensure that you have a new, clean shadow volume?

Thanks Gustav!

-Steve

 

The scale of the bounding box is in local mesh coordinates, so if you scale the game objects using the transform component, large values may be needed for the "Bounds Margin". Glad it worked!

Nope, if there already exists a shadow mesh asset it will be updated so that references are not lost. However, if you manually move the shadow mesh asset to another folder the script will create a new shadow mesh asset at the original location (so there will be 2 duplicate assets in this case). The shadow mesh asset will be created next to the reference model in the project folder hierarchy.

 

Hmmm I'm rather thorough with my mesh data prior to exporting, so my models are definitely correctly scaled but regardless it works and very well I might add

 

So it appears that the shadow volumes in fact don't batch. I wasn't working specifically on level art and thus shadows, but doing some routine profiling before bed, I ended the night with a quick peek at my stats and noticed I couldn't necessarily account for my draw calls. Went through each object on the screen and yadda yadda, I won't bore you with the nitty gritty details but I eventually came around to your shadow volumes...

Long story short, while my object is getting batched, its shadows are not. I pasted the prefab down several times, and my draw calls went up by 2 for every new shadow casting object. Again the new objects got batched (1 draw call total) but each shadow volume was still adding 2 draw calls (Is Simple would be only 1 added draw call but I need for the camera to be able to enter the shadows).

Do you have any thoughts on perhaps how you could optimize the tool to somehow support batching, or what I could do on my end short of manually combining objects together so as to make fewer shadows volumes?

Again fantastic tool but I'm worried as the project grows that I'll need those draw calls back...then again maybe I'm being premature.

Thanks Gustav

 

For some reason when I set the volumes to the new Stencil Buffer backend, the entire scene gets a giant shadow spread across it in the "game" view.



If I change it to the Alpha Channel it appears to work correctly, but I'd like to be able to use the stencil buffer for the performance increase!

 

Did you uncheck 'Is Simple' on the shadow volume script?

'Is Simple' is what allows the camera pass into and out of the shadow volume. Check it only for objects that are either far away or are small enough that the camera will never be 'inside' the volume, otherwise leave it unchecked. Be aware that 'unchecked' doubles the drawcall for that shadow (from 1 to 2 calls).

-Steve

 

Gustav? You haven't left us have you!?

Another question, and perhaps I'm simply failing to see the reason right in front of me, but this is puzzling me...



...but why does the Shadow Volume Renderer (Script) take 2 drawcalls, including reporting 4 triangles and 8 vertices? The shot is the project running in Game View from the main camera, and if I were to disable the Shadow Volume GameObject, I would get those 2 drawcalls back and Stats would report zero drawcalls as it should.

Otherwise, every single object in my game is deactivated, including of course the two shadow casting objects and yet here we are burning 2 drawcalls for no reason I can honestly fathom.

Could you either elucidate this for me as to why there are any drawcalls for this GO, or see if this is in fact an unintended feature in your code?

Also just as a reminder I have a concern in my last couple posts above from a week ago, if you wouldn't mind.

Thanks Gustav

-Steve

 

Unchecking "Is Simple" doesn't seem to change anything. My camera is pretty far away from any objects in the scene so it's definitely not inside of any volumes. Also, everything appears to work perfect using the Alpha Channel setting.

 

Shoot I don't know then.

Hopefully Gustav will make an appearance otherwise I'm no help then, sorry.

-Steve

 

Sorry for the absence. Unfortunately, working on the toolkits is not my full time occupation, yet

Honestly, I haven't prioritized batching before and expected it to just work. Thanks for taking the time to thoroughly examine it. Now that the toolkit is used for mobile devices, I agree that it is important. I will look into this over the weekend and report back!

The ShadowVolumeRenderer component is required to 1) Clear the stencil buffer before use 2) Compose the contents of the stencil buffer with the contents of the screen. Thus, the game object will render 2 full screen quads (4 vertices and 2 triangles each). It is not possible to batch these calls since they happen in different render queues and using different materials.

Unfortunately, the stencil buffer backend does not work with Deferred Rendering, is this what you're using? I will look into this over the weekend as well and see if there is any way around it.

 

Perfect! Wow, if you could get batched shadows to work that would be absolutely huge, and yes especially for mobile. Right now performance is fantastic so this would only be that much the better...

...and two fullscreen quads; makes perfect sense thank you Gustav!

Cheers and good luck this weekend! Hehe

-Steve

 

So, it appears that Graphics.DrawMesh() does not support dynamic batching (yet?). This is unfortunate since the toolkit relies on this method for shadow rendering. As DrawMesh() simply submits render jobs to the standard render queue according to the documentation, I see no reason for Unity not to add support for batching in the future. Thus, I will not change the toolkit to permanently work around this issue. (Also, the benefits of using DrawMesh() instead of tons of game objects in edit-mode outweighs batching in my opinion)

Instead, I created a script to work around the issue. It basically uses game objects and MeshRenderers instead of DrawMesh() when the game is in Play-mode. The drawbacks of this work around are: 1) A lot of new game objects are created at scene start 2) It is not possible to change ShadowVolume.ShadowMesh, ShadowVolume.IsSimple or ShadowVolumeRenderer.Backend and have it affect the actual shadows during runtime. These settings will have to be made in edit-mode. I think this is a fair compromise to get batching up and running

Here is the script, just attach it to all game objects with a ShadowVolume component and press Play to see the results.

Code (csharp):

1. using UnityEngine;
2.  
3. [RequireComponent(typeof(ShadowVolume))]
4. public class ShadowComponentToGO : MonoBehaviour
5. {
6.     public void Start()
7.     {
8.         ShadowVolumeRenderer shadowVolumeRenderer = ShadowVolumeRenderer.Instance;
9.  
10.         if (shadowVolumeRenderer == null)
11.         {
12.             return;
13.         }
14.  
15.         ShadowVolumeBackend backend = shadowVolumeRenderer.Backend;
16.         ShadowVolume component = GetComponent<ShadowVolume>();
17.  
18.         GameObject shadow = new GameObject("Shadow");
19.  
20.         shadow.transform.parent = gameObject.transform;
21.         shadow.transform.localPosition = Vector3.zero;
22.         shadow.transform.localRotation = Quaternion.identity;
23.  
24.         shadow.AddComponent<MeshFilter>().sharedMesh = component.ShadowMesh;
25.  
26.         Material[] materials = null;
27.  
28.         if (backend == ShadowVolumeBackend.StencilBuffer)
29.         {
30.             if (component.IsSimple)
31.             {
32.                 materials = new Material[] { component.stencilFrontBack };
33.             }
34.             else
35.             {
36.                 materials = new Material[] { component.stencilBackFrontAlways, component.stencilFrontBack };
37.             }
38.         }
39.         else if (backend == ShadowVolumeBackend.StencilBufferNoTwoSided)
40.         {
41.             if (component.IsSimple)
42.             {
43.                 materials = new Material[] { component.stencilFront, component.stencilBack };
44.             }
45.             else
46.             {
47.                 materials = new Material[] { component.stencilBackAlways, component.stencilFrontAlways, component.stencilFront, component.stencilBack };
48.             }
49.         }
50.         else if (backend == ShadowVolumeBackend.AlphaChannel)
51.         {
52.             if (component.IsSimple)
53.             {
54.                 materials = new Material[] { component.alphaFront, component.alphaBack };
55.             }
56.             else
57.             {
58.                 materials = new Material[] { component.alphaBackAlways, component.alphaFrontAlways, component.alphaFront, component.alphaBack };
59.             }
60.         }
61.         else if (backend == ShadowVolumeBackend.AlphaChannelNoBlendOp)
62.         {
63.             if (component.IsSimple)
64.             {
65.                 materials = new Material[] { component.alphaFront, component.alphaBackNoBlendOp };
66.             }
67.             else
68.             {
69.                 materials = new Material[] { component.alphaBackAlways, component.alphaFrontAlwaysNoBlendOp, component.alphaFront, component.alphaBackNoBlendOp };
70.             }
71.         }
72.  
73.         shadow.AddComponent<MeshRenderer>().sharedMaterials = materials;
74.  
75.         component.enabled = false;
76.     }
77. }

 

Two things (and awesome btw I think)

First, I got this error:

Second, does this mean were I to use this script I would get batching but I wouldn't be able to move the light-source and have the shadows update? In other words completely static shadows, akin to 'lightmapping'?

Funny too about isSimple, as I was already modifying that at run-time when you were far enough away from a shadow volume the camera couldn't possibly be inside, thus saving calls there.

All in all though it sounds like perhaps your toolkit might already be more efficient as-is, at least thats what I got from your comment about DrawMesh(). What are the benefits of DrawMesh() out of curiosity?

Thanks Gustav!

-Steve

 

I commented out the 'layer' line just to see if it mattered, attached to the script to all the objects I have casting shadows (Shadow Volume (script)) and there wasn't a difference in drawcalls, but again I might have made it malfunction by removing that single line.

 

Yeah, I forgot that I was working on a newer version of the toolkit, just comment out the line regarding Layer

The shadows are still dynamic so you can move the light and objects around, but IsSimple can not easily be toggled. You can disable shadows by disabling the "Shadow" game object that replaces the component when using the work around script.

You'll only see batching working in play-mode, since the work around script is play-mode only. In my test case (10 shadow casting cubes with a per pixel point light) I get 44 draw calls in edit-mode and 26 in play-mode so batching is definitely working in that simple scene. I've noticed that the Stats window will not always update in edit-mode though, so I have to move around an object in the scene view slightly to get it to update the number of draw calls. Also, keep in mind that Unity will only batch shadow game objects together if the shadow mesh they reference contain less than 450 vertices, and that shadow meshes in almost all cases have a higher vertex count than the original reference mesh.

Could you try a very simple mesh (like a cube as I describe above) and let me know if it works?

 

The benefit is that the shadows do not have to have their own game objects. The alternative to DrawMesh() is to have a shadow game object as a child to each game object you want to cast a shadow. Previous versions of the toolkit was designed like this but the workflow was worse since you could accidentally select a shadow game object instead of it's parent. It clutters the scene and hierarchy view with unnecessary game objects.

Regarding efficiency: Tons of game objects only used for rendering is a lot of unnecessary overhead, but I'm not sure DrawMesh() is faster because it lacks batching. Difficult to tell, as batching depends on shadow mesh complexity.

I think it's more probable that the game will be limited by the graphics card fill-rate before the number of draw calls start to cause a problem. I recommend running the toolkit as-is (with the IsSimple toggling trick you suggested) until you run into performance problems that can be attributed to draw calls

 

Hey Gustav! Yea I'll make another go at your script today, but I'm starting to get the feeling that yea maybe it really is better (simpler?) to just go the original route...I'll do that test and let you know.

...and just to be clear, my apparent obsession with drawcalls is due to my project being mobile. On a PC I honestly wouldn't give drawcalls a second thought.

Thanks man!

-Steve

 

Hmm I am not using deferred rendering, I am set to forward rendering and building to Android usually for testing outside of the Unity editor (tested on Tegra 3, Mali-400, and PowerVR SGX540 units)

 

Have you enabled the 24bit depth buffer in the Android build settings? (The stencil buffer backend requires this setting whereas the alpha channel backend requires the 32bit display buffer. You only need to use the one of the two corresponding to your Backend setting)

 

Thanks, that looks like it fixed it!

Unfortunately it appears that Tegra 3 doesn't support stencil buffer access so I will likely end up using Alpha Channel anyway....wish I could just drop Tegra 3 support but there's just too many Android devices using it to ignore :???:

 

I just submitted an update to the toolkit. The major new feature is support for non-two-manifold source meshes. It should now be possible to use any mesh with the toolkit

Shadows from non-two-manifold source meshes will look just as good as those from two-manifold ones, but the geometry generated for the shadow mesh will be roughly twice that of a two-manifold counter-part.

Here is the changelog:

 

They're sure taking their time huh? Checked the store and it's still 'Import' (vs. Update)...

 

The update should now be live

Here is the change log again:

 

Awesome...

...and just to be safe, is there anything we should do to update (e.g. remove the old version) or just import and go?

Thanks Gustav!

-Steve

 

Well I installed over the old one so never mind about my last question.

...but the docs don't appear to reflect the new additions/changes, and when I tried adding the ShadowComponentToGO script to the shadow casting object, the drawcalls didn't change. Is there a procedure other than adding the script?

-Steve

 

The help blurb in the Quick Shadow Setup dialog now states that the meshes no longer have to be two-manifold. The ShadowComponentToGO script is nearly identical to the one I posted before. Here is a simple test case:

1. Create a new project and import the Shadow Volumes Toolkit
2. Create an empty game object and attach the ShadowVolumeRenderer script to it
3. Create a new cube game object and use it as the floor
4. Create a new point light game object above the floor and attach the ShadowVolumeSource to it
5. Create 3 new cube game objects above the floor and use the Quick Shadow Setup dialog to set them up as shadow casters
6. Press play and note the number of draw calls, then go back to edit mode
7. Add the ShadowComponentToGO script to all 3 game objects acting as shadow casters
8. Press play and note the number of draw calls

When I repeat the above and use the Stencil Buffer backend, I get 16 draw calls before attaching the ShadowComponentToGO script and 12 draw calls when it's attached. Could you try this and see if your results differ?

As a side note: I discovered a bug related to inconsistent normals in the new shadow mesh generation code, so I'm working on yet another update (EDIT: I've now submitted the fix to the asset store as v3.2)

 

Hello Gustav,
I have got two clarifications to ask before buying your tool.

(1) In Android, when two of your shadows overlap, is the resulting shadow of the same color everywhere or can you see (in Android) where the shadows overlap (due to the intersections being double-dark)?
(I can see from the images on the Asset Store that, on Windows, the shadow intersections are not visible but I wish to get your reassurance about Android).

(2) In my game, I have got procedural meshes and their shadows never change (because the light and the objects do not move, just the camera moves). Is your tool capable of computing the self-shadowing once and for all, hence saving a lot of time each frame after the initial setup?
I mean, is it much faster than Unity shadows, after the initial the initial setup when shadows do not move and your mesh does not need to be modified?
I am asking because Unity self shadows must be calculate every frame.

Thank you in advance for the clarification.

 

I answered these questions via email but I though I would post them here as well, in case anyone is interested.

The shade of the shadowed areas should always be the same. No areas should be "double-darkened". The toolkit should produce the same image no matter which platform is used. That said, the quality of OpenGL ES drivers vary considerably on Android devices so I recommend that you test the toolkit on most target devices before releasing an app. I can send you an apk demo scene if you would like to test it before buying, just contact me through the website.

There are currently no special optimizations in place for static geometry. It is possible to save quite a few shader instructions and a lot of geometry if the game object and light remains static. It is not possible to omit the fill-rate heavy GPU passes as long as the camera is dynamic though, so I'm not sure how great the performance improvement would be in practice. This is something I'm going to look into for the next version of the toolkit. However, I've spent a lot of time updating the toolkit recently so I'm going to focus on other projects for a while now. I will post in the forums as soon as I've made any progress


By the way, version 3.2 with improved shadow mesh generation is now live. It should now be able to handle any mesh you throw at it

 

EDIT - Useless info...it was dynamic batching that I failed to notice...

 

EDIT - Useless info...it was dynamic batching that I failed to notice...

EDIT2 - Alrighty, it looks like it's not your toolkit, but rather the dynamic batching limit of 300 vertices in Unity. I kept adjusting the vertex count of the object and importing it and regenerating the shadow volume to get it as close to 300 as possible...

...351 verts for the shadow object...no batching
...288 verts for the shadow object...batching

Phew!!

 

Oh and just to allay your fears about addressing all my rambling...

...had I paid attention to the fact that your fix was offering 'dynamic batching' from the very beginning, this all would've been far less of a mystery to me...sigh.

Carry on great sir!


-Steve