[scottb613]

Genma Saotome, on 06 January 2023 - 07:55 PM, said:

Going back to the Terragen product, I watched one of their videos and was impressed at the products ability to produce different types of clouds (per differences in altitude). Could those different clouds be "migrated" from their art to whatever form (texture?) is planned as discussed somewhere in the above posts?

Hi Dave,

Since the goal is a living changing dynamic sky - I can't think of any way to use the Terragen software with the skydomes I've already made - as when you look at the domes I produced - the projection scales the clouds as they go off into the distance on the horizon - which would negate any use in a moving cloud system. I would hope that whatever we do with the environment - we don't break the ability to use Terragen skydomes for those who wish to use them.

Perhaps I could try using a normal camera - point it up and snap an image for use in making a seamless texture. I don't know of any way to "green screen" the sky so I could isolate the clouds. The sun is also "hidden" at the zenith of the dome which would complicate that procedure as well. I'm not saying that it's not possible - just that I have no idea as to how to do it.

I've come to terms that whatever I do - it is not going to look as good as what I can make with Terragen.

Regards,
Scott

[scottb613]

Weter, on 06 January 2023 - 09:55 PM, said:

@Sean
There's a reason for being careful: some time zones are conventional (either not match actual geographic coordinates of the place by time shift, position shift, or just being averaged for quite wide area) - also, as RailGuy have noted.
But You are right in Your next post: for exact matching between simulation time and appropriate sun's position, well need to take in account all these three values: two geographic coordinates and conventional time zone for final correction.
@Scott
1.Your overcast clouds looking very good, IMO
2. Yes, about a year ago, one member from Danmark shared a video with his blizzard implementation attempt.
Shadows there indeed looked veery odd.
3. Playing with Ctrl+/Ctrl- already influences in-game brightness and gamma quite notably.

Hi Weter,

Thanks and yep...

:)

Regards,
Scott

[scottb613]

PerryPlatypus, on 06 January 2023 - 10:25 PM, said:

Scott,

Not sure if it's just me, but I get strange visual issues with your clouds01.png from this file if I increase Cloud Cover % to anything over 20% using CTRL + PLUS. This seems to happen regardless of how high visibility is set to. It's as if the contrast is too high in the image file.

I don't get the issue with your cloud file from Post #124.

I will note that the file from post #124 *appears* too monochromatic / grayscale in general and should have a *slight* natural blue tint in the clouds, HOWEVER I'm not certain if it's worth expending a ton of effort at this point to fix yet. I think as we begin to do work on improving the color shift / hue of daylight through different times of the day and through different percentages of cloud cover, that will have a big, big effect on the color/hue of the clouds (as it should). So better to not spend time adjusting hue / "white balance" of the clouds until we have the lighting colors figured out.

Hi Sean,

Yeah - I get that too. Perhaps it's related to how the textures displayed - if you look at my latest texture - it's pretty dark and black - yet when displayed in the sim it still looks pretty white. Obviously it's being processed in some manner.

If we can have an overcast layer separate from any cloud work - I think things might look better - as I had to combine them in the last file (no alpha).

Yep - just playing around - I'm not very happy with anything I've produced for this method.

Regards,
Scott

[ATSF3751]

Thank you guys for working on this! We need more eye candy for the sim and updated graphics so its nice to see others working on something in that aspect. I would also like to help out with graphics and coding just need to get up to speed with everything first!

Brandon

[Genma Saotome]

scottb613, on 07 January 2023 - 04:43 AM, said:

Hi Dave,

Since the goal is a living changing dynamic sky - I can't think of any way to use the Terragen software with the skydomes I've already made - as when you look at the domes I produced - the projection scales the clouds as they go off into the distance on the horizon - which would negate any use in a moving cloud system. I would hope that whatever we do with the environment - we don't break the ability to use Terragen skydomes for those who wish to use them.

Perhaps I could try using a normal camera - point it up and snap an image for use in making a seamless texture. I don't know of any way to "green screen" the sky so I could isolate the clouds. The sun is also "hidden" at the zenith of the dome which would complicate that procedure as well. I'm not saying that it's not possible - just that I have no idea as to how to do it.

I've come to terms that whatever I do - it is not going to look as good as what I can make with Terragen.

Regards,
Scott

Got it.

Doing clouds "right" would actually involve 3d shapes in order to show them at the correct angle for every direction and distance. I rather doubt anyone wants to take that on. But the alternatives -- what we have to what we will eventually get -- all have problems too; there are very different clouds at altitude and location -- what you see in Iowa is not what you see in California, etc. etc., ... it is a hard problem to solve well.

[scottb613]

Hi Folks,





Would 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 Clouds
https://youtu.be/iqR5BDUa5rg

This 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

[James Ross]

Currently working on: reading sun rise/set time from MSTS environment file

PerryPlatypus, on 06 January 2023 - 03:34 PM, said:

Related to time zone, it would be really nice if we could input into the TRK file the time zone (using UTC format). And in the event that that line is not in the TRK file, then OR would do its own calculation that you propose to determine time zone (would that be based on Start Tile for simplicity's sake, or some geographic average of the extreme lat/lons for the route?)

Agreed, putting the time zone into the route data would mean we don't need the sun rise/set times and can instead calculate them - which also means they can vary based on where you are in the route (primarily long east/west routes I guess)

scottb613, on 06 January 2023 - 04:45 PM, said:

I think we need the weather system to have control of the shadow system to be able to deactivate it when overcast. Shadows look silly on overcast days.

I think the weather system should also have access to the brightness slider to represent various conditions. The image above is 100.

The shadows do disappear in more overcast scenarios, but this relationship likely needs to be evaluated along with all the other colour and brightness interactions

railguy, on 06 January 2023 - 05:14 PM, said:

Time Zone is not the only parameter necessary to achieve proper sunrise/sunset times, though. Latitude also must be in the calculation. For example (using the U.S.), both south-central Texas and central North Dakota are in the Central Time Zone, but sunrise/sunset times will be markedly different for each on the same day because of the difference in latitude, even though they are at similar longitude. Days are longer in the summer and shorter in the winter as one goes away from the equator at the same longitude.

We always have latitude and longitude because that's encoded into the terrain/world tile system, so with the addition of time zone I believe we have enough to calculate correct sun position for a given season

PerryPlatypus, on 06 January 2023 - 05:19 PM, said:

In the absence of the info in the TRK file, then ORTS can just have local/solar noon occurs at 12:00 p.m. on the clock.

I am going to try using the environment files as fallback, since the information is already there for sun rise/set, and it'll match MSTS

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

Would 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.

This sounds interesting and multiple textured cloud domes certainly seems like the next logical progression for sophistication of the sky

This sort of change will necessarily come after some of the more basic issues are addressed, but I would be encouraged to see people experimenting with new cloud textures (as has already happened!) that would be compatible with this

If you want a primitive test, you can put higher clouds onto SkyDome1 and lower clouds onto Clouds01 and see if it works (obviously limited by sky not moving, etc.)

[Genma Saotome]

Last night I played around with the brightness setting, several trials ranging from 90% to 140%. One thing I noticed was how easily I could be sucked into approving the setting that most looked like photos -- highly saturated. NOPE, down that way lies falsehoods. But it did show me something interesting and that was the shadows were all lighter as well.

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

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. 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.

[PerryPlatypus]

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

Last night I played around with the brightness setting, several trials ranging from 90% to 140%. One thing I noticed was how easily I could be sucked into approving the setting that most looked like photos -- highly saturated. NOPE, down that way lies falsehoods. But it did show me something interesting and that was the shadows were all lighter as well.

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

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. 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.

I think you hit the nail on the head, Dave. I can't say for sure that the daylight brightness throughout the day is spot on, but it may be pretty close. At early morning and late evening hours (within 2 hours after sunrise and before sunset) the lighting *looks* way too dark right now, but I suspect it's *mostly* because there is so little contrast between the light and shadows. Shadows in early morning/late evening light should be very dark since there is much less indirect sunlight from the sky above.

Once that is corrected, and color-shifting is also corrected for low sun angles and for varying degrees of cloudiness, then we will be well on the way to success. (It would probably be good to incorporate having the hue/tint of the cloud layer also affect the visible light spectrum, i.e. a brown/yellow tinted layer of smoke or smog would cause an overall color shift in all objects. Not sure if it's better to have that happen on a texture-by-texture basis for different cloud textures, or instead create some preset RGB values for different weather conditions, in which case we would need to have a "Wildfire smoke" preset, a "City smog" preset, etc.)

[scottb613]

Hi Folks,

Three domes should be more than sufficient vs four - you would never have Cirrus clouds on an overcast day - we can just use the Top Cloud Layer for overcast days eliminating the Overcast Layer.

Yep - will do further testing.

On a side note - thanks everyone for your input - I remember it was kind of frustrating when working with Mauricio on the Train Driver HUD - how few people cared to voice an opinion on how things should work.
;)

Regards,
Scott