A first attempt at proper lighting

[assertivist]

I extended the fragment shader and AvaraGL to set up the four directional lights and ambient lighting. Everywhere Juri calls SetLightValues I call my thing too. Then I also modified CBSPPart to pay attention to have local ambient and respect the ignoreDirectionalLights flag. While I was there I changed extraAmbient from multiplying color values into actually adding ambient light instead.

The shader changes I think are relatively OK, the C++ stuff is what I don't know about, if something should go somewhere else let me know.

I'm not 100% sure the lighting is correct but it looks right when I load familiar maps.

Will close #7

[assertivist]

Oh yeah, I forgot to mention that I added a call to reset the defaults every time you load a level. I'm not sure that is the best place for the call (level parser) but it was an easy spot to put it.

[rherriman]

I haven't reviewed the actual source code (nor am I a particularly savvy person to ask for C++ advice), but attempting to run on a Mac is causing constant "Error 00000502 after convex fill" messages in Terminal, and failing to render properly.

It looks like it's trying to render the hull shapes but it's... bad. And level geometry doesn't seem to be rendering at all.

[rherriman]

By way of an update, I managed to create a fix for the issue in my fork of the project. Wound up being a simple syntax error that (evidently) only macOS cares about.

As we've discovered, though, the lighting does not seem 100% correct yet. https://imgur.com/a/9i6flXV

In general it seems darker, but the most notable difference is the shading on the light blue pillar near the center of each screenshot. The light/dark faces of the pillar are reversed, suggesting that the angles on the light sources are not translated correctly. Maybe the problem lies in to_cartesian? Could be a difference between what Avara considers x/y/z axes and what OpenGL considers the x/y/z axes? Just throwing out ideas.

[assertivist]

Here's where I am wrt all that:

I can verify that the shader and stuff produces the correct output for the input its given. So like here are some examples at 0 ambient and one full light from the north, east, south and west respectively, followed by one light at 90 elevation and 0 azimuth. So like this in order:

light[0].i = 1  light[0].a = 0  light[0].b = 0
light[0].i = 1  light[0].a = 0  light[0].b = 90
light[0].i = 1  light[0].a = 0  light[0].b = 180
light[0].i = 1  light[0].a = 0  light[0].b = 270
light[0].i = 1  light[0].a = 90  light[0].b = 0

And that seems correct. So I can only guess that my reading of the numbers from level files is wrong or out of order. I just need to add some debug statements and load some maps with known light levels (like grimoire) but it would be nice if I had a test level with more extreme lighting.

That way we can verify its working without having to worry about things like the colorspace being different (ours is definitely a higher bit depth) or factors like the emulator's consideration of coloring--though I totally agree it is clearly shown in the screenshots that the angle of the lights is different on those columns.

I'm also suspicious of some of the normals. For example the hector head looks like some of the normals are definitely flipped:

This shows the hector being lit only from above like in the last frame of the animation. Note that the right half from the viewing perspective should match the left half of the hull shape if the light is coming from above. Definitely going to try to not worry about that as part of this pull request--it can probably be a part of the existing shape conversion issue so I'll add a note there.

[assertivist]

I was able to verify that the angles are coming over correctly. From my svg copy of grimoire:

light[0].i = 0.6
light[0].a = 60
light[0].b = 30

from the debug output:

INFO: LOADING LEVEL 1198680429 FROM classic-mix-up
INFO: Light from light table - idx: 0 i: 0.599991 a: 60.000000 b: 30.000000
INFO: Light from light table - idx: 1 i: 0.299988 a: 20.000000 b: 200.000000
...

I double-checked the parameters so I am feeling like this is as "correct" as we're going to get:

i got really suspicious of normals but then i looked closer and uhh. isn't our shading more accurate in this case?

Consider below, if the light is coming in from the angle indicated by the arrow, those "left facing" faces SHOULD be lit more than the others:

Then observe in the Avara screenshot, that face is dark when it has no business being dark, even comparing it to nearby blocks!

???

[assertivist]

Just realized that the above screenshot had ambient turned off, and Grimoire definitely sets a custom one. so here's an updated screenshot:

[assertivist]

this is a screenshot taken with some rounding all around in the shader to approximate 16-bit color. i think its a little closer but still different...

[rherriman]

For the record I don’t think it has to be completely pixel perfect, people can set their display to 16-bit if they care about that. I just care that the faces light up accurately relative to one another.

…

On May 5, 2019, at 6:51 PM, andy ***@***.***> wrote: this is a screenshot taken with some rounding all around in the shader to approximate 16-bit color. i think its a little closer but still different... — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub, or mute the thread.

[assertivist]

i figured out why the ramp is shaded wrong. So this whole time, OGL has been rendering all the faces we throw at it as double sided. This means though, that when rendering that face, we get the same normal even if we're looking at the face from the bottom. So you're seeing what should be the top color of that ramp because ramps are built from a BSP which is a single polygon.

So I need to revisit the BSP exporter. And that stuff is only pulled in from the other repo on the svglevels branch. So to continue working on it i'm moving all this into that branch so I can test them together. That means unfortunately lighting will have to wait until svglevels/testing gets merged.