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
First, 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!
About the author
Game developer.
Recent Threads
#2
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).
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
Thanks!
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!
#5
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.
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
Just tested - it's still there. Here is a video of another larger "area" (XviD). - Fresh install of TGE1.7 release.
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
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
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
To confirm - try setting ScreenError to 0 (in prefs.cs) and you'll see that it now looks good again.
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
Thanks for the pointer!
Rich
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
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.
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
I really need to start digging... lol.
03/02/2009 (4:23 pm)
Perhaps just defer shadow rendering to a final pass.I really need to start digging... lol.
Associate Matt Fairfax
PopCap
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.