Source Code Project Mantis - FSSCP
View Issue Details
0003129FSSCPgraphicspublic2014-11-14 22:512019-07-11 07:46
ReporterDarth Geek 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version3.7.2 RC4 
Target VersionFixed in Version 
Summary0003129: Lod 2+ rendered shiny even if shinemap is black
DescriptionWhen a model has more than 2 LODs and a completely black shinemap, LOD 2 and above are rendered with bright specular regardless of the black shinemap: see attached screenshot.

I also notice the normalmap is gone, which makes sense for rendering LOD 2+, but the addition of a bright shinemap renders the model incorrectly if it needs little to no specular, for instance if it is an asteroid.
Steps To ReproduceI suspect the effect isn't as visible using most ships since shininess doesn't look out of place on them. To see the effect more clearly, run the mission from test mod: https://app.box.com/s/yj1adjihffhbh5yx0pf6
TagsNo tags attached.
Attached Filespng screenshot.png (140,904) 2014-11-14 22:51
http://scp.indiegames.us/mantis/file_download.php?file_id=2611&type=bug
png

pdf 125.pdf (33,527) 2019-07-11 07:46
http://scp.indiegames.us/mantis/file_download.php?file_id=2726&type=bug

Notes
(0016461)
Cyborg17   
2015-01-25 13:33   
(Last edited: 2015-01-25 13:36)
So, I don't know if anyone has looked into this one yet, but I tried tracking down the revision that causes the bug.

What I found is that the revision which last changes the behavior, 9812, has little to do with shinemaps. (I could only test 9809 and 9814, but the rest seems unrelated) This bug simply became more pronounced in this revision since that's when turning normal maps off is sure to do something (the 9812 change), and it was probably trying to turn off normal mapping for LOD 2+ before that but couldn't.

So I loaded a really old revision, 7237, fixed the mission compatibility issues and then ran the mission. It had some really goofy behavior, including having this shinemap issue for all LOD's. I'm still looking for more clues, but I thought I'd report what I've found so far in case it would help.

(0016462)
Cyborg17   
2015-01-25 14:32   
(Last edited: 2015-01-25 14:33)
Testing by replacing the shine map with one that had a red tinge instead of black.

Red tinge did not appear at LOD+2, meaning that shine maps *are* turned off at LOD+2 and that a shader is being told to add shine data once above LOD+2.

After looking at revision 7189, adding shine data to models seems to have been the default behavior since shaders were introduced.

(0016463)
Cyborg17   
2015-01-25 15:03   
I tried changing the alpha channel of the shinemap to 0 to see if that would change the behavior, but it didn't.

I'm done looking for now, but the next think I was going to look at was to try to track the revision that the Lower LOD's stopped generating shine map data. (although that's probably when shinemaps were added)
(0016464)
FUBAR-BDHR   
2015-01-25 19:24   
Only LOD 0 and 1 render shine, glow and normal maps. Any LOD above 1 just renders the base map to keep the game from slowing down. The solution is to either make lod maps or increase the distance at which lod1 is used.

Issue History
2014-11-14 22:51Darth GeekNew Issue
2014-11-14 22:51Darth GeekFile Added: screenshot.png
2015-01-25 13:33Cyborg17Note Added: 0016461
2015-01-25 13:35Cyborg17Note Edited: 0016461bug_revision_view_page.php?bugnote_id=16461#r973
2015-01-25 13:36Cyborg17Note Edited: 0016461bug_revision_view_page.php?bugnote_id=16461#r974
2015-01-25 14:32Cyborg17Note Added: 0016462
2015-01-25 14:33Cyborg17Note Edited: 0016462bug_revision_view_page.php?bugnote_id=16462#r976
2015-01-25 15:03Cyborg17Note Added: 0016463
2015-01-25 19:24FUBAR-BDHRNote Added: 0016464
2019-07-11 07:46tomplatzFile Added: 125.pdf