[#VWR-12314] Avatar mesh doesn't cast shadows where darker than 50% Grey

1. Second Life Viewer - VWR

Avatar mesh doesn't cast shadows where darker than 50% Grey

Created: 07/Mar/09 02:13 PM Updated: 11/Nov/09 09:26 AM

Return to search

Component/s:

Graphics

Affects Version/s:

Snowglobe 1.0, 1.22, Snowglobe 1.1, 1.23

Fix Version/s:

None

File Attachments:

None

Image Attachments:

1. dark color doesn't cast shadow.jpg (40 kB)	2. i_aint_got_no_body.jpg (134 kB)	3. no prims no body.jpg (8 kB)
4. OnlyPrimsexample.jpg (87 kB)	5. shadow.jpg (30 kB)	6. Shadow_Bug_Is_Based_On_Darkness_Of_Mesh_Color.jpg (241 kB)
7. SnowglobeTestBuild+2009-10-10+17-41-52-66.jpg (137 kB)

Environment:

Win XP, SP3, GEForce 8800 GTX, driver 180.48

Issue Links:

Duplicate

This issue is original of duplicate:

~~VWR-13111~~ Dark areas of baked av mesh do not cast shadow

Parent/Child

This issue child of:

VWR-812 Ability to add alpha to base avatar skin

VWR-12719 Deferred Rendering Meta Issue

Relates

This issue Relates to:

VWR-13201 Meta-Issue: Shadow-Draft bugs & improvements

This issue is related to by:

~~VWR-12558~~ Full-Bright Alpha-Channeled prims do not render with RenderDeferred

VWR-812 Ability to add alpha to base avatar skin

VWR-15876 Meta-Issue: Machinima Improvement Issues

Last Triaged:	02/Apr/09 10:25 AM
Linden Lab Issue ID:	DEV-30042

Description

« Hide

Any part of the avatar mesh that is darker than 50% grey does not cast a shadow. This only applies whenever the mesh texture is fully loaded. Avatar leaves shadows correctly whenever the avatar mesh is only partially loaded.

Repro:

Create the test skins:
1.) Create full white skin
2.) Create a full black skin

Enable Shadows:
4.) Ensure debug setting "RenderDeferred" is set to FALSE, and that preferences Basic and Atmospheric Shaders are ON, and Hardware Skinning is turned ON.
5.) Set debug setting "RenderUseFBO" to TRUE
6.) Set debug setting "RenderDeferred" to TRUE

7.) Equip full-white skin, remove all clothing. Wait for the skin to fully load. Observe avatar leaves shadows correctly.
8.) Equip full black skin. Wait until the skin texture fully loads, observe shadow vanishes.
9.) Rebake clothing. Observe shadow reappears for 5~15 seconds, until the skin rebakes and the shadow again disappears.

See attached picture for reference:
http://jira.secondlife.com/secure/attachment/30672/Shadow_Bug_Is_Based_On_Darkness_Of_Mesh_Color.jpg

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Dessie Linden added a comment - 07/Mar/09 02:57 PM

Vector - Thank you for logging this bug and including the excellent snapshot. When you get the chance, please identify the SL Viewer version you're running and add that information to the Affects Version/s field. If you're running a recent RC viewer, please also let us know whether or not shadows appeared correctly in prior Release Candidates. Thanks!

[ Permlink | « Hide ]

Vector Hastings added a comment - 07/Mar/09 09:24 PM

Hey Dessie, thanks for looking at this. Sorry, I didn't see the "source code" option under Release version, I think that's as close as I can get, because this is the trunk, not even RC yet. My understanding is it's the basis of what's likely to be in 1.23.

To my knowledge, Shadows will be new in 1.23 and doesn't exist even in the RC 1.22 yet. Those who are working on the trunk might want to know about it.

Cheers.

[ Permlink | « Hide ]

Vector Hastings added a comment - 23/May/09 01:48 AM - edited

Just to add that this is indeed an issue with the Release Candidate 1.23.2.

Another possible contributing factor is that the combination of animations and height parameters for the avatar on the right (with only prim shadows) causes him tio hover a few centimeters above the ground, while the female avatar on the left always has her feet grounded. Note however, that this lack of body shadows continues when flying.

[ Permlink | « Hide ]

Opensource Obscure added a comment - 23/May/09 09:46 AM - edited

Partially (see attached shadow.jpg) confirmed on Linux too, 1.23.2 RC

By the way it happens even without playing animations.

Second Life 1.23.2 (120719) May 18 2009 12:02:26 (Developer)
Built with GCC version 40102
You are at 161407.9, 325345.7, 52.3 in White Taj located at sim5763.agni.lindenlab.com (216.82.51.65:13000)
Second Life Server 1.26.4.120562
CPU: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz
Memory: 4025 MB
OS Version: Linux 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9600 GT/PCI/SSE2
OpenGL Version: 3.0.0 NVIDIA 180.44
libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3.3 c-ares/1.4.0
J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0
Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24114 (Mozilla GRE version 1.8.1.18_0000000000)
Packets Lost: 0/24785 (0.0%)

[ Permlink | « Hide ]

Celierra Darling added a comment - 23/May/09 11:08 AM

I've seen this before, though I'm getting slightly different symptoms right now... For me right now, the shadows develop holes when I have on clothing that has alpha on it, and the transparent places end up not getting shadowed. Rebaking seems to work around it (at least until the next sun/moon update).

It's possible what I'm seeing isn't quite the same problem, though.

[ Permlink | « Hide ]

Adeon Writer added a comment - 08/Jun/09 02:11 PM

Second Life 1.23.3 (122255) May 30 2009 13:13:41 (Second Life Release Candidate)
Release Notes

Built with MSVC version 1400

You are at 237346.7, 253664.9, 26.1 in Dreams located at sim2573.agni.lindenlab.com (216.82.18.70:12035)
Second Life Server 1.26.4.120562
Release Notes

CPU: AMD (Unknown model) (2599 MHz)
Memory: 8190 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9800 GTX/9800 GTX+/PCI/SSE2
Windows Graphics Driver Version: 8.15.0011.8585
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24503 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 5/7949 (0.1%)

[ Permlink | « Hide ]

Soft Linden added a comment - 29/Jun/09 11:17 AM

Are you seeing the same issue with 1.23.4 ? I want to rule out any self-built viewer issues. That will help the graphics team handle this better.

[ Permlink | « Hide ]

Evo Szuyuan added a comment - 29/Jun/09 12:04 PM - edited

Yes it does (and also in snowglobe).
However, it doesn't only happen with lots of prims attached. See picture "no prims no body". My friend there is not wearing any attachments whatsoever, but an important body part is missing in the shadow.
When he takes off his shirt, his shadow is complete again. Texture rebake doesn't help in my case...
In case of missing body parts when wearing prims, taking off a shirt (or something) for a moment shadow is complete, before it gets back to the state where parts are missing.

[ Permlink | « Hide ]

Soft Linden added a comment - 29/Jun/09 02:19 PM

Thanks, I've moved it into the general post-1.23 pool

[ Permlink | « Hide ]

Adeon Writer added a comment - 11/Jul/09 01:50 PM - edited

~~Summary of messing with bug: Skin leaves shadows fine, but any part of your skin covered by clothing or tatoos will not leave a shadow.~~

~~Amount of attachments do not effect the result, they always leave their shadows. The biggest factor is if you are wearing fullbody tatoos (like most custom skins do) you will not have a mesh shadow.~~

~~Shadows appear to be confusing layers that obscure the base skin layer as positive alpha masking.~~

The above is wrong, see correction below.

[ Permlink | « Hide ]

Evo Szuyuan added a comment - 11/Jul/09 02:08 PM

To add to Adeon's comment.. Skin does not leave shadows fine.. A dark colored skin for example won't cast a shadow.

[ Permlink | « Hide ]

Adeon Writer added a comment - 20/Oct/09 08:38 AM - edited

@Evo: Thanks, hadn't tested a darker skin. So apparently the final mesh is looked at as monochrome, and 50% gray or darker gets counted as transparent.

Occurs on all ~~known~~ official viewers. After speaking with a quite the number of residents using shadows, I am fairly confident this is not a hardware issue - I haven't met someone yet who doesn't get this bug.

[ Permlink | « Hide ]

DarkShadow Beck added a comment - 20/Oct/09 12:10 PM

Just another one who complains about it.

Second Life 1.23.5 (136274) Oct 14 2009 13:31:00 (Second Life Release Candidate)
Versionshinweise

Built with GCC version 40102

Sie befinden sich in 267430.3, 271588.0, 25.1 in Berkman located at sim968.agni.lindenlab.com (216.82.13.118:13000)
Second Life Server 1.30.2.135876
Versionshinweise

CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
Memory: 3959 MB
OS Version: Linux 2.6.31-gentoo-r1 #1 SMP Tue Sep 29 15:29:59 CEST 2009 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 260/PCI/SSE2
OpenGL Version: 3.0.0 NVIDIA 185.18.31

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.750000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.27717 (Mozilla GRE version 1.8.1.18_0000000000)
Packets Lost: 0/12308 (0.0%)

[ Permlink | « Hide ]

JeffeJ5005 Lewis added a comment - 20/Oct/09 01:53 PM - edited

I recently upgraded my graphics card to an Nvidia 275 GTX from an 8800. I definitely don't think this is a hardware issue, and is definitely an issue with the alpha sorting. With it, I've also noticed that if you rebake textures, you will briefly be able to see your full mesh's shadow until something happens causing it to no longer make a shadow. Really hurts the immersion that shadows create when you turn into a shadow ghost...

I'm also consistently experiencing this on all versions of snowglobe, including the trunk 1.2 versions.

Stats:
Snowglobe 1.2.0 (2895) Oct 15 2009 15:51:33 (Snowglobe Test Build)
Release Notes

Built with MSVC version 1400

You are at 263841.9, 279219.6, 57.1 in Eder D Uru located at sim1063.agni.lindenlab.com (216.82.13.213:13002)
Second Life Server 1.30.2.135876
Release Notes

CPU: AMD (Unknown model) (2999 MHz)
Memory: 2783 MB
OS Version: Microsoft Windows Vista Service Pack 2 (Build 6002)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 275/PCI/SSE2/3DNOW!
Windows Graphics Driver Version: 8.16.0011.9062
OpenGL Version: 3.1.0

[ Permlink | « Hide ]

Vector Hastings added a comment - 21/Oct/09 02:12 AM

Just to the comment that this occurs on all known viewers, Kirsten's S18 has fixed it. There are other bugs, but the basic alpha sorting problems have been licked, so it's solvable.

http://sourceforge.net/projects/kirstensviewers/

[ Permlink | « Hide ]

Geneko Nemeth added a comment - 21/Oct/09 12:23 PM

From what I see, if there's any layer of the body texture that has been uploaded with transparency, the avatar body will not cast a shadow. This may include skin textures that are fully opaque but are saved with an alpha channel (that is fully opaque), or maybe just textures that use transparency.

[ Permlink | « Hide ]

Adeon Writer added a comment - 21/Oct/09 02:40 PM - edited

@Vector: I reproduced this in Kristen's S18205's. Can you confirm the bug's gone for you in S18205? Remember that it will always display correctly before the skin has 100% loaded in.

[ Permlink | « Hide ]

Adeon Writer added a comment - 28/Oct/09 05:00 PM - edited

Updated name of Jira title to accurately reflect the specific cause of the bug.

See attached screenshot:
http://jira.secondlife.com/secure/attachment/30672/Shadow_Bug_Is_Based_On_Darkness_Of_Mesh_Color.jpg

Reproduced bug by creating shades of greyscale skins and seeing which cast shadows and which do not.
Showed that anything darker than <128,128,128> grey doesn't cast a shadow, while everything lighter does.
Additionally, partially-loaded skins always cast a shadow regardless of brightness.

[ Permlink | « Hide ]

Charlette Proto added a comment - 30/Oct/09 08:09 PM

I'm curious if anyone has looked at the Hardware Options in Kristen's viewer, it includes the "RenderUseFBO and Render Deferred" UI options and produces a completely different result; very soft shadow outline (practically a blob like the feet make under the normal viewer), but it works as expected for all I can tell. The postprocessing in Kirstin's is rather more radical and everything looks very soft a toned in comparison to non Deferred rendering. I normally use Snowglobe and LL viewers including RC, which change the lighting slightly under deferred rendering and exhibit the same problems as describe by Adeon and others. BTW Kirsten's FPS drops to a 1/6 eg from 36 to 6 under the same conditions when deferred is switched on on my laptop and curious errors are listed too, see fragment from the log below.
_________________________________________________________
2009-10-31T02:39:04Z INFO: display_stats: FPS: 37.50
2009-10-31T02:39:07Z INFO: LLAppViewer::idle: Kills on unknown objects: 8
2009-10-31T02:39:12Z INFO: LLAppViewer::idle: Kills on unknown objects: 8
2009-10-31T02:39:14Z INFO: display_stats: FPS: 39.30
2009-10-31T02:39:15Z INFO: LLViewerShaderMgr::setShaders:
~~~~~~~~~~~~~~~~~~
Loading Shaders:
~~~~~~~~~~~~~~~~~~
2009-10-31T02:39:15Z DEBUG: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsVarsV.glsl class 2
2009-10-31T02:39:15Z DEBUG: LLShaderMgr::loadShaderFile: Looking in C:\Program Files (x86)\Kirstens S18-1 (211)\app_settings\shaders/class2/windlight/atmosphericsVarsV.glsl
2009-10-31T02:39:15Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class2/windlight/atmosphericsVarsV.glsl (Want class 2)
2009-10-31T02:39:15Z DEBUG: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsHelpersV.glsl class 2

.............. (edited out)....................

0(8) : warning C7532: global type sampler2DRect requires "#version 140" or later

2009-10-31T02:39:16Z DEBUG: LLGLSLShader::mapUniform: Uniform diffuseMap is at location 0
2009-10-31T02:39:16Z DEBUG: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0
2009-10-31T02:39:16Z DEBUG: LLGLSLShader::mapUniform: Uniform screen_res is at location 1
2009-10-31T02:39:16Z WARNING: LLRenderTarget::shareDepthBuffer: Cannot share depth buffer between non FBO render targets.
2009-10-31T02:39:16Z WARNING: LLAudioChannelFMOD::play: Playing without a channelID, aborting
2009-10-31T02:39:16Z INFO: LLVOWLSky::updateGeometry: WL Skydome strips in 2 batches.
2009-10-31T02:39:16Z WARNING: LLVolumeGeometryManager::registerFace: Non fullbright face has no normals!
2009-10-31T02:39:16Z WARNING: LLVolumeGeometryManager::registerFace: Non fullbright face has no normals!
2009-10-31T02:39:16Z WARNING: LLVolumeGeometryManager::registerFace: Non fullbright face has no normals!
2009-10-31T02:39:16Z WARNING: LLVolumeGeometryManager::registerFace: Non fullbright face has no normals!
2009-10-31T02:39:17Z WARNING: LLAudioChannelFMOD::play: Playing without a channelID, aborting
2009-10-31T02:39:17Z WARNING: LLImageGL::readBackRaw: GL Error happens before reading back texture. Error code: 1282
2009-10-31T02:39:17Z INFO: LLAppViewer::idle: Kills on unknown objects: 4
2009-10-31T02:39:21Z WARNING: LLView::createDummyWidget: Making dummy view named location_combobox in general_panel
2009-10-31T02:39:21Z WARNING: LLView::createDummyWidget: Making dummy view named camera_offset_scale in Input panel
2009-10-31T02:39:21Z INFO: LLControlGroup::saveToFile: Saved to C:\Users\Piotr\AppData\Roaming\Kirstens S18\user_settings\settings.xml
2009-10-31T02:39:21Z INFO: LLControlGroup::saveToFile: Saved to C:\Users\Piotr\AppData\Roaming\Kirstens S18\user_settings\settings_crash_behavior.xml
2009-10-31T02:39:21Z WARNING: LLRenderTarget::shareDepthBuffer: Cannot share depth buffer between non FBO render targets.
2009-10-31T02:39:21Z INFO: LLPipeline::resizeScreenTexture: RESIZED SCREEN TEXTURE: 1280x778
2009-10-31T02:39:22Z INFO: LLAppViewer::idle: Kills on unknown objects: 4
2009-10-31T02:39:24Z INFO: display_stats: FPS: 7.40

_________________________________________________________
Kirstens S18 1.18.1 (211) Oct 6 2009 10:46:33 (Kirstens S18)
.....

CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2527 MHz)
Memory: 4064 MB
OS Version: Professional (Build 7100)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9600M GT/PCI/SSE2
Windows Graphics Driver Version: 8.17.0011.9539
OpenGL Version: 3.2.0

[ Permlink | « Hide ]

Adeon Writer added a comment - 06/Nov/09 04:21 PM

Rewrote jira entry based on newest information and included repro.

[ Permlink | « Hide ]

Vector Hastings added a comment - 06/Nov/09 10:36 PM - edited

Thank you Adeon for paying such close attention to this!

Don't pictures 3 and 5 suggest coloration of a clothing layer is also at issue?

[ Permlink | « Hide ]

Adeon Writer added a comment - 09/Nov/09 09:52 AM - edited

Yes - most colors when viewed in black and white are dark grey, so they aren't past the 50% grey mark.

I don't know the exact reason for why, but from testing different things, for whatever reason the final baked mesh is converted to black and white, and then anything lighter than 50% grey leaves a shadow. So, for example, Obscure's dark green shirt turns into something like 25% grey (1/4 white 3/4 black) when viewed in black and white, which just is darker than middle grey, so that part of his mesh has no shadows.

Very odd that this happens, but that's what the patterns seem to show. Now if anyone can actually take a look at the code to see WHY that's happening, that would be wonderful.

PS: I compiled the render-pipeline branch, and this bug doesn't exist. But, that is 6 months old, so I can't tell wither this is "Already fixed" or that was just before the bug was introduced.