Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Axem on December 18, 2013, 05:35:50 pm
-
Hey so in the mediavps open beta thread, there was a heated discussion about proper bloom settings and stuff. The mediavps can't really do much about it, because the code defaults to 75 no matter what the mediavps would try to do anyway. Only the user can change it with a command line flag that's not really documented within the launcher.
Is it possible to have some sort of post_processing.tbl option that allows the changing of the bloom flag so mods can, at their own discretion, change their bloom field to match their settings? Of course, that setting would be superseded by the -bloom_intensity flag, should someone want to be blinded by nebulas and stuff.
(Also making the default like 20 or something would be rad as well)
-
I agree with this.
Default 20 would be very helpful.
Bh
-
I believe more appropriate place for this would be the mod.tbl (or whatever its name is) that karajorma was/is working on. It should hold the default values for any command line options.
-
Yeah, that kind of mod-wide setting should be in game_settings.tbl
-
Well, bloom only works when post processing is enabled, so I'd have thought that post_processing.tbl was the best place for the mod defined default. I thought that game_settings.tbl was supposed to be for settings that didn't really fit anywhere else.
-
I tend to agree with post_processing.tbl is the place for this.
-
There are all kinds of defaults for lighting which most people don't use. We have a section in the FreeSpace Wiki that deals with that and an option in the launcher to use different sample lighting schemes. Maybe it should have a section for Bloom. I don't much care if we change the default as long as there is an easy way to adjust the settings. The command line works fine for me. I don't want to be locked into a particular setting by it being in a table that has to be modified. Lighting settings including bloom would depend on a person's preferences, the campaign's mission backgrounds or the monitor being used. I find I often change the lighting setting based on the campaign I'm playing or the computer I'm playing on.
-
Since this is starting to head down the road of 'modder's choice vs player's choice', I will say that I think wxL found the compromise for lighting settings that we've long been hoping for. They have (or are working on) a way for mods to have 'recommended lighting settions' as a radio button. It's perfect. Users can input whatever commandline they want, but mods have a way to say 'we recommend this'.
The defaults, don't really matter much to me either. But it seems to me that a system where Table is overwritten by Commandline while mods have a tool to offer a Recommended Setting, hits all the necessary points. Just wonder if wxL's radio buttons work with Bloom.
-
Since this is starting to head down the road of 'modder's choice vs player's choice', I will say that I think wxL found the compromise for lighting settings that we've long been hoping for. They have (or are working on) a way for mods to have 'recommended lighting settions' as a radio button. It's perfect. Users can input whatever commandline they want, but mods have a way to say 'we recommend this'.
The defaults, don't really matter much to me either. But it seems to me that a system where Table is overwritten by Commandline while mods have a tool to offer a Recommended Setting, hits all the necessary points. Just wonder if wxL's radio buttons work with Bloom.
this would be my preference, while a mod has the right to say this is how we think it should be played ultimately its the player who should decide how its played and they shouldn't need *any* modding skills to do it no matter how rudimentary they might be. so yes wxLauncher recommendations overridden by player preference all the way. personally for example i hate bloom
-
I don't want to be locked into a particular setting by it being in a table that has to be modified.
The suggestion was that post_processing.tbl would change the default Bloom value, not override the commandline setting.
-
Indeed. User preference should always take priority, it's only in cases where the user hasn't changed this option that the default should be used.
-
A comparison with the suggested intensity value of 20.
MediaVP_3612 with Bloom_intensity 75
(http://koti.mbnet.fi/olzie/Moebius/FSO_bughunt/bloom_3612_75.png)
MediaVP_2014_beta with Bloom_intensity 20
(http://koti.mbnet.fi/olzie/Moebius/FSO_bughunt/bloom_2014_20.png)
So as you can see, MediaVP_2014 nebulas are still bloomier with an intensity of 20 than MediaVP_3612 are with a default intensity of 75. MediaVP_2014 nebulas produce white burnt spots even at intensity of 15, whileas MediaVP_3612 nebulas have very little white spots even at bloom intensity of 75.
If you want to recalibrate the default value of bloom intensity in SCP engine, it probably needs to be even lower than 20. OR, someone with more experience in post-processing should probably look at the bloom code in an attempt to prevent the birth of these white burnt spots when a higher resolution is used in nebula graphics (that seems to be a correlation here).
-
Problem ain't bloom.
$Name: saturation
$Uniform: saturation
$Define: FLAG_SATURATION
$AlwaysOn: true
$Default: 1.28
$Div: 50
$Add: 0
$Name: brightness
$Uniform: brightness
$Define: FLAG_BRIGHTNESS
$AlwaysOn: true
$Default: 1.48
$Div: 50
$Add: 0Learn to blame the right things.
-
Right. There appears to be a great overflow of saturation and brightness when higher resolution nebulas are being post-processed. But on the technical side, I admit I have no idea what would cause this correlation between higher resolutions and overflows.
-
The correlation is that, at some point between the 3.6.12 MVPs and the 2014 MVPs, the post process table was altered to increase the brightness and saturation values. In concert with bloom, this causes the artefacts you're seeing.
-
Right. There appears to be a great overflow of saturation and brightness when higher resolution nebulas are being post-processed. But on the technical side, I admit I have no idea what would cause this correlation between higher resolutions and overflows.
I don't know why you keep going back to the irrelevant higher resolutions that aren't even remotely related to the subject at hand.
If you applied that post-proc table and those bloom values on retail assets you'd have similar output. Assets are not in cause here.
-
I don't know why you keep going back to the irrelevant higher resolutions that aren't even remotely related to the subject at hand.
Because I didn't know the truth and I was desperate to find even some reasons for this apparently unintuitive change in overall visuality. That was before I learned this:
at some point between the 3.6.12 MVPs and the 2014 MVPs, the post process table was altered to increase the brightness and saturation values.
If someone would have said this in the first place, I wouldn't have had to speculate about it at all :D
EDIT: spelling
-
Problem ain't bloom.
$Name: saturation
$Uniform: saturation
$Define: FLAG_SATURATION
$AlwaysOn: true
$Default: 1.28
$Div: 50
$Add: 0
$Name: brightness
$Uniform: brightness
$Define: FLAG_BRIGHTNESS
$AlwaysOn: true
$Default: 1.48
$Div: 50
$Add: 0Learn to blame the right things.
Bam. What a find. Btw, who the hell decided to push saturation and brightness that high as defaults? You'd have blown colors even without bloom on.
As an aside, compressed vs uncompressed textures basically comes down to blocking and/or ringing as artefacts. It's not even necessarily true that compressed textures are lower resolution compared to originals. Sometimes, if compression is fairly heavy, you get very slight loss of saturation or color accuracy.
The point is, to the casual eye or on a cruddy monitor, uncompressed and compressed textures should look virtually identical in almost all situations. (The only exception I've come across is using the new, smooth nebula poofs that aren't in the beta. While they're great as uncompressed textures, they become a blocky mess if you used compressed versions).
-
Here's the post_processing.tbl that shipped with the 3.6.12 MVPs:
#Effects
$Name: distort noise
$Uniform: noise_amount
$Define: FLAG_DISTORT_NOISE
$AlwaysOn: false
$Default: 0.0
$Div: 20000
$Add: 0
$Name: saturation
$Uniform: saturation
$Define: FLAG_SATURATION
$AlwaysOn: false
$Default: 1.0
$Div: 100
$Add: 0
$Name: contrast
$Uniform: contrast
$Define: FLAG_CONTRAST
$AlwaysOn: false
$Default: 1.0
$Div: 500
$Add: 1
$Name: film grain
$Uniform: film_grain
$Define: FLAG_GRAIN
$AlwaysOn: false
$Default: 0.0
$Div: 100
$Add: 0
$Name: stripes
$Uniform: tv_stripes
$Define: FLAG_STRIPES
$AlwaysOn: false
$Default: 0.0
$Div: 100
$Add: 0
$Name: dithering
$Uniform: dither
$Define: FLAG_DITH
$AlwaysOn: false
$Default: 0.0
$Div: 100
$Add: 0
#End
-
I wasn't even aware there was one in mvps12, but everything's set to false anyway so that's just like no table.
-
The_E, will that table work immediately as a drop-in, or do you also need entries for sunshafts to prevent the game from yelling at you?
-
Ask yourself: How much does the engine yell at you when you start a game with the 3.6.12 MVPs enabled?
-
Oh. I've been using a custom post-processing build, but with nightlies and/or BP builds. I just remember one time I got yelled at because it couldn't find (or was it because it found?) sunshafts entries. I asked the question as a reminder, but apparently I just remembered wrong :P