search

scp-fs2open / fs2open.github.com

Origin Repository for SCP FreeSpace 2 Open
https://www.hard-light.net/
Other
405 stars 162 forks source link

A Collected Lighting Feature Wishlist/Proposal #3492

Open EatThePath opened 3 years ago

EatThePath commented 3 years ago

When I was fixing beam lights I noticed several things about the state of Freespace lighting, as well as related options that I think should change. In many cases I'm not locked too hard on any one change and am oepn to input. This is all stuff that I want to eventually do, if nobody else takes it up first, but I want to be sure I'm doing it right, and that it's all changes the SCP wants to include, before I start digging in. Maybe it should be broken up into multiple issues for proper discussion, but it's all related ideas and I didn't want to flood the tracker. However works best, I would very much appreciate some yea or nay or other guidance from the powers that be on any or all of this. Maybe it should be workshopped on the forums too for user visibility?

SPECULAR LIGHTING AND THE LIGHTING FLAGS

The community seems to generally view the lighting flags as general brightness controls, but they only affect the specular component of the lights, not the diffuse. I'm not too versed in the math or physics behind there being two different lighting components, but I can talk about the effects I've observed. That effect is that some ships, in particular (?some?) pre-PBR ships of which there are many still in use, are lit only by diffuse lighting and see no change from the flags.

I think that should change. If I'm going to scale the lighting, I want to scale it all. Maybe it would make sense to implement a second set of flags for diffuse lighting. Maybe it would make sense to make the specular flags scale both. Maybe it would make sense to make it a game option or flag to make the specular flags scale both but leave the default behavior alone. Maybe something else would be best, but I don't think the current state is good.

In the long run I'd love to see the lighting flags retired in favor of in-game lighting settings, but for now flags are the tools we have and I'd rather those tools be good.

AMBIENT LIGHTING FLAG

The ambient lighting flag is insane. Maybe there's a niche reason to want what it does, but needing a 150 word wiki entry, a general understanding of the actual ambient lighting numbers in the missions you'll be playing, and a calculator in order to pick a good value for what would in a sane world be a simple multiplier attached to a slider is nuts and bad. If I recall correctly the formula used can also distort the hue of the ambient lighting in some cases, which is probably not noticeable much but is just in principle bad.

IMO the flag should just be replaced with saner behavior. This'll break everyone's lighting presets though I guess, so maybe a different approach should be taken. Maybe I'm wrong and this is actually how lighting is typically scaled under the hood for unintuitive reasons, stranger things have happened, but there's got to be a more intuitive way to present it to users if so.

LIGHTING OPTIONS/FLAGS AND SCALE

This one is a little speculative, but maybe it'd be cool to throw in a user settable scalar on lighting size? This way users could flex with their big strong GPUs by cranking that up and seeing beams light up everything and whatnot, and they could compensate for the increased brightness by turning down the brightness with the existing flags.

LIGHTING FLAGS AND MINIMUM VALUES.

I can imagine why someone would put a minimum value in the light scaling flags, and I disagree with it vehemently. Hacking together a build that lets me black out light types completely has led to both very useful debugging sessions AND very striking visuals. Remove the floor, let users live in darkness should they so choose. But let the emissive flag take precedence...

ACCESSIBILITY

It's possible that 'fixing' the ambient lighting flag would make it harder to maintain visibility in dark levels for people using the flags for that. To safeguard against that I would suggest allowing the emissive flag to accept a parameter to act as a new minimum brightness for ambient lighting.

MODDER TUNING OF WEAPON LIGHTS

Right now, the light cast by weapons is only very slightly adjustable by modders. Sizing of laser and missile lights is fixed, laser light color is controlled by the laser color table entry, IIRC beam color is too, missile color is always white, and beam light width is controlled by beam width. That works, and the defaults aren't bad, but I think it's holding things back. Imagine if Shivan megabombs cast an eiree red light that reached their target's hull, for instance. Utterly impossible now, and that’s a shame.

I don't know if it'd make sense to give modders separate control over specular and diffuse components of these lights. If it does, then let it be so.

LIGHTING MAGIC NUMBERS

Right now the lighting process is rife with magic multipliers. A beam creates a tube light based on it's width, times a constant, and then that size is multiplied by a magic number when handed off to the GPU. Point lights go through a similar process but are multiplied by a different radius. If/when weapon light controls are handed over to modders I think these should be as much as possible baked out, so that any values that modders enter in are exact meter radii and are passed through the code to eventually reach the GPU without having been touched by any static or hard coded values. Situational or optional scalars are fine of course.

ATTENUATION FORMULA

As far as I recall, all lighting in FSO currently uses linear falloff equations. I believe it would look better if it used one of the equations that better mimicked realistic lighting falloff. The effect can be subtle, but I can try to produce visual comparisons that show it if that is required.

MISSION LIGHTING CONTROLS

This is a perhaps only tenuously connected to the rest, but I think the mission format should allow the direct overriding of the directional lighting. Use the existing suns as a default, but mission makers shouldn't have to add new table entries to that to get bespoke lighting setups for a mission.

That's what I've got. Again, I'd very much value some feedback on the desirability and best route for these.

Baezon commented 3 years ago

Re: MODDER TUNING OF WEAPON LIGHTS I completely agree, imo this is the biggest elephant in the room of your issues here.

Re: LIGHTING MAGIC NUMBERS This is unfortunate, but I don't think quite as big a deal as you make it out to be, more often than not these magic numbers are meant to make the final result more intuitive to the user, but it can definitely work the other way around for the coder looking at it. They are often specifically chosen to compensate for some quirk of the system, or otherwise have to re-interpret the value because the internal system uses the number differently than the way the user was presented the value (these aspects should be noted in comments, but they are often not).

By all means, the exposed number should be as straightforwardly related to the result as possible, but don't get too hung up on making it exactly 1:1 meters if difficult. The most important quality is that it behaves in consistent and predictable ways, i.e. higher = bigger or whatever. Modders are going to tweak and futz with the number either way, and as long as they understand the general relationship between the number and the aspect, they rarely need more.

Re: ATTENUATION FORMULA Agreed, but be careful, I would really love to see an exponential function instead, because I suspect that will look much better, but care must be taken to choose magic numbers (your favorite) to mimic the general intent of the existing linear lights as much as possible. Anything older converted to this new system should still look pretty good, which brings me too...

Re: AMBIENT LIGHTING FLAG ...all I have to say on this topic is to reiterate that anything that was using the old system should still look at least close to what was intended before. Obliterating the look of the lighting unless you use the new system is a non-starter. Plenty of mods use specific lighting flag values very intentionally, and we need to try to maintain that.

The rest is out of my wheelhouse.

EatThePath commented 3 years ago

@Baezon On the magic numbers stuff, I understand your points and they're defintely worth keeping in mind. But, I think there's two values in keeping the evolution of the numbers as clean as possible. One is that when a coder goes rooting around they have as few confounding factors as possible, as a general rule.

The other is that I do believe it generally makes getting what you want out of the engine easier. My go-to example would be with the turning times; I have in the past tried to engineer specific interactions of turn times and weapon lifetimes, and it never worked as I expected because unbeknownst to me at the time the turn times were just relatively suggestive but not actually accurate. This kind of thing might rarely come up, but if someone wants to set up a scene with a 500m light for specific artistic purposes and it's actually a 300m or a 750m light or whatever, it's going to be a lot more back and forth between fred, files, and gameplay to find the actual number they need. That's possible enough worth avoiding, I think, even if it is very niche.

It's possible an additional fudge factor would be needed along the way to get things looking right as you say in the attenuation comments. But that's part of why I want to consider this all together, because I think the way to handle it is... suppose that laser lights right now have a final radius of 10 after all the steps, and to get them looking right with falloff changes they need to be radius 14.14 or whatever. I would then want to make 14.14 the default value of the new light radius table value and apply that *1.414 multiplier, along with the existing light radius multiplier, as adjustment constants within any other code paths that can add point lights. I can't think of many except maybe explosions and portals, and I'd probably want to apply similar table-exposure to any that do exist in which case the same default-setting solution can be applied to them and the adjustments thus pulled out.

Stepping back from that noodly bit, I also recall something I recently saw I think @PhantomHoover say, which is that major graphical changes have to worry a bit less than gameplay changes about backwards compatibility because they're immediately visible rather than silently gumming up the works of fragile missions in the background. PBR wasn't held strictly to reproducing retail visuals, because that's impractical and defeats the point. Obviously what I'm proposing doesn't rise nearly to the impact or obviousness of PBR, but maybe the principle applies a little bit? Food for thought in any case, this is ultimately not my ship to steer 😄

Baezon commented 3 years ago

Of course, graphics changes are not held to the same standard as gameplay changes but there are still limits. I'm just saying that the old system should still produce at least roughly equivalent looks. Changing .dds rendering for instance to a new version that will horribly mangle the colors of older .dds' for instance would be out of the question, even though its just graphical and wouldn't affect retail.