Yet another major bug

[Holy_Diver]

I noticed today Som wasn't producing the object lighting to match up with the lamps (with my drivers/Windows 7)

I knew that before if you changed your display settings in the options mid game the object lighting had a tendency to disappear, but this is new.

An example of why this sucks is if you have say a lamp near a false wall (secret door) the door object will have no lighting but the walls around it will. Of course the object lighting and map piece lighting have never meshed correctly so your secret door would still be pretty obvious either way but it kind of cramps the atmosphere for it to not be lit to at least match.

The lamp lights are never even created. The directional map lights are however. The ambient map light isn't actually a light, its a global render state I learned about only the other day while researching the Direct3D lighting model.

Anyway I know for certain these were working before, though it may've been a year since I last payed attention to them. I'm assuming there is some device capability that Som expects to be reported just so which is not.

I'm pretty confident it can be fixed (with Ex...) in fact in theory it definitely can be. I'd forgotten about the lights being lost after leaving the options screen. Hopefully that can also be remedied in the process, though there is a possibility that bug might present more trouble... or at the least require a less than eloquent approach.

[Holy_Diver]

Ah I spoke too soon. Som does "set" the lights fortunately, it just never turns them on!!

I thought I was tracing the setting interface but was just monitoring the turn on interface. This is good news. So instead of trying to fix the bug. First I will just prepare an extension that ignores Som's light flipping and just turn on all the lights that are contributing to the scene / sort them so the more dominant ones are not left out. That in itself will fix everything (including the options bug) regardless -- and make it possible to up the effective light limit beyond whatever it is (3 or 4 + map lights I think)

Also Som does use diffuse lighting for lights. For a while I thought they might only be ambient. But ambient is not used, so those constant registers can be freed up in the shaders for other stuff.

I will try to setup a light calibration extension at the same time... assuming they can be better matched up with the baked in map lighting.

An extension that converts lamp lights to ambient might also be useful for speeding up games on slower machines.

[Holy_Diver]

Here is a screenshot with calibrated lighting. I will say something about it after it successfully uploads. I saved it lossless so the colour information would not be lost (~2MB)

Did not take. Here is a zipped version (.zip is lossless compression so at 10x smaller it makes me wonder if the .png file is compressed at all??)

Will upload a compressed thumbnail when I can...

UPDATE: Oh nevermind, looks like the compressed PNG is also lossless, but I swear GIMP have given me PNGs with artifacts when compression is high before (guess not)

[Holy_Diver]

I did not spend much time calibrating this lighting because basically I just hardcoded the calibration into the software and had to rebuild (compile/link) the library every time I made an adjustment (and of course close/run som_db.exe every time)

I only played with the attenuation basically. Som had it set for a constant attenuation factor of 1 and quadratic of 1. It may be all of the lights are setup with those settings. But anyway even the treasure chest in the picture right under the light was receiving virtually no light from the lamp. The ground around it was blue as it is, but the treasure chest was pitch red (the ambient light colour)

The attenuation in this screenshot is 0 constant, 0.25 linear, and 0.125 quadratic. I don't know if those settings would be good for all Som's lights or not. But it's clear this is a radical improvement / and superior approximation of the map piece lighting. The curve could be better maybe but as you can see the blue light peters out somewhere around the NPC. If you sample the colour of the NPC you'll see some blue contribution which must be coming from the lamp because the red ambient light is incapable of reproducing the blue hues in the NPCs texture. The suit of armor in the back is untouched as is the ground around him. And the treasure chest looks pretty appropriate... maybe the blue is a little less than should be or maybe the brown of the wooden chest just doesn't reflect blue as well as the white stones beneath it.

The skeleton is clearly half/half, blue on the side facing the light. Because the light is in the middle of the treasure chests right side, the front and back surfaces of the bottom part of the chest technically receive no light from the lamp. That presented an extremely sharp contrast which seemed unnatural. So I set the ambient contribution of the light to a fraction of the diffuse contribution to smooth things out. Light naturally bounces around the place even when shiny surfaces are not present. So Som's diffuse only lighting seems really inappropriate. The ambient light also helps smooth out the artifacts caused by per vertex (approximate) lighting. Unfortunately it may not be possible to add a little ambience to the map colours without processing the map files themselves... so you do get unnatural lights I think for instance bouncing off the grass pieces, though I have a feeling that could be fixed by smoothing out the surface normals in those files.

I don't myself have a natural feel for lighting / know if those numbers are natural, but they're clearly very different from Som's numbers and look a hell of a lot better in this case anyway. One thing is for sure, just being able to set numbers in an ini file won't cut it for authors or players. I gotta admit though the map editor is pretty shit for light setup. I don't even know if you can see the effects of your lamps at all in the editor.

[Holy_Diver]

It just occurred to me I recently learned that the map pieces do not in fact have lighting normals, therefore it must be the map lighting (read: non-lamp) is also baked into the map.

Which also brings up the point that the lighting seems to require calibration even when no lamps are involved (I believe) for instance we've had a lot of trouble I think creating map piece patches with objects because they did not receive the same lighting as the map pieces. Like a grass wall object to patch over the top of a cave mouth.

I'm assuming that Som's baked in lighting can even be replicated in terms of the Direct3D lighting model. I've always accepted that this is a challenge, which is why I'm interested in developing an alternative unified lighting model (see my other personal blog thread as of late)

[Holy_Diver]

It seems like maybe only som_db.exe (debugger) is effected by this bug, whatever is causing it

[Holy_Diver]

I kind of assumed that when you change the resolution in the options menu and that causes the direc3d device interface to be recreated Som was just forgetting that it had to setup all the lights again on the new interface.

But that doesn't seem to be the problem (though they may also be going on -- have not run any tests) .... it seems like after changing the options (either device or resolution) the same bug that afflicts the debugger kicks in. Basically Som just quits managing the object lights period. If something causes the map to be re-opened, the lights will come back.

I think I've seen other stuff make this bug kick in as well.



There's nothing I can think of to work around this behavior in terms of fixing the bug. I would not want anyone to have to release a game with this bug on the loose.

However what I have planned in order to fix the debugger (som_db.exe) should be applicable. The idea there is to just ignore Som's flip switching and keep all applicable lights burning up to max lights.

It seems like Som turns on up to 3 lights per object. I figure it chooses the three by whatever light radii overlap with the best fit radius of the object (forming 3d spheres) ... I was going to turn on all the lights that were visible to the player, but now I'm thinking in order to better simulate the 3 light behavior the extents of the vertex buffers should be calculated. That will also probably be a lot easier to implement. The only caveat is in theory anyway for soft animation objects the contents of the vertex buffers can change, and I'm not actually sure how Som manages the map pieces. But this approach in theory will also be more efficient because only as many lights as necessary would ever be factored in, and that would make it possible to really have a lot of lights in your game. Even crazy firefights which magic balls of light flying all over the place. So the pros out weigh the cons I think (if there even are any cons)

If any of the soft objects do break out of their initial radius they could be altered by placing a degenerate triangle or two into the file. And the radius could probably have a fudge factor added to it just to be conservative without too much harm done.

I think I can implement this in not too much time. And the [Bugfix] section option can be equivalent to "do_lights = yes" with a maximum light number 3 or 4 (whatever it is)

It may be too early to say, but after the lights are fixed. If you just erased the "Elapsed Time" from the menu in the translation file, and restrict the aspect ratio to 4:3 (adding this option) if needed, your game might appear to be bug free, editing aside. Only other thing I can think of at the moment is the sound dropping out and continuing to play after going into the menu. I definitely want to do some more work with DirectSound at some point.

EDITED: There are also a number of graphical "bugs" I can think of which could be fixed by making sure there are no black holes in the textures. The shadow texture should be re-leveled so it tops out at pure white. And almost all of the mdl files seem to have their uv components off by about a texel, and I can't find a way to automatically fix that, so probably those would need to be corrected by hand (or some clever algorithm) eventually.