Some spacecraft with normal maps are appearing completely or partially dark
levinli303 opened this issue · comments
Describe the bug
Some spacecraft with normal maps are appearing completely or partially dark.
To Reproduce
Steps to reproduce the behavior:
- Download and install this add-on (on desktop you can click Download to download)
- Go to 'JUICE'
- See error
Screenshots
This is a screenshot of a different add-on that also has the problem
Desktop (please complete the following information):
- OS: macOS, iOS, Android (some?)
Additional context
based on the test build, the issue is introduced between
1b92417
and
7ad50c3
Hmm, generated shaders seem to be the same.
I compiled and did a complete installation of several git versions of Celestia.
System: openSUSE Leap 15.2 Linux
Celestia: Built for 64 bit CPU
Using GNU GCC 7.5.0
Built against Qt library: 5.12.7
Runtime Qt version: 5.12.7
QPA platform plugin: xcb
OpenGL: version: 4.5 (Compatibility Profile) Mesa 19.3.4
Vendor: X.Org
Renderer: AMD RAVEN (DRM 3.33.0, 5.3.18-lp152.19-default, LLVM 9.0.1)
GLSL Version: 4.50
Two models were selected. JUICE per levinli303 and a composite model of the ISS with parts from various models. JUICE was completely gray when affected. The textures and details (from the normal map? - normal map is present) were missing. ISS had some components dark gray and some that were not affected.
In order of oldest to most recent:
Version found on git July 11, 2023 08c7b4a - no affects seen on models.
Version found on git July 11, 2023 dc5592c (calculate planets shading in fragment shaders) - JUICE model colors OK. ISS model colors were OK but model had issues. When moving the model, some components were displayed randomly on the screen at 2x to 10x normal size and colors of gray, black, blue and purple. They flashed on and off and changed position as the model was moved. It appeared that the enlarged segments were also the ones that were dark gray in later versions, though not all of the dark gray components were flashing. It also appeared the flashing components had a specular map.
Version found on git July 11, 2023 9cd336b (always compute lights for night texture in fragment shader) - JUICE model was dark gray. ISS model had some components of dark gray. No random/flashing components overlaying model.
Version found on git July 11, 2023 3cfaeb3 (cleanup previous commits) - JUICE model dark gray. ISS model had some components of dark gray. No change from previous 9cd336b and matches results to present day.
The next experiment was to look at the models.
On the components of the ISS that were dark gray, CMODVIEW showed a normal map, which was not found on the other sections which did not turn gray. CMODVIEW was used to remove the normal map from these components. When displayed, the gray color had disappeared.
The JUICE model also has normal maps. When removed, the colors changed from gray to more usual shading, but the textures were missing with no normal map. Below are pictures of the JUICE model.
JUICE with normal maps
JUICE without normal maps
this model has normal map but no tangent, so
Celestia/src/celengine/shadermanager.cpp
Line 2307 in e475e2f
Thanks @levinli303 !
Indeed, the models don't have tangents, so we can either:
- Omit normalizing if tangents are missing. Just an additional field to
ShaderProperties. Not the best solution, it's more a hack. - Do nothing and request addon authors to rebuild them with tangents generated. Anyway it's their responsibility to provide proper models.
- Generate tangents when loading models. We already have such code in
tools/cmod/common/cmodops.cpp, so just need to adapt it for the main codebase. This will increase load time for such models but on the other hand if we can compute them why to waste storage and bandwidth?
My personal opinion is 3, 2, 1 (in order of descending priority).
@ajtribick , @levinli303 your ideas?
im in favor of 3. i think load time increase is acceptable given it is only a one time increase.
3 makes most sense to me also.