Game Development Community

TGEA 1.7.0 Beta 2 Bug - Shadow rendering bug

by Fyodor -bank- Osokin · in Torque Game Engine Advanced · 03/31/2008 (5:48 pm) · 12 replies

my.afterworld.ru/~bank/gg/tgea170b2_t3d_shadow.jpgFirst, I thought about sharing an idea to "decrease" a shadow while the player is already in shadow - like on screen I'm covered by mountain from Sun - so it would be nice if shadow will almost disappear while in this condition... but while running around I found that there are rendering bug with it.
See the screenshot.
This does appear on my side with other player models too and it's all default settings, only resolution changes.

WinXP SP2 English, GF8600 512VRAM, DX: Nov2007, Drivers: 169.21. Stock shipped EXE.

edit: corrected image link, huh!

#1
03/31/2008 (6:08 pm)
That could be one of two things...

With some of the models the bounding box is too small (I'll admit I haven't gone in an tweaked each of them) and the shadows can get "chopped off" by the bounding box.

The other thing that I have seen is that on the Terrain it is fairly common to get into places where the polys near you are "backfacing" (their normal faces away from you) and the shadow won't render on back facing polys (a long standing "bug"). This is useful when casting onto meshes since you don't get the shadows bleeding through to the other "side" of the polys but it can look a little odd on th Terrain. We *may* be able to make an exception to the Terrain and see if that looks better.
#2
04/01/2008 (4:33 am)
First: this bug appears only at some places, so it's not bounding box.

second: This does not seems to be backfacing issue, as if I fly around the model with camera - at different angles the shadow starts flickering and being "cut" in different ways (the "empty" square have different size). The further away I fly - the more shadow visible, if I rotate around model if at some angles it's "ok", at others - "bad".
Better to see by yourself:
Here is video I've made - link (XviD MPREG-4 Codec).
The position of bot is: 552.202 770.08 161.537 (I'm seeing it all the time).
#3
04/01/2008 (11:05 am)
Can you record a journal of this hapening at 800x600 windowed resolution (journals are resolution dependent) and send it to me so that we can reliably recreate the bug on our end?

Thanks!
#4
04/01/2008 (11:15 am)
Sure: zipped.
Edit: I've spotted two places - bot is "jumped" there. While running there were seen another two places where the shadow flickered.
#5
04/05/2008 (2:55 am)
Hey bank,
Please test out the TGEA 1.7.0 Release and see if you can still reproduce this bug. John added what he thought would fix it but we haven't had a chance to properly test it.
#6
04/05/2008 (11:45 am)
Hi Matt.
Just tested - it's still there. Here is a video of another larger "area" (XviD). - Fresh install of TGE1.7 release.
#7
04/08/2008 (1:49 pm)
This should be the same bug:

XVid ~1 MB

I only (but always) get it in that small spot and didn't find any other places around in a wider range where it happens.

1.7.0 final
Windows XP SP2 German
GF 6600 GT with driver 169.21 (same as bank, no idea if it matters)
AA off
beer cold
#8
03/01/2009 (10:00 pm)
Sorry to ressurect this, but it's still there in 1.8.1. It occurs at certain locations on the terrain and it appears that it's literally a matter of the shadow not being rendered to certain terrain polygons.
#9
03/02/2009 (1:42 am)
This error is related to Terrain LOD. Long story short, shadows gather a polylist which they render their texture to, and in this case the polylist isn't accuratly representing the terrain that is being rendered, when LOD kicks in.

To confirm - try setting ScreenError to 0 (in prefs.cs) and you'll see that it now looks good again.
#10
03/02/2009 (4:32 am)
Hmm, guess we'll have to look into this - maybe have shadows ignore the highest detail level and render to everything. Somehow the shadow polylist is not being updated correctly as the player approaches new areas of the terrain and apparently this is at least partially controlled through the ScreenError setting. I suppose a little digging is in order.

Thanks for the pointer!

Rich
#11
03/02/2009 (4:54 am)
Well, the reason this is a problem is because you just can't update the collision mesh every frame. You'd also have to keep two sets, one for "real" collisions, so you're in sync with the server (which doesn't do LOD!) and then one for the rendering part. Not feasible.

I would go for a deferred 2D approach, if it's possible.

Edit: Or hey, check out how dynamic lighting is done. It doesn't do any collision but redraws affected terrain tiles with the new texture on them. That shouldn't be too difficult to get working for shadows.
#12
03/02/2009 (4:23 pm)
Perhaps just defer shadow rendering to a final pass.

I really need to start digging... lol.