[railguy]

scottb613, on 08 January 2023 - 11:00 AM, said:

Hi Folks, true.jpgWould it be too much to have (4) hemispheres for clouds?

• Overcast Layer
• High Cloud Layer
• Middle Cloud Layer
• Low Cloud Layer

The "flattened dome" we have now in testing seems it would be good candidate for the Low Cloud Layer. The Overcast Layer should probably be the highest - so any cloud details included on the other layers could still be visible. Obviously - if performance is an issue - we can combine whatever layers are necessary to keep good performance. Blender may be able to help with various clouds once we know how the environment shakes out in ORTS.Blender Cloudshttps://youtu.be/iqR5BDUa5rgThis process would have us rendering clouds in Blender - then using the image rendered to make seamless textures. In Blender - the sky can be excluded from the cloud rendering.I have yet to try this but there are numerous tutorials on creating "Volumetric Clouds" for rendering and they look pretty good.Regards,Scott

Scott's analyses here are quite good. The biggest challenge with it would be modeling multi-layer cloud formations, such as cumulonimbus. Cumulonimbus clouds--the common "thunderhead"--can rise as high as 70K feet altitude, almost the top of the troposphere. Incumbent in all of this is having the sun, stars, moon, and planets ABOVE all of the cloud layers. In the current OR configuration, I find the moon to be so unrealistic that I wish that I could just eliminate it altogether.

The fog layer also behaves badly at night, becoming quite unrealistic, particularly if there are hills or mountains present.

Finally, having wind affect cloud layers and precipitation would be nice. This could be sort of "fudged" to work in MSTS, one of the few things in MSTS that worked better than OR.

[Genma Saotome]

railguy, on 09 January 2023 - 07:55 AM, said:

The fog layer also behaves badly at night, becoming quite unrealistic, particularly if there are hills or mountains present.

Probably too arcane but a couple of comments on fog: Here on the central coast of California fog is an afternoon/nightly effect -- it pours over the coastal hills as it is sucked inland (a 30C difference of ocean air/inland air temperatures produces a big difference in barometric pressure that pulls ocean air inland every afternoon). It is our natural air conditioning. What might be of interest to OR is such fog is high in most places, at least 100m AGL, and it tops out at 2000ft AGL. When you climb above 2000ft and look out the fog looks very much like the clouds you see under your airliner but completely thick like a blanket. It will settle down to ground level as the evening rolls on and so at dawn it looks like ordinary marsh fog, right down to the ground. It can be extremely dense on occasion ( I recall one evening where street signals could not be seen outside of 30-40 feet; I thought the power had gone out).

To replicate anything like this in OR, well, I dunno how. Would a combination of fog effect and overcast do it? Dunno. Maybe with a very low cloud layer? At any rate, if there is a practical answer that can piggy-back along with the other changes I be very grateful.

[James Ross]

Genma Saotome, on 08 January 2023 - 09:56 PM, said:

So a question or two: Am I correct in thinking the shadows were lighter as brightness was increased?

I am not very familiar with this code, but it looks to me like it applies the adjustment to brightness after calculating the texture, specular, shadow, and overcast effects - but before headlights and fog

So yes, you appear correct; it seems like any shadowed area which is not 100% black will get lighter as you increase the brightness setting

Genma Saotome, on 08 January 2023 - 09:56 PM, said:

Am I also correct that the brightness factor is simply applying a factor to the entire texture rather than the individual channels for RGB? I figure doing it this way is vastly easier but it can produce modest color shifts when the factor calculation results in a value for one or more channels that goes past 255.

It is written as a single multiplication in the shader code, but shaders are different from most traditional languages and use component-wise operation (I couldn't find a good reference for this in HLSL, but it's the same as GLSL) - which means that line of code multiplies each component of "litColor" ( R/G/B ) by "NightColorModifier" completely independently

Also, shader code almost exclusively using floating point numbers, so overflow from e.g. one byte (0 - 255) storage isn't an issue

Genma Saotome, on 08 January 2023 - 09:56 PM, said:

Overall I wonder if the current brightness method is realistic... Should not shadows remain unchanged or perhaps even darkened? Has anyone looked at only darkening shadows? Perhaps the increased contrast of normal texture, darker shadows might fool the eye and mind into thinking the normal texture is brighter, while retaining the original color of the texture.

Off-hand I do not know what the correct adjustment for shadows vs non-shadow should be for the brightness setting, or the changing daylight, but if you come across any real-world references on such things they'd be very helpful in establishing what we need to do :)

railguy, on 09 January 2023 - 07:55 AM, said:

Scott's analyses here are quite good. The biggest challenge with it would be modeling multi-layer cloud formations, such as cumulonimbus. Cumulonimbus clouds--the common "thunderhead"--can rise as high as 70K feet altitude, almost the top of the troposphere. Incumbent in all of this is having the sun, stars, moon, and planets ABOVE all of the cloud layers. In the current OR configuration, I find the moon to be so unrealistic that I wish that I could just eliminate it altogether.

The sun, stars, and moon are all above the existing cloud layer already

Adding more layers for the clouds (especially if they are visibly moving at different speeds/altitudes) should be a big improvement and is probably the best we can do without a complete rewrite

railguy, on 09 January 2023 - 07:55 AM, said:

The fog layer also behaves badly at night, becoming quite unrealistic, particularly if there are hills or mountains present.

The fog is currently just a distance-from-viewer effect, and may not even be correct for 100% even fog

A lot of games get by with a simplified volumetric fog system, and that might be what we need too, but it'll be a fair amount of work I expect

railguy, on 09 January 2023 - 07:55 AM, said:

Finally, having wind affect cloud layers and precipitation would be nice. This could be sort of "fudged" to work in MSTS, one of the few things in MSTS that worked better than OR.

The clouds currently move at a fixed wind speed and direction, which I'm going to fix so it matches the simulation's wind (which you can control with the weather file)

But I'm not sure what you have in mind for the precipitation? The angle rain and snow falls?

The precipitation code actually does apply a wind effect to the falling angle... but it does not seem to be connected to any of the other winds in the game (I think that makes FOUR now)

Genma Saotome, on 09 January 2023 - 12:31 PM, said:

To replicate anything like this in OR, well, I dunno how. Would a combination of fog effect and overcast do it? Dunno. Maybe with a very low cloud layer? At any rate, if there is a practical answer that can piggy-back along with the other changes I be very grateful.

Probably need a full volumetric implementation to do a good job of rolling fog/low clouds like that - not on the cards right now

[FS.E652 091]

I state that I am not a graphic developer, I have been working on railway simulators as a router for 10 years.. mine is simply a piece of advice that I give you based on my experience..

As far as Open Rails is concerned, in my opinion we need to evaluate both the arrangement of the skydomes and the atmospheric rendering.

Going back to 2004, already the famous Flight Simulator had a graphics software good enough to allow a flawless rendering of the sky, the atmosphere and related phenomena.

In 2022, these potentials applied to a simulator like Open Rails are, in my opinion, more than feasible..
But we must also try to arrange them in a logical and sensible way.

As far as the management of the skies is concerned.. in my opinion, it is not necessary to ensure that the simulator rests on a single Skydome.. simply because this will be unique in all the various bands of the day from sunrise to sunset..
We should take as a model of operation, the skies of games such as EuroTruck Simulator, which vary from Sunrise to Sunset .. with the intention of having a unified and standardized sky with dynamic and functional clouds ..

If a user uses Skydome and Clouds, it happens that the clouds will contrast with the Skydome, making the rendering unreal (unless you have a totally blue skydome and then the matter changes! )

As for the atmospheric rendering and relative brightness..

I noticed that on Skyshader files and stuff like that, that it all depends on the distance of the fog and its color..
by altering the color of the fog, I will have an atmospheric effect, but at the same time I am aware that it is not the atmosphere but the fog!

To be clear .. the atmosphere is one thing, the fog is another ..

We should add an atmospheric rendering effect with the typical depth effect that gives color and ambient brightness at the same time (an example is present on Google Heart with atmospheric rendering).

Last, but not least.. atmospheric phenomena and dynamic weather..
If in 2004 Flight Simulator had a realistic weather based on coordinates, and phenomena such as wind, rain, storm, etc..etc.. in 2002 Open Rails has all the potential!
it is unthinkable that if I want to simulate a train with adverse weather conditions, storm, etc... I have to limit myself only to the classic and boring rain without a minimum of wind with a lot of sound effect and which affects the physics of the convoy..
You have the potential to use the Web Server system.. , there are arguments on how to implement lightning bolts on this forum that has been discussed a lot, even the old MSTS through Kosmos allowed to have lightning bolts..!!

I sincerely would like you to exploit it in order to increase the realism of the simulation instead of transmitting a clock or data that I can very well see using F4 or F5...! and it is not a criticism, but an incentive to ensure that this simulator can become the flagship of the concept of simulation..

I also add that to date, the RTX gaming system offers nothing short of phenomenal graphical experiences, my pc is now built on an RTX system.. where Open Rails runs at 500 fraps on my scenario, i.e. I could also have a water rendering with a 3D shader, or a super detailed station with a scary 3D (and many of my scenarios have these characteristics by now), so, in an era of evolution like this, it's also only right that we can make the potential comes out..
Unfortunately I am not good with programming.. but I have always made sure that this topic can always be sensitized, because from my point of view, working on the construction of scenarios also involves many challenges and a lot of time, and in the end satisfaction is that of being able to receive compliments not only for the work I have done .. but mainly for the work of each of you in making this simulator even better!

I will constantly follow this discussion, hoping that concrete results can be achieved.
I know that developers are needed, and people who can realize all these requests, but if we are a community each of us is here to share and improve.. so I'm confident! and with this screen I show you how much potential lies in this program!

Attached thumbnail(s)

• 

[railguy]

James Ross, on 09 January 2023 - 03:53 PM, said:

I am not very familiar with this code, but it looks to me like it applies the adjustment to brightness after calculating the texture, specular, shadow, and overcast effects - but before headlights and fogSo yes, you appear correct; it seems like any shadowed area which is not 100% black will get lighter as you increase the brightness settingIt is written as a single multiplication in the shader code, but shaders are different from most traditional languages and use component-wise operation (I couldn't find a good reference for this in HLSL, but it's the same as GLSL) - which means that line of code multiplies each component of "litColor" ( R/G/B ) by "NightColorModifier" completely independentlyAlso, shader code almost exclusively using floating point numbers, so overflow from e.g. one byte (0 - 255) storage isn't an issueOff-hand I do not know what the correct adjustment for shadows vs non-shadow should be for the brightness setting, or the changing daylight, but if you come across any real-world references on such things they'd be very helpful in establishing what we need to do :)The sun, stars, and moon are all above the existing cloud layer alreadyAdding more layers for the clouds (especially if they are visibly moving at different speeds/altitudes) should be a big improvement and is probably the best we can do without a complete rewriteThe fog is currently just a distance-from-viewer effect, and may not even be correct for 100% even fogA lot of games get by with a simplified volumetric fog system, and that might be what we need too, but it'll be a fair amount of work I expectThe clouds currently move at a fixed wind speed and direction, which I'm going to fix so it matches the simulation's wind (which you can control with the weather file)But I'm not sure what you have in mind for the precipitation? The angle rain and snow falls?The precipitation code actually does apply a wind effect to the falling angle... but it does not seem to be connected to any of the other winds in the game (I think that makes FOUR now)Probably need a full volumetric implementation to do a good job of rolling fog/low clouds like that - not on the cards right now

Just a couple of comments and questions:

If I read this correctly, a weather change event can modify the wind speed and direction? But, wind will not affect how precipitation falls? For example, in blizzard conditions, snow can not "fall" at a near horizontal angle? (When I lived in Wyoming, we locals joked that seeing snow fall vertically rather than almost horizontally was "not normal.") Also, I know that precipitation intensity is currently "clamped" to a certain maximum. Could that be "unclamped" to allow heavier precipitation, with the simmer balancing the effect against the potential lowering of frame rate on the simmer's particular computer?

As always, thanks to all who are working on these improvements.

[James Ross]

I have created a PR for fixing sunrise/sunset times included in Unstable Version U2023.01.15-0151:

• Load sun rise/set times from MSTS environment files
  
• Apply them to the sun position calculation
  
• Fix the movement of the sun in the sky

[James Ross]

railguy, on 14 January 2023 - 10:15 AM, said:

If I read this correctly, a weather change event can modify the wind speed and direction? But, wind will not affect how precipitation falls? For example, in blizzard conditions, snow can not "fall" at a near horizontal angle? (When I lived in Wyoming, we locals joked that seeing snow fall vertically rather than almost horizontally was "not normal.")

Currently the precipitation "wind" is entirely controlled by the liquidity (i.e. where it is on the rain/snow scale)

There seems to be a lot of places that do wind weirdly like this, and I would like to fix them to all use the actual wind set by the weather change event

railguy, on 14 January 2023 - 10:15 AM, said:

Also, I know that precipitation intensity is currently "clamped" to a certain maximum. Could that be "unclamped" to allow heavier precipitation, with the simmer balancing the effect against the potential lowering of frame rate on the simmer's particular computer?

Currently it looks like we define precipitation density from 0 to 1 by simply scaling from zero to the maximum number of particles allowed, which is completely arbitrary but probably not a good idea to simply increase - we can probably do a better job of making it appear heavier than we currently do :)

We should be defining it using real-world measurements, such as mm/h and perhaps using the METAR list of precipitation types

In any case, the wind needs fixing first so that at least the clouds and precipitation match the simulation (and weather change events); after that, maybe other bits of the weather can be improved :)

Weter, on 14 January 2023 - 10:43 AM, said:

Tell me please, why Sun isn't bright-bright orange, but greenish-white all the time?
Why it inflates near horizon and follows broken zig-zag trajectory near afternoon?

The colours of the sky, sun, moon, stars, and clouds will all be looked at soon

As it happens I also spotted the weird zig-zag trajectory of the sun and that should be fixed in the Unstable Version U2023.01.15-0151

[Genma Saotome]

James, you asked for more info on lighting. I took I screenshot, pulled into my art software and adjusted/saved copies so you could see how certain functions changed the appearance. Hopefully it will be of some use.

First, orig9inal, then +10% brightness, then +20% brightness. All images are 4k, click on any to increase to full size and color.

Screenshot



Lightness increased by 10%



Lightness increased by 20%

Obviously just increasing lightness produces a washed out image.



Repeating the series, this time increasing contrast.

Screenshot



Contrast increased by 10%



Contrast increased by 20%

Much more interesting.



Last, since I was using photo editing software I tried the auto balance tone function -- white whites and black blacks -- to make it look like a good photograph.

Screenshot



Tone automatically balanced.


A final thought; I make all of my own textures and of late have been adjusting older textures to desaturate them. The autobalance strips all that work right out of the data. But it still looks very good because we're all used to our cameras doing that. The other thing I noticed in the original screenshot was there was a lot of gray everywhere. I don't know if that is my own effort to desaturate things or that the OR software is doing something; it was apparent that the added contrast reduced the gray, as did the auto balance tone.

I will continue to poke around on the web to see if I can find some more knowledgeable ideas than my attempts above.

[Genma Saotome]

James, This might be useful as it is a question from a game programmer.

[Jonatan]

Interesting topic, some of the screensots look realy nice. :good:

This may not be relevant, but have anyone brought up the posibility of lightning in the skydome? In Vehicle Simulator Framework and its predecessor Virtual Sailor the developer had a decently realistic lighting simulation with a vertical sprite striking at random location, followed by a thunder crash with random delay time and loudness.

It is a striking visual phenomenon of the sky that usually can't be ignored and would be a nice addition to the sim.