weather.wdt (and other things to mod track lightning)

for some time I wonder how far we can/could push the GP4 engine's lightning/shading capabilities
yes - they are rather basic compared to modern game engines
but let's collect the "wisdom" about the tweaks available in track making to mod track lighting

imho the file weather.wdt is quite powerful
- some settings (I think the first 7 variables) seem to influence shading (of some objects/materials) in general
- some settings (I think all the other variables) seem to be connected to the dynamic sky changes (and SkydomeDomeHeight v2 must be -1000 to enable the sky dome with hd sky textures)

more or less by chance I've already noticed that some variables of weather.wdt (or: how they influence the game's graphic) seem to be connected to some of the material properties we can assign to individual objects/parts

so - given the time - I will start with testing the variable "DirectionalFogScalar" and report my findings here
I did have a look in the GP4Builder manual and did a quick search of the forum and didn't find the variables explained
but
- if this is all an old hat: please tell me so (and I will shut up)
or
- if you do have a observation to share: please do so

cheers
xandy



Edited 1 time(s). Last edit at 11/07/2013 08:06AM by xandy.

I'm looking foward on this.

------------------------------------------------------------------------------------------------

PLEASE VISIT: Grand Prix Mods Blog

first of all my starting point: weather.wdt from the original a1ring (only SkyDomeHeight changed)
test will be done with only one variable at a time, so correlation of variables must be analyzed later on

version 2
         1.000		;DirectionalFogScalar
         0.240		;AmbientConstant
         0.750		;AmbientFogConstant
         0.250		;AmbientFogScalar
         0.480		;AmbientLevelRebalance
         1.500		;DirectionalLevelRebalance
         0.100		;MinFogBright
         1.000		;FogWetScalar
         0.000		;GreyBlueRampSplit v2
         0.000		;GreySkyScalar v2
         0.000		;Blue_R
       102.000		;Blue_G
       255.000		;Blue_B
       245.000		;FarBlue_R
       250.000		;FarBlue_G
       255.000		;FarBlue_B
         0.140		;FogBlueSkyLerpFactor
         0.500		;NearFarBlueSkyFactor
         0.000		;SkyColourCentreDeltaX
         0.000		;SkyColourCentreDeltaY
         0.000		;SkyColourCentreDeltaZ
        -1.000		;SkydomeHorizonHeight v2
     -1000.000		;SkydomeDomeHeight v2
         0.000		;SkydomeHorizonHeightForReflections v2

screenshots are made with GPxPatch, downscaled and gamma-corrected (value: 1.3) with GIMP

DirectionalFogScalar
original tracks: always set to 1.000



my conclusions for DirectionalFogScalar
- meaningful usable range 1-16 (other values may give artefacts)
-- range 1-8 effects tarmac of track/pitlane (all what is painted per .bin I think) - higher values bring darker tarmac - jip mappings and track "glare" are dimmed too
-- range 9-16 effects unshaded parts of objects - higher values mean darker "lighted" objects
- real numbers do work, so the effects can be fine-tuned
- some objects are not affected (example: horizon/sky/tree... in above picture) perhaps due to object class or material properties

Nice work, also on the Jerez track.

---

My Grand Prix 4 Files
I'm a total dick. How many people can say that?

Nice work, always good to see experimentation on this sort of stuff!

---

X (@ed24f1)

Nice work! I suggest you also check your results in wet sessions. Use a random seed in GPxPatch to ensure you always get the same conditions.


My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com

AmbientConstant

original tracks: 0.240 or 0.250 (Imola, Melbourne, Monaco, Monza, Sepang, Silverstone, Suzuka)

not much to report on this one

observations for AmbientConstant
- usable range 0-1 (perhaps !!!)
- no discernible effect on track lightning (with positive values - did test quite a lot)
- negative values give coloured tint to shaded surfaces (-8=yellow tint / see picture below / may be useful to check your normals in game )

AmbientFogConstant

original tracks: 0.750 except for Spa with 0.800



observations for AmbientFogConstant
- usable range 0-1
- lower values give darker shaded and lighted surfaces (see below concerning the use of these terms)
-- most differences are visible in the range from 0 to 0.4
-- effects on tarmac of track/pitlane (all what is painted per .bin I think) - lower values bring darker tarmac - jip mappings and track "glare" are dimmed too
- negative values give coloured tint to shaded surfaces (see AmbientConstant)
- some objects are not affected (example: horizon/sky/tree... in above picture) perhaps due to object class or material properties

now about the "layman's terms"
as far as I understand it the lightning of the track follows the correlation of normals and sun (light) position
- normals of the surface pointing to the light -> surface is lighted
- normals of the surface pointing away from the light -> surface is shaded
in the picture above one can see no effect of the changes on all "flat" surfaces, with this I mean the grass/the sidelines etc - i.e. surfaces with normals pointing more or less upwards - these surfaces seem to be not "lighted" or "shaded"

finally a word on the objects which are not affected (see also DirectionalFogScalar)
- this needs further investigation for sure, but the material property "Illumemmissive" seems to be the culprit
- if "Illumemmissive" in the GP4Builder Material Editor is set to black the surface is lighted/shaded as expected, selecting some other colours leads to the result seen with the horizon in the picture above



Edited 1 time(s). Last edit at 11/14/2013 03:34PM by xandy.

By the way, all variables from "Blue_R" to the end of the file apply to the game's original skydome, so you won't notice any changes while using a custom skydome.

Blue_R, G and B are the RGB color values for the sky up high.
FarBlue_R, G and B are the RGB color values for the lower sky, closer to the horizon.
FogBlueSkyLerpFactor, I don't know.
NearFarBlueSkyFactor, I believe this controls how the color progresses from Blue to FarBlue.
SkyColourCentreDeltaX, Y and Z move the position of the center coordinate for the Blue color.
The three final values are self-explanatory I believe.


My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com

@prblanco
thank you very much for the information - I'll do the "test for the rest"

AmbientFogScalar

original tracks: always set to 0.250

not much to report on this one
same as with AmbientConstant

observations for AmbientFogScalar
- usable range 0-1 (perhaps !!!)
- no discernible effect on track lightning (with positive values - did test quite a lot)
- negative values give coloured tint to shaded surfaces

AmbientLevelRebalance

original tracks: 0.470 (Barcelona) to 0.500 (Imola, Melbourne, Monaco, Monza, Sepang, Suzuka)



observations for AmbientLevelRebalance
- usable range 0-1
- lower values give darker shaded and lighted surfaces
-- effects on tarmac of track/pitlane (all what is painted per .bin I think) - lower values bring darker tarmac - jip mappings and track "glare" are dimmed too
- negative values give coloured tint to shaded and lighted surfaces (see picture below)
- some objects are not affected (example: horizon/sky/tree... in above picture) perhaps due to object class or material properties

comparison to AmbientFogConstant
- effect is more pronounced (larger range from dark to bright)
- shaded surfaces get "more brightness" than lighted surfaces with higher values (with 1.0 the difference between shaded and lighted is nearly lost)
- given the similarities and differences between "AmbientFogConstant" and "AmbientLevelRebalance" there could be the possibility to achieve good result with some combinations of these variables (darker shadows as an example)



I really do invite you to set the AmbientLevelRebalance to -8 for one of your tracks and do a T-Cam round to see which surfaces are affected and which aren't by this "ambient lightning" lark

I'm still at it - but with a different approach
at first I only wanted to describe the effects of changes in weather.wdt with terms like "darker", "shaded surfaces" etc but for a better understanding of the ambient lightning or fogging I think some objective data is needed

to get it I
- build a simple wall in GP4Builder with 5 rectangualar parts using "TrackMat" as material and assigning a non-existent texture
- set the sun position to 0/0/-1, which means a top down sun light (this being the sun vector and making the next step easier for my rusty knowledge of vector arithmetics)



- calculated me a set of vertex normals with different angles between sun vector and normal (a normal of 0/0/-1 means there is an angle of 0 between sun vector and vertex normal, 90 degrees are achieved with a normal of 0/1/0, 170 degrees with 0/.174/-.985 etc.)
- assigned different vertex normals to the five parts of the wall
- used different settings in weather.wdt for AmbientFogConstant (AFC) and AmbientLevelRebalance (ALR), ie for the variables wich showed visible effects in the first round of tests

in game I took screenshots of the wall and (with the unedited bmp) picked the colour of the five wall segments in GIMP



here are some of the results



the lines represent different settings for AmbientFogConstant (AFC) and AmbientLevelRebalance (ALR) in weather.wdt - the magenta one being the default settings for most tracks
the ambient lightning/fogging works with (I don't know the correct technical terms) "overlayed shades of grey" (or perhaps: "a black overlay with different level of transparency" ?), the colours picked from the screenshots are always in the grey range (i.e. R=G=B 0..255) on the white (unpainted) background - the RBG values are given on the Y-axis
on the X-axis you find the angles between sun vector and vertex normals
example: with the default weather.wdt (magenta line) and an angle of 110 degrees between sun vector and vertex nomals "the surface is overlayed with a grey value of 209/209/209"
the black line (ALR=0) is a special case - with ALR=0 the setting of AFC doesn't matter and the whole range of RGB=0 (solid black) to RGB=255 (no overlay) is used

three questions:

- what happens with angles less than 90 degrees?
-- if the vertex normals point in the same direction as the sun vector (away from the sun position - angle under 90) nothing changes, the grey values given in the chart for 90 degrees are the "maximum blackness" of shaded surfaces - so with the default setting shades won't get "darker" than with an overlay of RGB 122/122/122

- what's up with angles above 180 degrees?
-- in range 180..270 the values for 0..90 are mirrored, for >270 degrees the above said applies

- there seems to be no shading with angles greater than 130 degrees (default setting) - perhaps there is a "white overlay" to "light" the surfaces if vertex normals point more or less directly into the sun?
-- I've tested this with coloured surfaces and no I couldn't find a "white overlay"

more comments on the results in a later post



Edited 1 time(s). Last edit at 11/11/2013 11:35AM by xandy.

Epic post! Very interesting test.

---

My Grand Prix 4 Files
I'm a total dick. How many people can say that?

@Turbo Lover - thank you

did a further test with a RGB texture
texture has three parts RED (RGB 127/0/0), GREEN (RGB 0/127/0), BLUE (RGB 0/0/127)



after re-running the tests shown in the last post the result for RED (RGB 127/0/0) looks like this



dependant on the sun/normal angle only the R-value of the shaded surfaces changes, i.e. with the default setting (magenta line) and an angle of 110 degrees we get a surface colour of 101/0/0
this said the chart is very similar to the one from the grey/unpainted surface test
the scale is different (0..127 vs 0..255) but this is only further evidence for there not being a "white overlay" for "lighted surfaces" (why the R-value maxes out with 123 and not 127 I don't know - perhaps an effect of mipmapping)
for GREEN and BLUE the result is identical (GREEN maxes out with 125)

with this I'm quite sure to say
- ambient lightning/fogging works in dependance of angle between sun vector and surface normals on all three RGB channels in the same way
- all surfaces with normal/sun angles<=90 (or>=270) are shaded as dark
- between 90 and 180 the shadows are getting "brighter" in an approx. linear way till the colour of the original texture is reached (mirrored in range 180..270)
- the "darkness" of the shadows and the angle at which the ambient fogging is cut off is dependant on the variables AmbientFogConstant and AmbientLevelRebalance
- the gradient of the "lightning curve" seems not to be changeable

so that's it with testing for now - don't see the wood anymore with all the trees
what's about "DirectionalLevelRebalance", "MinFogBright" and "FogWetScalar" you ask - the first one acts similar to DirectionalFogScalar, with MinFogBright I didn't see any effects and the Wet in FogWetScalar should mean there will be needed a different test setup - Prblanco already explained the other variables

finally some thoughts on practical use

- DirectionalFogScalar in the range 1 to let say 3 can be used to get darker tarmac (and the track glare is reduced with higher settings) - so that one may be worth a try

- the ambient lightning controls work for me like a brightness control (it seems AmbientFogConstant and AmbientLevelRebalance do the same thing but with different scale and range) - so we can get our shadows "darker" or "brighter" (and influence how many of the surfaces are affected) but we sadly can't control the "contrast" or levels overall

- all my tests let me believe that for parts with a material that has some non-black colour set as "Illumemmissive" there is no ambient lightning - in most tracks trees and crowds have this kind of material (and trees may look peculiar and crowds may look dull with shading) - but with imported/modified objects it may be advised to check the materials (more on this see post below)

- clearly "checking of normals" may also be advisable and we can have some "fun with the normals" by setting them manually - as an example - for surfaces of buildings which are in shadow of other parts but have a normal/sun angle which results in "not enough" shadow - there are many possibilities to play around with normals (yes I know - if you change them they aren't normals anymore ) but for this you must be sure about your vectors and trigonometry


thank you for your interest
xandy



Edited 1 time(s). Last edit at 11/14/2013 03:35PM by xandy.

I believe I found a good explanation to the AmbientLevelRebalance setting, based on xandy's tests.

Let's say you hold a book between your sight and the sun. One of the covers is directly facing the sun, and the other directly opposite to it, facing your eyes. The side facing your eyes receives no lighthing from the sun, which is equivalent to a "0 degree normal" in xandy's example. So why isn't it black?

It's not black because it receives light reflected from other objects - the ground, walls, trees, whatever is around you, including yourself and your arm holding the book in its position. If you were in outer space, the side of the book facing you would be black, with no objects around to reflect light.

That's what AmbientLevelRebalance does. It translates the reflection of the sunlight that occurs naturally, and sunlight equals ambient light here. That's why zero ALR is the only setting that gives black surfaces (no sunlight reflection) and ALR set to 1 sets all surface to maximum brightness (100% sunlight reflection). Also a good reason to not deviate too much from the default values

And may I suggest another test? What happens if your RGB-colored object is set to white, red, green or blue Illumemmissive? Does it affect each color differently?


My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com



Edited 1 time(s). Last edit at 11/13/2013 11:52AM by Prblanco.

@Prblanco

nice explanation - thank you

and ... "good reason to not deviate too much from the default values" - you are the one with the "dark" Sepang 2009 (0.300 - AmbientLevelRebalance), aren't you

concerning further tests:
I've already cleaned up the gp4, so must rebuild the wall with the normals (not much to it) and will do it later this week
you mean the Illumemmissive Colour setting in Material Editor, do you?

Yes, but that race started at 5 pm

Just kidding, I really didn't remember we changed that value. You caught me

About the Illum. setting, that's the one.


My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com

it always a good idea to make one test more

back to Prblanco's request

Ambient Lightning and Illumemmissive Colour setting in Material Editor

Black (RGB=0/0/0) - tested above
White (255/255/255) - no Ambient Lightning
Red (255/0/0) - no Ambient Lightning
Green (0/255/0) - no Ambient Lightning
Blue (0/0/255) - Ambient Lightning as with Black

"no Ambient Lightning" means that all surfaces are displayed with the colours of the original texture independent of the sun/normals angle (I think that is the same as with Self-Illum material - GP4Builder manual: "if checked, part won’t receive dynamic computed lightning" )

the Blue one was a surprise
and now it gets funny:
- all RGB combinations with R in (0..12) AND (G in (0..242) AND B in (0..12) OR B in (13..255)) seem to turn Ambient Lightning on
- all other combinations seem to turn Ambient Lightning off
but really couldn't check them all

I've tested three "turn on"-combinations (12/255/13, 0/0/255, 7/31/38) against the "black Illumemmissive" with the RGB texture and using the five AFC/ALR settings explained above: the results are always the same as with Illumemmissive=Black

so: the setting "Illumemmissive" in material properties influences wether but not how ambient lightning is working

that's the deal ... for now ... until we find some obscure settings or put other material properties into the mix perhaps

new round of tests

Object Classes and Track Lightning

test setup:
- sun vector set to top down (0/0/-1)
- wall with ten parts and for each part manually set normals to get sun vector/normal angles in the range from 90..180 degrees
- texture for wall parts with 3 coloured stripes (red (RGB=127/0/0), green (0/127/127) and blue (0/0/127)
- 2 different Illumemmissive Colour setting (black - should turn on ambient lightning / green (0/255/0) - should turn off ambient lightning)
- 2 different settings in weather.wdt (standard - AFC=.75,ALR=.48 / extreme - ALR=0)
- check of colours on wall in game with screenshot and colour picking in GIMP

(btw: really would appreciate it if someone (perhaps with an ATI/AMD card) could re-run some of the tests, the "test wall", texture and short howto you find here
[www72.zippyshare.com]
thank you)

step by step I will check all the object classes in GP4Builder (see manual for more information) with the four-way test, always using the above described results with a NLAND object for comparison

as a short preview for things to come (maybe)

SCREEN object
is used for video walls - surface on which the fixed tvanim.tex or some dynamic in game shots are displayed
result: the SCREEN object is always shaded (i.e. gets "darker" if normals of the surface point away from the sun) even with green (0/255/0) as Illumemmissive Colour or with material properties set to "Self-Illum"
this isn't logical in my book - video walls should be self-illum.
to get them bright and shiny you can use normals for the screen pointing towards the sun (an inverted sun vector could be the best option)

well I would love to be driving the first 10 laps then have lightning flashing the next 10!
go you good things!

Latest Themes / Mods > [www.mediafire.com]
You Tube Video's [www.youtube.com]
________________________________________±