Regression/Issue with spheremap textures/lighting

[legoj15]

(I actually don't know if 'projected textures' is the right term, but they're specular environment maps applied over a texture, occasional with a color map texture applied)

I noticed this a while back, and thought it'd be a temporary bug, but it only got worse. So I did some bisecting (IDK if that's the right term), and found the start of the issue. Here is a viewport capture of of the latest commit (0513e31) as of writing, as you can see, it's very static, the projected envmaps don't move the and light is very bright and facing the front only:

Here's 8af7c711, the last build where the light is still very bright, but it's following the camera (I think, either that or the texture is fullbright) and so do the projected envmaps: (Some builds in between 8af7c711 & ce7fbe5e suffered from overexposed textures, such as 15247927)

And here's ce7fbe5e, the last build in which captured the closest lighting simulation (IMO) and the envmaps properly:

This is a capture from the 3DS, using the background in the trophy viewer that has the least lights Obviously, SPICA can't make it look like how it does in the 3DS screenshot, since the lighting is controlled outside of the model scene so it affects all trophies, but I still belive that ce7fbe5e is the best looking in the sense of lighting.

And lastly, here's the sample used in the examples above: Amy.zip

[legoj15]

Forgot to mention that this is from Super Smash Bros. for 3DS in BCH format

[gdkchan]

Those models uses hemisphere lighting and the light color is calculated on the vertex shader, and passed to the fragment shader on the vertex color (primary color) attribute. The version on your "closest lighting simulation" is the result of a vertex shader made by me, that tried to mimic the result you see on the game with some hardcoded values.

After that I wrote an automatic translator that translates the binary 3DS vertex shader in shbin format to GLSL, this should (in theory) be more accurate. I then removed my shader and added the default bch shader used on (most) games, translated to GLSL by default, this introduced the two "issues" you noticed -- The light no longer changing with the camera and too bright lighting.

FWIW the uniforms that controls hemisphere lighting on the translated 3ds shaders are HslSDir for the light direction (where W = LerpFactor iirc), HslGCol for the ground color, and HslSCol for the sky color. For some reason those uniforms aren't set anywhere on the code, iirc I was trying to avoid hardcoding values and planning to write proper light support (something that I started on 6ffdfdc1ddf3b3614b9fda457ef9717194d6cf34, but it's still incomplete).

The camera issue is maybe due to a wrong normal matrix, I need to take a look.

[legoj15]

Thanks for the explanation, it was actually very helpful. I'm glad that proper lighting support is being implemented, that's a pretty big deal for what I do and would happily wait patiently now knowing that that's planned. The camera issue (static envmaps/forward lighting) affects more than just these Smash Bros. models, I've noticed this from SuMo models to Puzzle Swap scenes after taking a deeper look. Speaking of which, in the Samus puzzle swap scene, there's an animated camera baked into the scene. If I look through that one and play it's animation, the lighting/envmaps do follow the camera, as expected. Just thought I should mention that, since it intrigued me that the envmaps do still work, just only when it's using the animated scene camera. Here's a video I recorded a while back, demonstrating the animated camera working with envmaps (but not the viewport camera): https://youtu.be/YNRo0dRcdOw