General FreeSpace > FreeSpace Discussion

The future of lighting flags in FSO

(1/7) > >>

EatThePath:
Since becoming more involved in the graphics side of FSO I have been increasingly dissatisfied with -spec_point, -spec_tube, -spec_static and -ambient_factor, for a number of reasons. I want to remove them from the engine, but I also know that they serve an important role since the engine does not provide brightness options. I've discussed my plan of action on discord with a number of people over the past year or two, but I didn't want to change such a deeply ingrained part of FSO without bringing it here too.  I'll go over my reasons first, then my plan of action.

The -spec lighting flags were added almost 20 years ago, along with shine maps. In my experience they are used almost entirely as brightness controls by the community, either by user options or for mod visual design. The thing is, they're really bad at that. They don't control brightness overall but rather the brightness of specular reflections, the sharp highlights on shiny parts of a ship. This has a number of negative consequences.



Here's a comparison of -spec_static 2.0, 1.0, and 0.0 on two ships from the same angle under the same lighting conditions. It shows a number of the issues.


* By comparing the non-shiny areas of the Hecate you can see that this tool is not very effective at changing the overall brightness of a ship very much. If you're trying to make the game much brighter or much darker this way, it's not very effective.
* No, I didn't screw up and put three copies of the same Erebus screenshot in, though I can't promise they're in the right order ;). How much a ship is affected by the -spec flags depends heavily on the ship's texturing, so using the flags as a brightness control leads to an incoherent and unpredictable results between assets.
* The shinier areas of the Hecate start to look very strange at extremes, because PBR assets intrinsically depend on properties of light that these flags break. Even worse, if you have noticeably different values for the different spec flags you get a ship that looks like it's made of different materials depending on where the light is coming from.
I'm sure when these flags were added and specular was a relatively new feature people were tuning, this made sense. Now though, PBR textures have specularity as an integral part of the artistic intent for a ship from the very start and the flags unpredictably mangle that intent more than anything else.

Ambient_factor I hopefully don't have to explain, the math behind it is confusing, for little benefit. Simple scaling is what people expect and likely what they should get.

So what am I going to do about it?

Of course none of this is set in stone, I'm confident in it but there's always the possibility that discussion or development will prompt a change of plans.

Firstly, I will disable the current set of flags, and replace them with two new ones. -lights and -ambient, both simple multipliers on the lighting. I want to do this rather than simply update the old ones so that people are aware of the changes and have the chance to adjust for them, rather than having their lighting change in potentially subtle ways and only discovering why down the line.

Second, I will add a swath of brightness controls to the lighting profiles table, again controlling the whole light rather than only the specular. This will allow much more detailed changes to lighting than would ever be practical as command line flags, and allow mods to incorporate these changes directly into their files rather than relying on launcher flags to implement their visual design. When profile switching is fully implemented this will even let mods tweak their global lighting properties from mission to mission, such as making weapon lights dimmer and smaller in nebula missions or the like.

In my mind if you want to adjust a game's lighting at that level of granularity you are dipping into what is essentially modding, just as much as editing the HUD or fonts is, and it makes the most sense to support that via tables. Still, while it is my hope that mods will take more ownership of lighting design over time and players will feel less need to adjust it I have no expectation that this will happen immediately or completely. So as lighting profiles matures as a feature I will be mindful of ensuring there is always a viable way for an end user to over-ride a mod's settings if they feel the need.

In doing all this I also intend to disable the SunSpecularRGB config option in stars.tbl. I have yet to find a mod that uses this option and it has all the same problems as the specular flags do. With it gone the FSO's shaders can be somewhat simplified under the hood, and quite possibly improved further too.

Please, let me know if you have any concerns or question. I understand that I am messing with something the community takes for granted and I want to do it in the best way I can.

Phantom Hoover:
I'm entirely in favour of this; the current situation with lighting settings is frankly an embarrassment and I'm personally sick of having to think about it at all. We've gone through 3 or 4 different overhauls of the lighting model since those parameters were introduced and more are entirely possible in the future.

-Joshua-:
I had a lot of fun messing around with lighting flags ~10 years ago but now with all the newfangled PBR and deffered lighting I'm happy if there's just a "one size fits all" solution rather then a bunch of things you have to manually set depending on which built you are on.

mjn.mixael:
There also seems to have been a general culture shift in the community where once there were vocal players would would commit murder if they lost the ability to fine-tune things. Now it seems most players are happy to let mods and artists have more say in how their creations look. +1 from me.

0rph3u5:

--- Quote ---allow mods to incorporate these changes directly into their files rather than relying on launcher flags to implement their visual design
--- End quote ---

You had me at this.  :)

Navigation

[0] Message Index

[#] Next page

Go to full version