Tree shadows proposal
by Duncan Gray · in Torque Game Engine · 12/15/2005 (3:24 pm) · 14 replies
I have been looking through all forum posts and resources and reached the conclusion that no suitable solution currently exists for generating shadows from objects with transparent sections like trees.
Using Melve's fix only gets static shadows going but the whole transparent face of a leafy section is rendered as shadow, or not at all.
Bob the C-Builder did The Torque Lighting Kit which uses(I think) raycasts against the trees collision mesh which results in a shadow of the collision mesh, not the tree and its leaves.
Brett did a stencil shadows resource but the manner in which it works does not solve the transparency problem.
All credit to the above people because they at least achieved results. I'm hoping they get to read this and apply some of their expertise to this approach.
I'm proposing a render-to-bitmap approach which gets done just after scene-lighting. After looking in the code, it seems the current render to bitmap in TGE does not do a true render of the shape, i.e. It does not use textures and alpha values. If one simply renders a tree with alpha values you would get something like the below, left tree, as seen from the players point of view.
If you then did a render of the same tree, but using the sun's vector, it would look like the middle picture. Convert that to a stencil bitmap and you get the picture on the right.

Now use that stencil bitmap in the manner that TGE uses the bitmap from its own renderToBitMap() and you should get a result as below.
Obviously the alpha value of the shadow should change with the level of ambient lighting.
I don't know if this method is more cpu intensive than the current but seeing as all renders are done in realtime, I can't see an additional render for the shadow being too much of a problem. If it's done once at scene lighting time, even better, for static objects anyway.
Any comments from those in the know?
Using Melve's fix only gets static shadows going but the whole transparent face of a leafy section is rendered as shadow, or not at all.
Bob the C-Builder did The Torque Lighting Kit which uses(I think) raycasts against the trees collision mesh which results in a shadow of the collision mesh, not the tree and its leaves.
Brett did a stencil shadows resource but the manner in which it works does not solve the transparency problem.
All credit to the above people because they at least achieved results. I'm hoping they get to read this and apply some of their expertise to this approach.
I'm proposing a render-to-bitmap approach which gets done just after scene-lighting. After looking in the code, it seems the current render to bitmap in TGE does not do a true render of the shape, i.e. It does not use textures and alpha values. If one simply renders a tree with alpha values you would get something like the below, left tree, as seen from the players point of view.
If you then did a render of the same tree, but using the sun's vector, it would look like the middle picture. Convert that to a stencil bitmap and you get the picture on the right.

Now use that stencil bitmap in the manner that TGE uses the bitmap from its own renderToBitMap() and you should get a result as below.
Obviously the alpha value of the shadow should change with the level of ambient lighting.I don't know if this method is more cpu intensive than the current but seeing as all renders are done in realtime, I can't see an additional render for the shadow being too much of a problem. If it's done once at scene lighting time, even better, for static objects anyway.
Any comments from those in the know?
About the author
#2
I'd say you are going the right direction, unless someone has any better ideas.
12/15/2005 (5:18 pm)
That is the method Epic uses for use of shadows in Unreal engine 2. I don't believe that what you got would be more to the cpu but rather the gpu and video memory size issues. I'd say you are going the right direction, unless someone has any better ideas.
#3
You're way above my head in the renderToBitMap() area along with the stenciled shadows. Tried to even just implement it a while back and made a mess. Hopefully one of the smarter guys around here will pipe up. Until then I do know how to fake it but it's a whole lot of work. Looking at your proposal made me think of it. The results look like this:


It has some inherent limitations, but on relatively smooth terrain it works o.k.
- Alan
www.reallyreallygoodthings.com
12/15/2005 (5:45 pm)
@DucanYou're way above my head in the renderToBitMap() area along with the stenciled shadows. Tried to even just implement it a while back and made a mess. Hopefully one of the smarter guys around here will pipe up. Until then I do know how to fake it but it's a whole lot of work. Looking at your proposal made me think of it. The results look like this:


It has some inherent limitations, but on relatively smooth terrain it works o.k.
- Alan
www.reallyreallygoodthings.com
#4
12/15/2005 (5:58 pm)
I think with slight modifications to the existing player shadow code, you could get the result that you are looking for. But I think there are bigger problems with the shadows that would then look even more out of place. What I would like to do is to change the way the shadows are baked into the textures. right now, there is one big shadow map that projects across the entire terrain. What I would like is to create a set of shadow maps, one for each terrain chunk, and bake the shadow in at a 1-1 ratio. That would give a much finer shadow, and fix a lot of the problems where things were too small to generate shadows (etc).
#5
TGE's built in code somehow places the bitmap correctly against all terrain shapes but its beyond me to fathom out how that code works. If I could figure out the placement, then I have another idea about using a propertymap.cs file to point to a shadow bitmap for a static shape. At shadow render time you then tell the shadow code to use that bitmap instead and it will be placed correctly against the terrain.
12/15/2005 (8:33 pm)
@Alan, yeah you could fake it by manually creating a shadow from a tree then placing the bitmap in the game. How did you place yours there, just out of interest?TGE's built in code somehow places the bitmap correctly against all terrain shapes but its beyond me to fathom out how that code works. If I could figure out the placement, then I have another idea about using a propertymap.cs file to point to a shadow bitmap for a static shape. At shadow render time you then tell the shadow code to use that bitmap instead and it will be placed correctly against the terrain.
#6
12/15/2005 (8:40 pm)
@Jaimi, yes I have a long wishlist about the baked in shadows. The fact that they repeat from one terrain tile to the next is also a major anoyance when you build a race track accross multiple terrain tiles.
#7
I used TLK's decal projector, I discovered by accident that it projects onto terrains as well as dif objects. Now as to the question of if projector decals are in 1.3.5, I'm not sure. I've been using (as far as I know) an unreleased version 1.3.6 for a collaboration for IGC with John Kabus. Decal projectors are a part of that, but I defer to John on that. ( But I don't remember them in 1.3.5).
And boy, I hope they weren't a secret.
So then it's just a semi transparent, alpha channeled .png projected onto the terrain surface. I made the shadow from a screen of Treemagik G3 in Billboard mode (didn't bother to export it because it would have ended up trying to separate the textures for the BB dts model anyway).
- Alan
www.reallyreallygoodthings.com
12/15/2005 (9:06 pm)
@DucanI used TLK's decal projector, I discovered by accident that it projects onto terrains as well as dif objects. Now as to the question of if projector decals are in 1.3.5, I'm not sure. I've been using (as far as I know) an unreleased version 1.3.6 for a collaboration for IGC with John Kabus. Decal projectors are a part of that, but I defer to John on that. ( But I don't remember them in 1.3.5).
And boy, I hope they weren't a secret.
So then it's just a semi transparent, alpha channeled .png projected onto the terrain surface. I made the shadow from a screen of Treemagik G3 in Billboard mode (didn't bother to export it because it would have ended up trying to separate the textures for the BB dts model anyway).
- Alan
www.reallyreallygoodthings.com
#8
But it would only be usefull on flatish terrain.
12/15/2005 (9:34 pm)
@Alan. Don't worry, you can also use a billboard shadow as a TSStatic and place it next to the tree, horizontal with the ground. You don't need the decal projector. It can can also be automated in script at missionload time, cutting down on manual placements.But it would only be usefull on flatish terrain.
#9
I was also thinking that you might want to take a look at how the vehicle shadow code works. I created a physics object by hacking up the rigid body physics coding from vehicle.cc/vehicle.h.
( Before I discovered someone else had did the same thing!). The shadows work great on the physics dts objects that use this code, they are dynamic and sharp, even on small objects.
Here's the difference:

I don't know if this is any help, but the shadows seem very accurate to the mesh in that coding.
- Alan
www.reallyreallygoodthings.com
12/15/2005 (9:38 pm)
@DuncanI was also thinking that you might want to take a look at how the vehicle shadow code works. I created a physics object by hacking up the rigid body physics coding from vehicle.cc/vehicle.h.
( Before I discovered someone else had did the same thing!). The shadows work great on the physics dts objects that use this code, they are dynamic and sharp, even on small objects.
Here's the difference:

I don't know if this is any help, but the shadows seem very accurate to the mesh in that coding.
- Alan
www.reallyreallygoodthings.com
#10
I think its a speed compromise done for moving objects. Changing it to load the objects textures etc before creating a shadow bitmap might be too 'expensive', time-wise for real time render of moving objects but for statics like trees it would work.
12/15/2005 (9:47 pm)
@Alan, yes thats the standard shapebase shadow code used by all shapebase derived objects likes players, vehicles etc. They all use the same code... The problem is with transparency. Make a barrel with a transparent skin pattern and it will still generate a solid shadow. :(I think its a speed compromise done for moving objects. Changing it to load the objects textures etc before creating a shadow bitmap might be too 'expensive', time-wise for real time render of moving objects but for statics like trees it would work.
#11
12/15/2005 (10:21 pm)
What if the tree's DTS was animated?
#12
12/15/2005 (10:37 pm)
Hey, nice stuff in'ere
#13
Wouldn't make any difference as far as I know. Even if I say converted the static tree to a physics object class and gave it so massive a mass it couldn't be budged, yes, the shadow would be very accurate to the mesh, but that would include a twenty or thirty thin squares in the branches that the leaf textures are on, because like Duncan mentioned it wouldn't let the light pass through the transparency of the textures.
I think as far as I understand the problem is that we need Statics that could display transparent portions of their textures, but it's non transparent parts would block light at the time of
lighting the level and bake the shadows in to the terrain.
Or I could be totally wrong. =)
- Alan
Edited for Grammar...=)
12/15/2005 (10:49 pm)
@MidhirWouldn't make any difference as far as I know. Even if I say converted the static tree to a physics object class and gave it so massive a mass it couldn't be budged, yes, the shadow would be very accurate to the mesh, but that would include a twenty or thirty thin squares in the branches that the leaf textures are on, because like Duncan mentioned it wouldn't let the light pass through the transparency of the textures.
I think as far as I understand the problem is that we need Statics that could display transparent portions of their textures, but it's non transparent parts would block light at the time of
lighting the level and bake the shadows in to the terrain.
Or I could be totally wrong. =)
- Alan
Edited for Grammar...=)
Torque Owner Duncan Gray