Shadow Volumes Toolkit (now with stencil buffer support)

Actually I have one simple question...

...we know that the vert counts in 3D editors is going to differ from the count in Unity. One of my characters comes in at say 400 verts in 3DSMax, yet 735 in Unity...

...but why does the Shadow your tool creates add 1000 more vertices? Said characters shadow object is a whopping 1722 verts??

Also is it unreasonable to ask if an optimizer of sorts is possible for the Toolkit?

Thanks Gustav!


EDIT - Double checked my work on my tree object...I neglected to clear all my UV data and place all verts on Smoothing Group 1, so I was able to get matched counts between Max and Unity (176 verts for both), but the tree shadow object is still 738 verts...and yes I did delete the old one and generate a new one for the newly exported tree.

 

Alrighty, just so I can add value to my near ceaseless posting here today (poor Gustav, sorry!), I want to do a quick once-over of the best way to take advantage of dynamic batching with the Shadow Toolkit. As Gustav mentioned earlier, it might be that the DrawMesh() implementation is just as fast or faster than creating actual GO's to be batched, but just in case:

1. Create your object as you normally would in the 3D editor of your choice...
2. Import into your project...
3. Create (and rename) a duplicate of your original object and, unless the original already has a low vertex count, optimize it either by hand or a built-in decimator (e.g. ProOptimizer in 3DSMax)...
4. Import this new 'shadow object' into your project; you should now have your 'real' asset and the lower resolution 'shadow' counterpart in your Project Folder...
5. Instead of firing up Quick Shadow Setup, launch Shadow Mesh Creator(/Window/Shadow Volumes Toolkit), set your Bounds, and for the Reference Mesh choose the mesh you imported in Step 4, and click Create Shadow Mesh...
6. Double check the vertex count of this newly created shadow mesh. At or below 300 verts and you're golden...more than 300 verts and you need to go back to Step 3 and start over. Otherwise...
7. Select your primary object and add the Shadow Volume component, and for the Shadow Mesh choose the shadow mesh created in Step 5...
8. Finally add the Shadow Component To GO component, duplicate the object several times and fire it up! Note the batching in your stats window!

That said, it would be cool if there was some sort of automation in the Toolkit that offered a form of shadow mesh optimization, but perhaps that might be asking for a bit much.

I'm still curious why so many more vertices are created when generating the shadow mesh.

Cheers

-Steve

 

I'm considering using this for a 3d space game (in which it is impossible to prevent light from coming in at a near parallel angle to surfaces which makes light mapping unusable).

However I found a few issues in your web-demo. Can you comment on those?

Video:

 

Hello,

Yours is the first unity plugin I've bought and I can see it working for me, but I can't understand how to use the above feature.
I would, like previous posters have said before me, like to disable self shadowing.
I've tried many combinations, but can't seem to get it to work.

Can you elaborate on how to use this new feature?
Thanks.

 

Hello again,

Sorry to be the bearer or bad news, but me and a friend of mine have found an undesirable reproducible effect.
We are both seeing the projection lines of the shadow mesh in the game mode.
Here is my friends screenshot:


I've also attached part of his dxdiag:
View attachment $my friends dxdiag.txt

I can reproduce the effect by using any of the graphics quality settings that are above Good.


Here's is also my dxdiag if that helps:
View attachment $my dxdiag.txt

And here's the demo: https://drive.google.com/file/d/0B_Do8clBnuzwLXFRMGZQUWs5Unc/edit?usp=sharing

Also my friend with the older nvidia gpu has the error happen on our online demo as well. Here's a screenshot from him:

 

Sorry for the absence.

Hehe

The number of vertices/triangles in the shadow mesh depends on the number of triangles in the source mesh, here are the numbers. I think

For a two-manifold/closed source mesh:
vertexCount = sourceTriangleCount * 3
triangleCount = sourceTriangleCount * 4

For a non two-manifold/closed source mesh:
vertexCount = sourceTriangleCount * 6
triangleCount = sourceTriangleCount * 6

As you can see, two-manifold source meshes are to be preferred. Two-manifold source meshes result in fewer vertices/triangles and are less fillrate intensive.

The shadow mesh generation code will use the minimum amount of vertices and triangles, so it is not possible to optimize further.

 

Here is what I wrote a few pages back:

For the above use-case you don't need to use the new feature (to put the ShadowVolume and ShadowVolumeRenderer components on a specific layer), you just need to keep your dynamic game objects on the layer that the second camera renders. If you want to use a scheme where you need to put the shadows on another layer, just make sure that you choose the same layer for all the ShadowVolume components and the ShadowVolumeRenderer component.

Also, the Scene view will still show self-shadowing, since it only uses one camera to render the scene. Look in the Game view to verify the effect.

Thanks for buying the toolkit

 

Yes, this is a little embarrassing

For the webplayer demo I set the "Is Simple" property for all ShadowVolume components without giving it much thought. This improves performance but will cause artefacts if the camera is located inside a shadow volume, which is what is happening in the video. By disabling the "Is Simple" property this problem will go away, but I've just been to lazy to fix it and upload a new webplayer demo. The "Is Simple" property should only be used when it's impossible for the camera to be located inside a shadow volume, and this is obviously not the case for my test scene. Sorry for the confusion!

 

This artefact is caused by having antialiasing enabled when using the "Alpha Channel" backend. Quality settings above Good all have some form of antialiasing enabled, so this is why it's limited to those cases.

To fix the problem, either switch to the "Stencil Buffer" backend (on the ShadowVolumeRenderer component) or disable antialiasing.

My webplayer demo uses the "Alpha Channel" backend but should not have antialiasing enabled. Could you check if your friend has forced antialiasing in the nvidia graphics settings?

I will switch to the "Stencil Buffer" backend when I upload a new version of the webplayer to avoid this problem in the future. Thanks for letting me know

 

No big deal, I was already guessing that was the case. I figured either the shadows disappear because the cam is in shadow or because the light throwing the shadow is occluded (which is essentially exactly the same thing, just thought from a different angle ) So yeah no big deal, just wanted to make sure before I look into this.

Just one more question. Since you have put some work into this and know a bit about shadow technology first hand (I know the theory but haven't worked much with it): I am currently scouting shadow technologies for a 3d space game, meaning 6 degrees of freedom of motion, 3 degrees of rotation. From my current understanding there is no way shadow maps can be made to work reliably in a game that supports 3 degrees of rotation since you'll always hit an angle where shadows are projected at a surface that is paralell to the light direction, which causes artifacts since the projection function breaks down.

This is why I'm thinking that volumetric shadows are the only and better solution for such a game. Considering there is no real athmosphere in space and the local star basically throws mostly hard shadows because of its distance, in space shadow meshes throwing hard shadows seem to be ideal.

Do you agree?

Furthermore: Since we're talking about space, unless you're close to a larger ship there are nearly no surfaces on the screen that actually can receive shadows. Does your algorithm already profit from that or would there be an optimization to mark the screen where only the skybox is being rendered to prevent the shadow-pass for those pixels?

Finally, something that I cannot use for my game since it is shadow map based, but might be of interest to you as an implementation:
http://people.csail.mit.edu/ericchan/papers/smapSV/smapSV-electronic.pdf

I don't know if it would be possible for you to implement this since you need to hook yourself into the shadow map rendering for this, but maybe it gives you some ideas. Maybe your tech could be combined with shadow maps under certain circumstances. They do have some problems related to current hardware not fully supporting their idea, but I think they have a workaround for that. So I don't know whether that works yet for realtime stuff, I haven't researched that enough, but maybe you can figure something out to improve your project.

Thanks again for any input and thanks for your implementation, since shadow maps don't work for me I'm pretty sure this is the tech that I'm going to need this technology and it saves a lot of time not having to do this myself.

 

I'm referring to a 'decimator' of sorts, to generate lower vertex count shadow volume meshes that will then be able to be dynamically batched, essentially automating the process I outline above.

I was pretty happy finally being able to add as many shadow casting objects as I like and having the shadows batch. The 'trees' that I've been talking about now only take 3 drawcalls total...1 for the tree's themselves and 2 for their combined shadows(1 drawcall when they're in the distance (IsSimple)).

Mind you I was required to do my own decimation to get the shadow meshes under 300, but it works! Alternatively as you know without the batching, the trees would still be 1 drawcall, but each tree's shadow would be 2 drawcalls apiece. So that forest of 40 trees would be 81 drawcalls, not including anything else.

Not a biggie but if you think its feasible it could add some nice value to your asset.

Thanks Gustav!

-Steve

 

Hi,

You were right, it was because of antialiasing. My friend got the expected results now in the web player.
Sadly I can't switch to Stencil Shadows since that's a pro feature and I'm on Unity Free. So it's a tradeoff between shadows and overall crispness now.
So there's no way to maybe apply a different shader to those faces and not have them render at all?

Thanks for clarifying the self shadowing, I'll have to try it out.

 

Hi there, this toolkit looks really good and is very reasonably priced, so I am strongly considering buying it. however I have some questions before I do.

Is it possible to colour the shadows generated using this toolkit? Also, is it possible to have these shadows interact with a toon / ramp shader in some way? My current issue with shadow mapping toon shaders is that the shadow map is multiplied over the toon shader rather than being used to calculate the ramp value like I want. would any of this work or be feasible with your toolkit?

cheers!

 

Yes to 'Color' and, since the shadow is actual geometry, I can't see why it wouldn't work with any shader.

 

Hey if anyone can help: I've owned this for absolutely ages, even remember bitching at Unity for weeks about the 32bit buffer support in samsung phones. My question is - Is this asset still relevant for use, is it easier than it was to implement and where would I use it. And i'm assuming if on pro i use HDR the AA as postprocess, no weirdness.

Steve just made my day reminding me that i could use different shaders on the shadow volumes (Seriously for my next big thing that's just... perfect) but in more conventional terms, i'd like to use this for stuff and would like to know where! Also good possibilities for perverting its use somewhat for visual oddity

 

It's as relevant as a stencil shadow can be for you, hehe.

It's about as straightforward to work with as I imagine it could be, and I even outline some tips a few posts back on reducing shadow complexity if need be.

Otherwise being actual geometry in the world, again no reason I can see that would cause problems with any post-fx; no weirdness expected.

Sorry lazy I meant working with any given Shader of the 'object' casting the shadow, not the shadow shader itself. I haven't found any way (simply) to change how it renders, just its color. That would require Gustav to step in and answer this...now I feel bad having perhaps now made your day any less than it was.

Great tool all around honestly.

 

This is somewhat what I want to do. I'm using a ramp shader, and ideally I'd like any pixel inside a shadow volume to be assigned to the shadow colour and value defined by the far left pixel in the ramp texture. if possible I'd then also like to try and apply point lights to the objects after the calculation from the shadow volume caster has been performed (I guess additively?) and still using the ramp texture to drive the values.

Do you (or anyone else) have any idea if that's even possible, and how i might implement it? I'm guessing it would all be done within the shader... perhaps now that the stencil buffer in unity is accessible, that might be of use.

thanks!

 

youve ruined my day but maybe gustav can spare you from death

hah, no worries, i just thought 'what a neat idea' so maybe gustav can offer an answer

 

Haha, well see now that both of you are mentioning it and I'm thinking about it, it does sound like I could do some interesting stuff with that functionality hmmm...Gustav!?!?

(Looks like we might be on our own for now)

Cheers

 

Actually if you guys are adventurous, perhaps you could add another subshader pass, including whatever it is you're trying to do.

Look in the kit's /Shader folder and well...be my guest as shaders are not my area of expertise!

 

No you've got me thinking now, i want to add colliders to the shadows please, or youve double ruined my day

I dont even know if i'm being silly there

 

Colliders for a stealth game...hmmmm

Clearly not silly in the slightest!

 

You never know when weirdness is useful! Hah I feel like i'm hijacking the thread, but anyways, mobile projects are on the horizon, i'll be back

 

Hello Gustav,

First of all good job on creating this plugin.

Sadly we ran into an issue when using HDR cameras. The project we are currently developping is using deferred/linear lighting so we are using the AlphaChannel Backend. However activating or deactivating the HDR on the main camera causes that kind of undesired effect. For the purpose of the example we set the Shadow Color Strength to full red (alpha is set at 49)

Shadow Volume and HDR


No HDR


Does anyone have any idea on how we can fix this ?
Thanks in advance.

 

Hi all, sorry for the absence.

Thanks

This is a tricky issue. When using a HDR camera, the Alpha Channel backend will not work since it expects an 8 bit alpha channel and while I don't know exactly what backbuffer format the HDR camera uses, it does not seem to be compatible. The obvious solution to this problem would be to switch to the Stencil Buffer backend, but it does not work with the Deferred rendering path since I can't find a way to force the shadows to be rendered using the forward renderer after the deferred pass (like transparent objects are). This is needed because the Deferred path changes the contents of the stencil buffer while rendering the scene and thus messes up the shadow calculations.

So basically, HDR cameras in conjunction with Deferred rendering is not currently supported. You can have one but not both at the same time, unfortunately.

If anyone knows how to force a (non-surface) shader to be rendered in the forward rendering path, please let me know so I can fix this issue!

 

Actually, someone sent me an email asking for this a while ago so I wrote a first draft for a script to make it happen. Here is my reply to the email:

What you need is an extruded shadow mesh that can be supplied to a mesh collider component. It's not possible to get an extruded shadow mesh from the toolkit as-is, since the actual shadow extrusion happens in the vertex shader during rendering. However, it should theoretically be possible to extrude the shadow mesh in a script instead and use the extruded mesh as the source for a mesh collider. If the light or shadow casting objects move during runtime the performance will probably be pretty bad, but it might be worth giving a try!

I wrote a first draft of the script and attached it to this email. Attach the ShadowAsCollider component to a game object with a ShadowVolume component and make sure that you select the shadow casting light as the "Shadow Light" property. The "ExtrudeLength" property controls the length of the extruded collider. The "Update dynamically" property determines if the shadow collider should be updated each frame, enable this if your game objects or light move during runtime but be warned, it'll probably be slow.

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. [RequireComponent(typeof(ShadowVolume), typeof(MeshCollider))]
6. public class ShadowAsCollider : MonoBehaviour
7. {
8.     public Light shadowLight;
9.     public float extrudeLength = 10.0f;
10.     public bool updateDynamically = true;
11.  
12.     protected ShadowVolume shadowVolume;
13.     protected MeshCollider meshCollider;
14.  
15.     public void Start()
16.     {
17.         shadowVolume = GetComponent<ShadowVolume>();
18.         meshCollider = GetComponent<MeshCollider>();
19.  
20.         meshCollider.sharedMesh = new Mesh();
21.  
22.         UpdateShadowCollider();
23.     }
24.  
25.     protected void UpdateShadowCollider()
26.     {
27.         if (shadowLight != null)
28.         {
29.             Mesh m = shadowVolume.ShadowMesh;
30.  
31.             Vector3[] v = m.vertices;
32.             Vector3[] n = m.normals;
33.             int[] tris = m.triangles;
34.  
35.             LightType lt = shadowLight.type;
36.             Vector3 lpos = shadowLight.transform.position;
37.             Vector3 lbackwards = -shadowLight.transform.forward;
38.  
39.             for (int i = 0; i < v.Length; i++)
40.             {
41.                 Vector3 wv = transform.TransformPoint(v[i]);
42.                 Vector3 lightDir = lt == LightType.Directional ? lbackwards : Vector3.Normalize(lpos - wv);
43.                 Vector3 normal = transform.TransformDirection(n[i]);
44.  
45.                 if (Vector3.Dot(normal, lightDir) < 0.0f)
46.                 {
47.                     v[i] = transform.InverseTransformPoint(wv - lightDir * extrudeLength);
48.                 }
49.             }
50.  
51.             Mesh d = meshCollider.sharedMesh;
52.             meshCollider.sharedMesh = null;
53.  
54.             d.Clear();
55.             d.vertices = v;
56.             d.normals = n;
57.             d.triangles = tris;
58.  
59.             meshCollider.sharedMesh = d;
60.         }
61.     }
62.  
63.     public void Update()
64.     {
65.         if (updateDynamically)
66.         {
67.             UpdateShadowCollider();
68.         }
69.     }
70. }
71.  

 

Yeah, the toolkit will not take the vertex displacement of the shadow casting object's shader into account when extruding the shadow volume. The extrusion code is located in Core/Library/Includes/ShadowVolume.cginc at line 26:

Code (csharp):

1. float3 sourceDirection = normalize(localSource - input.vertex.xyz * _shadowVolumeSource.w);

You can change the local vertex position ("input.vertex.xyz") in the above expression to account for some displacement, but the problem is that it will be applied to all shadows, not those of a specific object.

This might be possible if you render the shadow term to a RenderTexture (Unity Pro only :/) before applying it to the scene. For performance reasons and since I'm targeting Unity Free as well, the scene color is linearly interpolated towards the shadow term using regular Alpha Blending. See the "SVT_StencilInterpolate.shader" file for how it's done.

Hope this helps

 

Hi everyone!

I just bought this asset today and have enjoyed playing around with it, thanks Gustav for making such a useful asset and has brought back memories of first playing Doom 3 a decade ago.

I've been in the process of making a game on the side for Ouya for far too long and the Shadow Toolkit seemed like a perfect addition to the game since light plays an important role in the gameplay, particularly the use of a point light, which other shadow solutions I've looked into don't seem to support. However I've had difficulty getting the shadows to display on device.

Before purchasing I did read that the original version of Amazing Frog used your toolkit (Now it appears they've switched to using PhobicGunners solution) as well as other users saying it works fine on other Tegra 3 devices, so it appears that I'm doing something wrong.

I'm getting a black screen, and have tried all the solutions I could find, which primarily appear to ensure I'm using a 32-bit color buffer and also set my backend to Alpha Channel No Blend Op as well as making sure the skinned shadow volume matched. I've also tried using the included older version of the toolkit with various setups. Nothing has worked so far. Is there something else I'm missing?

My game does generate it's level geometry at run time, but I'm only attempting to cast shadows from the main character currently. I've also tried pushing your example scenes to the Ouya without any success. I hope there's a solution I'm just missing because I'm tired...

Thanks for any help.

 

Hi and thanks for buying the toolkit!

I don't have an Ouya so I can't test the toolkit on the device myself. Since it's an OpenGL ES 2.0 device it should theoretically work fine. However, the quality of graphics drivers (or atleast unity compatibility) for android devices seem to be very bad and some features just doesn't seem to work unfortunately.

Are you following the points under #Important in the Readme?

Have you tried the Stencil Buffer backend on the Ouya yet? Basically, enable the 24bit depth buffer when trying the Stencil Buffer backend or enable the 32bit display buffer when using the Alpha Channel backend.

I've only gotten 2 emails regarding Ouya compatibility so I'm not sure how many of those that have bought the toolkit are targeting it. I've been away for a while so I don't know the current state of things, but my impression is that the Ouya is losing followers. However, if I get more requests I might buy an Ouya some time in the future

 

Thanks for the response!

Yeah, the Ouya may not be the most ideal platform anymore, but this is a side project and it should work well for what I'm attempting to do. I have followed everything as best I could in the readme, I only have unity free at home (have pro at work) so I haven't tried stencil back end. It wouldn't matter for the Ouya anyhow since the Tegra 3 only supports a 16-bit depth buffer. I've really been disappointed in nVidia's Tegra 3 feature set, but am really looking forward to the K1. I do have a low end Tab 3 I may test on as well, though it's a really slow device so I don't expect usable performance.

I know other posters in this thread mentioned getting it working on the Nexus 7 Tegra 3 tablet, which leads me to believe it's something I'm doing or something in my project is interfering, but I don't know what. I'll try a completely clean project next with only the shadow toolkit and see if I can't nail down the problem. It may be a while since we're working long hours to finish our game at work, but hopefully I may have a useful answer for anyone having the same problem I am.

 

Hi there
We've been having trouble getting the shadows to work on Tegra 3 devices (they work fine on desktop machines and iPads)
Namely, this is the setup we have:


And this is what it looks like when running on a Tegra 3 (in this case it was a Nexus 7 tablet) on the Stencil Buffer backend:


Curiously, while fiddling with it I got it to look like this (again, this bug only happens on the device) but I'm not sure what configuration I had then and haven't been able to reproduce it:


[Edit: It seems that the second screenshot is what it looks like when the shadow is NOT marked as simple and using Stencil Buffer backend; on any other configurations of those two parameters it looks like the first]

Any ideas what is going on?

 

My question, I'm wondering how do I specify something shouldn't have these shadows cast upon it?

Suppose I only want the shadows to appear on certain Game Objects, can I specify that?

I've tried playing with layer masking the light source, or matching the layer on the Shadow Volume Renderer to the layers of GameObjects, plus setting the things I don't want shadows on to not receive shadows, but I'm not clear is there a way to do this?

 

Android devices in general and Tegra 3 devices in particular seem to be super unreliable when it comes to feature support, unfortunately. For example, the toolkit seems to work fine on some devices running CyanogenMod but not when they're running the default firmware and so on. It seems to depend on the gpu/driver/os combination so it's difficult to say for sure if it should work or not. I don't have a Tegra 3 device so I can't help you debug the problem.

I found this: http://answers.unity3d.com/questions/503870/unity-42-stencil-buffer-dosent-work-on-tegra3.html. Have you tried the Alpha Buffer backend? (Make sure that you enable the 32bit display buffer if you do)

Yes, it is possible using the Layer properties, but it's a bit tricky. Here is what I wrote a couple of pages back:

Also, game objects that don't write to the depth buffer (transparent shaders among others) will not receive shadows.

Hope this helps!

 

If I remember correctly, the Nexus 7 couldn't do a 32 bit display buffer, so it would only show a black screen when we tried with Alpha Buffer backend. We've decided to just drop support for those specific tablets, so it should be good.

Thanks anyway!

 

Hello! Why are some shadows disappear when approaching camera?

 

Hi!

This is caused by the built-in view frustum culling in Unity. Since the shadow volumes are extruded on the GPU and the view frustum culling happens on the CPU, Unity might choose to not render a shadow volume even though it will actually end up covering the view. (Notice that the shadow will only disappear if the shadow caster is outside the view frustum of the camera?)

To fix the problem, set the Bounds Margin to a large value (~1000) before setting up shadows using the Quick Shadow Setup dialog. The shadow mesh bounds are extended by this value and since the bounds are what determines the size of the mesh during view frustum culling, the mesh will not be culled (as easily).

Ideally, the Bounds Margin value should be set to the maximum length the shadow can reach from the shadow caster. Since this is difficult to determine in practice it's sufficient to just set it to a large value.

Hope this helps!

 

Hi Gustav & other users!

I purchased the Toolkit last week and integrated this weekend for my iOS project. After realizing I needed a custom low-poly shadow mesh for my characters, everything came together nicely. My assets and scenes are pretty lightweight, so I didn't see any performance hit post-integration.

I have a few questions now:

1. Is there a way to exclude meshes/GOs from being affected by the volumes? (Even if that involves trickiness with layers or secondary/cloned cameras?)

2. I haven't had any luck yet using a skinned/animated mesh as a shadow caster; is that pipeline different than the pipeline for static meshes, or am I just doing something wrong?

3. Is there a guide for picking among the many shadow caster materials/shaders? Or is that all determined automatically by the Toolkit, and not something I need to worry about?

4. Are there any script-side, model-side, or shader-side optimizations I could make if I can guarantee I've only ever got a single directional light source casting shadows (i.e. the sun?)

Thanks!

 

Thank you. You are the best! Another question. What kind of mistake? This is when I create a shadow for object:

Could not create a shadow mesh for My_Object since the mesh is not properly closed (2-manifold)
UnityEngine.Debug:LogError(Object)

 

Hey ruslite - Gustav will surely provide a more comprehensive answer, but it's my understanding that shadow meshes need to be "watertight" - a clear exterior and interior, no holes, no exposed back-facing polys, all verts welded. (Kind of like Quake levels back in the old days - they weren't allowed to have any "leaks".) So your geometry might just need a clean-up pass.

 

Hi Gustav,

Im using your Shadow Volumes in PSVita, but i have problems with the stencil mode ( to save drawcalls as a mobile platform). Here is the screenshots:

Editor:


PSVita:


There is no problems with the other modes I have checked, and Vita is fully compatible with stencil buffers, what im doing worng?

 

Thanks!

 

Hello!

1.Why shadow on mobile not work? Display is black.

2. How to mitigate the shadows? Write shader?

 

Hi Gustav again,

Im here to report a bug (I will send private missage ). When the camera enter the shadow volume there is strange bug, here are the screenshots comparison (in game and editor):

Out of the shadow volume:


In the shadow volume (Alpha):


In the shadow Volume (Stencil):


I need a fix for this cause I use Shadow Volumes for large shadows and brings me weird shadows like this...

Using unity 4.3.4f1

 

Erik is right about the cause of the error and the explanation is correct. However, the latest version of the toolkit should be able to handle any mesh. (Watertight source meshes will result in better performance though!) Please update to the latest version and see if you can use the mesh that was giving you problems before. The new version might also solve the other problems you're having. Let me know how it works out

 

Hello! I'm happy that you're getting good performance out of the toolkit, even on iOS

Yes, here is an example on how it can be done:

That's strange. I just booted up a project with skinned meshes and checked, it works for me. Are you using the Quick Shadow Setup dialog? It can be a bit difficult to set it up manually.

It should all be handled by the toolkit. I recommend using the Quick Shadow Setup dialog in all situations. It handles the creation of shadow meshes and the attachment of ShadowVolume.cs components. With the newest version of the toolkit it's not possible to manually choose which shaders are being used by the (non-skinned) shadows, since it's handled by the ShadowVolume.cs script internally (Non-skinned shadows are not rendered using MeshRenderer components). Are you maybe using an old version of the toolkit?

Not that I can think of. It is possible to optimize the toolkit further for certain situations (scenes with static geometry and static lights) but it would require quite a bit of work on my end. In these situations, the shadow volumes can be pre-computed on the CPU saving GPU vertex shader cycles during runtime. It would result in more lightweight shadow meshes for these objects as well. I might add this in an update if there is demand and I have the time.

Thanks for using the toolkit, I hope these answers help

 

Hi!

I have not tried the toolkit on the PSVita so I don't know. Since it only happens with the "Stencil Buffer" backend it is probable that the Vita doesn't support all of Unity's stencil buffer operations. Does it work with the "Stencil Buffer No Two Sided" backend? If it does, use this instead. The normal Stencil Buffer backend takes advantage of a stencil operation (two sided rendering with different operations for each cull side) that I don't think is as widely supported. (At least I hadn't heard about it until Unity put it in the engine)

This is the expected behavior when the camera is inside a volume and the "Is Simple" property is checked for the ShadowVolume component in question.

If you're not using the "Is Simple" setting, then this is indeed a bug. Can you send me the model/scene in question so I can take a look at it? I'll answer your email so that you can attach the files to the reply. (Also I recommend using the latest version of Unity, but it shouldn't matter with this particular problem I believe.)

Hope this helps

 

Thank you very much for all your answers,

The "Its simple" checkbox has solved my problems with camera going trought shadow volumes, but there is something strange with PsVita now because stencil buffer its working different ( maybe now you can know what is causing this issue ).

PSVITA (there are correct shadows cause they are lightmapped, only cube and the character are using Shadow Volumes):


EDIT: Ok dont worry about it, i have managed to get in contact with Psvita deployment developers and they said that this is a bug on their side. They will fix it next build.

 

Great, thanks Gustav. I haven't used the quick shadow setup, I'll try that ASAP.

 

Hi, Gustav. I downloaded the latest version. I have two questions:

1. What is it?


2. In older versions of the shadow created by the new object. Not now. This is bad. Previously static shadows I could mark "Static". This reduced the draw calls. Take the opportunity to make the shadow object. Thanks.

 

Gustaaav!!