mm2hook
mm2hook copied to clipboard
Fireboyd78
Fix PSDL Ground Shading
The ground shading we implemented awhile back has a bit of an oversight.
As we know, pitch/heading have a minimum/maximum value of -3.14, and 3.14, with the center being at 0. For pitch, 0 is from directly west, -1.57 is from directly up, and -3.14 is directly from east. Likewise, 1.57 is from directly down, and 3.14 is once again from directly east. This image should help explain how it works.
If light sources have pitch/heading values that stay within the bounds of -3.14 and 3.14, everything works fine. However, if a light source has a pitch/heading value that goes below -3.14 or above 3.14, that light source will glitch out with our system.
MM2's own lighting system works fine with this though. Values that go beyond pi simply loop around. So for example, a value of -6.28 (pi 2x) will loop back around and act the same as a value of 0 (light from the west). A value of 4.17 (pi x1.5) will loop halfway back around, and will act like a value of -1.57 (light from directly above).
I don't remember the exact equation I came up with back when this patch was first made, but I do remember that it wouldn't work with out-of-bounds values. So in order to properly fix this, we'd probably need an entirely new way of calculating light color for the ground.
I suck at math; it's something of a minor miracle that I managed to come up with the original equation. I don't know of a way to do this properly, and I'm assuming you guys are in the same boat. So here are two alternative solutions:
-
Detect if a lighting file has any pitch and/or heading values that are less than -3.14, or greater than 3.14. If they do, disable our ground shading enhancement and fall back on default behavior. This will allow the ground to be fullbright, rather than glitched. I feel like this should be possible, since Mark just did a similar thing for the digital speedo last night.
-
Make this lighting enhancement an INI toggle, with a comment of something like "Set this to 0 if you are using any mods that cause issues with this feature". Not exactly ideal, but it beats being forced to either remove MM2Hook or fix the lighting file if you can't live with the glitched shading.
Issues in NYC’s Evening Cloudy seem to actually be related to negative floats for color values.
I haven't done any testing yet, but I'm thinking a color value of -0.25 is the same as 0.75, and I see in the code where it does this. Not difficult to add a check for a negative number. But I wanna make sure this is done right, cause if there's an equation we can use to simplify a lot of this math, that'd be perfect. Honestly it feels really hacked together, which may explain why negative values cause everything to go haywire.
@Fireboyd78 Turns out, PSDL really freaks out with negative color values. It even affects buildings, without mm2hook installed. All MM2Hook does is amplify this issue by causing ground to also be affected. For some reason though, PKG models are not affected in the same way.
As a result, I am demoting this issue to low priority. The bug I reported is still present (as you can see here), but there are no mods or cities I am aware of that use them.
I suggest implementing a fix that converts negative color values into positive ones when the data is first loaded. Maybe a FileIO hook, check for negative values after? Would fix lighting bugs!
TODO: Also disable based on lighting quality slider. Anything < 3 = just disable it
