[Beta 5 Bug] Shadow Sticks in Basic Lighting
by Ryan Mounts · in Torque 3D Professional · 08/12/2009 (7:32 am) · 17 replies
In Basic Lighting mode, apparently the player casts no shadow while in 1st person view. Switch to 3rd person, and the shadow appears. Switch back to 1st person and the shadow decal is stuck to the ground in the place where you toggled views. So, the shadow decal needs to be hidden or deleted when toggling between 1st/3rd person.
#2
08/12/2009 (8:44 am)
Can you guys provide me with a little more information? I do not see this behavior when first starting up in BL (the shadow appears in first person without having to switch, and updates correctly, nor the other on player dead). 
#3
... and it moves around with me.
I believe there was already a "bug" attributed to the player shadow because of a material setting (castShadows) not being set. Have you checked this?
08/12/2009 (10:10 am)
Um, the shadow does indeed appear in 1st person in 'Basic Lighting'...... and it moves around with me.I believe there was already a "bug" attributed to the player shadow because of a material setting (castShadows) not being set. Have you checked this?
#4
I have ~30 AiPlayers running around, using an angled overhead camera that is pretty far away using a FOV of 30. Right away I got no shadows at all, and had to modify projectedShadowV.hlsl to change the hardcoded fade range from 5 to 500.
After making the shadows visible, I saw the same issues I had with the Beta4 blob shadows: many shadows just stop following their owners and just stay there, and often a shadowless player will "adopt" another player's orphaned shadow, which keeps showing the previous owner's projection! It seems the system is unable of removing the decals when they aren't needed anymore, and since the default shadowMaxVisibleDistance is only 80, I tried defining shadowMaxVisibleDistance to 500 on my players' datablocks. Now I get crashes after a few seconds of my game running, with RenderMeshMgr trying to set memory garbage vertex buffers.
Back to the old trusty blowShadow it seems...
08/12/2009 (11:18 am)
I just updated my project to B5 and I'm having tons of problems with the projected shadows. I can't post screens, unfortunately, but here's what I'm doing:I have ~30 AiPlayers running around, using an angled overhead camera that is pretty far away using a FOV of 30. Right away I got no shadows at all, and had to modify projectedShadowV.hlsl to change the hardcoded fade range from 5 to 500.
After making the shadows visible, I saw the same issues I had with the Beta4 blob shadows: many shadows just stop following their owners and just stay there, and often a shadowless player will "adopt" another player's orphaned shadow, which keeps showing the previous owner's projection! It seems the system is unable of removing the decals when they aren't needed anymore, and since the default shadowMaxVisibleDistance is only 80, I tried defining shadowMaxVisibleDistance to 500 on my players' datablocks. Now I get crashes after a few seconds of my game running, with RenderMeshMgr trying to set memory garbage vertex buffers.
Back to the old trusty blowShadow it seems...
#5
08/12/2009 (11:40 am)
You can't just specify the fade range to any old thing you like in the shader. There is a parameter on the datablock called shadowMaxVisibleDistance. It's set up to fade where it is for a reason (just plugging in 500 there is going to give you weird results, for one thing). The reason you're seeing them stop updating at some point is because they are set up (in ProjectedShadow::shouldRender) to stop updating under certain conditions, one of which is when they would be faded out anyway.
#6
08/12/2009 (11:48 am)
I figured out as much. However, increasing shadowMaxVisibleDistance crashes the game for some reason.
#7
Edit: Just tested it, it is using the shadowMaxVisibleDistance by default for the Gideon player, and manually inspecting his datablock and changing the value does not crash the engine for me.
Edit again: If you really need it to render shadows at 500 meters, you'll need to switch the method it uses to determine the decal's position to the alternate method in the ProjectedShadow class (but it will cause problems in some edge cases, where the player is in front of an object, but due to the projection method to figure out the decal position, the object does not receive a shadow, but the surface in front of the object will receive). Then you'll have to fix the shader as well (in which 5 is the half-distance, so you'd want 250, so change both values in the vertex shader that are "5" currently to 250). But again, that's not how it's designed for the stock behavior, so...
08/12/2009 (11:50 am)
I'll try to reproduce that.... Where is it crashing?Edit: Just tested it, it is using the shadowMaxVisibleDistance by default for the Gideon player, and manually inspecting his datablock and changing the value does not crash the engine for me.
Edit again: If you really need it to render shadows at 500 meters, you'll need to switch the method it uses to determine the decal's position to the alternate method in the ProjectedShadow class (but it will cause problems in some edge cases, where the player is in front of an object, but due to the projection method to figure out the decal position, the object does not receive a shadow, but the surface in front of the object will receive). Then you'll have to fix the shader as well (in which 5 is the half-distance, so you'd want 250, so change both values in the vertex shader that are "5" currently to 250). But again, that's not how it's designed for the stock behavior, so...
#8
...and the contents of "this":
08/12/2009 (11:58 am)
Call stack:> StrongRefBase::incRefCount() Line 174 + 0xc bytes C++ StrongObjectRef::incRef() Line 223 C++ StrongObjectRef::set(StrongRefBase * object=0x110bf0e0) Line 213 C++ StrongRefPtr<GFXPrimitiveBuffer>::operator=(GFXPrimitiveBuffer * ptr=0x110bf0e0) Line 254 C++ GFXDevice::setPrimitiveBuffer(GFXPrimitiveBuffer * buffer=0x110bf0e0) Line 573 C++ ProcessedMaterial::setBuffers(GFXVertexBufferHandleBase * vertBuffer=0x0b71b498, GFXPrimitiveBufferHandle * primBuffer=0x0b71b418) Line 108 C++ MatInstance::setBuffers(GFXVertexBufferHandleBase * vertBuffer=0x0b71b498, GFXPrimitiveBufferHandle * primBuffer=0x0b71b418) Line 409 C++ RenderMeshMgr::render(SceneState * state=0x0b7e9ce8) Line 192 C++ RenderPassManager::render(SceneState * state=0x0b7e9ce8) Line 293 C++ SceneState::renderCurrentImages() Line 160 C++ SceneGraph::_traverseSceneTree(SceneState * pState=0x0b7e9ce8) Line 234 C++ SceneGraph::renderScene(SceneState * sceneState=0x0b7e9ce8, unsigned int objectMask=4294967295) Line 196 C++ SceneGraph::renderScene(ScenePassType passType=SPT_Diffuse, unsigned int objectMask=4294967295) Line 165 C++ GameRenderWorld() Line 311 C++
...and the contents of "this":
- this 0x110bf0e0 const GFXD3D9VertexBuffer::`vftable'{for `StrongRefBase'} {mRefCount=??? } StrongRefBase * const
- WeakRefBase {mReference=0x10583354 } WeakRefBase
- __vfptr 0x10574b24 GFXD3D9VertexBuffer::`vector deleting destructor'(unsigned int) *
[0] 0x2aa417e9 *
- mReference 0x10583354 StrongRefBase::destroySelf(void) {mObject=0x1cb557e9 mRefCount=3584223488 } WeakRefBase::WeakReference *
+ mObject 0x1cb557e9 {mReference=??? } WeakRefBase *
mRefCount 3584223488 unsigned int
mRefCount 274074219 unsigned int
#9
Also, the game runs for a couple seconds before crashing. It takes quite a few frames for the decal shadows to start showing up, and the game crashes before all players have shadows.
08/12/2009 (12:01 pm)
Using only one player doesn't seem to cause problems. In my case I have a whole bunch of them, with a little lag caused by having way too much stuff to update each frame to boot.Also, the game runs for a couple seconds before crashing. It takes quite a few frames for the decal shadows to start showing up, and the game crashes before all players have shadows.
#10
And yeah, trying to constantly clip 30 decals every frame, and render 30 objects to 30 render targets every frame, even when they're at really far distance is not going to perform well. Thus the default behavior fading decals out quite a bit earlier than that. The system isn't designed for the use you're trying to put it to. It's not a replacement for advanced lighting shadows.
The render targets use pooled textures, so trying to force all the shadows to always clip and always render is going to shoot your texture mem usage up like crazy, because it will never be able to reuse any of the textures.
08/12/2009 (12:05 pm)
Yeah, that's not related (ProjectedShadow doesn't even use a regular material). And yeah, trying to constantly clip 30 decals every frame, and render 30 objects to 30 render targets every frame, even when they're at really far distance is not going to perform well. Thus the default behavior fading decals out quite a bit earlier than that. The system isn't designed for the use you're trying to put it to. It's not a replacement for advanced lighting shadows.
The render targets use pooled textures, so trying to force all the shadows to always clip and always render is going to shoot your texture mem usage up like crazy, because it will never be able to reuse any of the textures.
#11
The shadow does exist in 1st person view, but it only moves with the player when I am looking down the world's negative y-axis (with some slop of 5-10 degress on either side). Whenever I look away from this direction, the shadow stops animating and sticks to the ground (see image below). As long as I don't look back in the negative y-direction, I can move all over the level, and the shadow remains in place, unchanged. As soon as I look back toward the negative y-direction, the shadow jumps back to the correct place and begins animating with my movements again. I can repeat this ad infinitum, just by looking away from the negative y-direction. The shadow works correctly in 3rd person... I thought there was no shadow in 1st person because it was apparently stuck somewhere else in the level.
Windows XP Pro
Intel Core 2, 2.0 Ghz
1 GB RAM
NVIDIA Quadro NVS 135M
08/12/2009 (12:33 pm)
After a little more experimentation, I can say that the original post is somewhat misleading. Here's a more accurate description of the problem:The shadow does exist in 1st person view, but it only moves with the player when I am looking down the world's negative y-axis (with some slop of 5-10 degress on either side). Whenever I look away from this direction, the shadow stops animating and sticks to the ground (see image below). As long as I don't look back in the negative y-direction, I can move all over the level, and the shadow remains in place, unchanged. As soon as I look back toward the negative y-direction, the shadow jumps back to the correct place and begins animating with my movements again. I can repeat this ad infinitum, just by looking away from the negative y-direction. The shadow works correctly in 3rd person... I thought there was no shadow in 1st person because it was apparently stuck somewhere else in the level.
Windows XP Pro
Intel Core 2, 2.0 Ghz
1 GB RAM
NVIDIA Quadro NVS 135M
#12
08/12/2009 (3:28 pm)
@Ross: I was expecting it to behave like TGEA's projected shadows. Seems I'll have to roll a custom solution then. Having to enable deferred rendering merely for having individual player shadows doesn't fit the project I'm working on.
#13
08/12/2009 (3:51 pm)
@Manoel, maybe use just the depth pass and shadowmaps then.
#14
As a bonus I get bilinear filtered shadows, and since my game takes place over a simple plane I can use a much simpler shadow projection geometry generation.
However, I'll use PSSM with 1 or 2 splits for extreme zoomed views, so my players render with self-shadowing in those situations.
08/13/2009 (5:41 am)
@Ross: on the test hardware, doing TGEA-style shadows for each player (re-using the same shadow buffer, of course) is several times faster than using a PSSM. Something to do with rendering a large R32F texture all over the screen on systems with integrated or old videocards. Since I'm sure to have more CPU power than GPU on 90% my target userbase, I need to trade off fillrate usage for geometry processing wherever possible.As a bonus I get bilinear filtered shadows, and since my game takes place over a simple plane I can use a much simpler shadow projection geometry generation.
However, I'll use PSSM with 1 or 2 splits for extreme zoomed views, so my players render with self-shadowing in those situations.
#16
08/26/2009 (7:18 pm)
Logged as THREED-714 
#17
06/10/2010 (1:45 pm)
Confirmed as fixed for 1.1 Beta2. 
Associate Manoel Neto
Default Studio Name