[steved]

Well... It looks the same.

https://i.imgur.com/hcghHPu.png

Might have to take a look at Clouds01.png.

The route is your beloved L&HR 1940s. I just picked it up and moved it west about 1000 miles.
It's in the general area where Kansas, Nebraska, Iowa and Missouri all come together. It's fictional. I call it the Rock Island Lines.

[scottb613]

steved, on 24 March 2021 - 07:12 AM, said:

Well... It looks the same.

Might have to take a look at Clouds01.png.

The route is your beloved L&HR 1940s. I just picked it up and moved it west about 1000 miles.
It's in the general area where Kansas, Nebraska, Iowa and Missouri all come together. It's fictional. I call it the Rock Island Lines.

Hi Randy,

Hmm - odd - perhaps I posted the wrong one - let me look as well. It's nothing more than a blanked out Alpha to remove the "Clouds01.png" completely.

Regards,
Scott

[steved]

Cool. Thanks.

[Icik]

scottb613, on 24 March 2021 - 07:01 AM, said:

Hi Jirca,

I'm a fan of your work - I've seen your shader video.

Yeah - moving clouds would be great but the system in ORTS we have to work with doesn't do a very good job of depicting realistic clouds - IMHO - at least from what I've seen. To me the painted Skydomes look more realistic. In real life you have to look long and hard at clouds - on most days - to detect any real movement.

Can you post a picture of the ORTS cloud system you think looks realistic ? Perhaps you know something I don't. It's certainly worth considering/discussing all options.
;)

Regards,
Scott

Thanks Scott, I'm glad you like. In the pictures, you see clouds that move lazily across the hills. I perceive the movement even if I stand just a few minutes in the station. Especially if the wind is strong.

[steved]

Here it is with a transparent clouds01.
https://i.imgur.com/czR7xJ9.jpg
Looks like a nice warm spring day.
I don't see any reason to stop what you're doing.

[scottb613]

Icik, on 24 March 2021 - 07:43 AM, said:

Thanks Scott, I'm glad you like. In the pictures, you see clouds that move lazily across the hills. I perceive the movement even if I stand just a few minutes in the station. Especially if the wind is strong.

Hi Jirka,

That looks quite good - maybe I'll have to play around with that a bit more.
:)

steved, on 24 March 2021 - 08:24 AM, said:

Here it is with a transparent clouds01.

Looks like a nice warm spring day.
I don't see any reason to stop what you're doing.

Hi Randy,

Cool - I think your haze might make it look better - just wanted to relay the option.

Yeah - perhaps because I know it could look much better but I find the distortion very distracting - my eyes are constantly drawn to it.

Thanks for the feedback - we'll see how it goes.

Regards,
Scott

[Icik]

Scott, these Skyboxes look great. Just why not use wind simulation options and don't move with sky? If beautiful high resolution clouds were managed so it would be great.

[FS.E652 091]

I have read this topic very carefully, I must say that personally I have a lot of sky domes reproduced ... the concept, however, is always the same ... the simulator as a base, would need a revision on the whole atmospheric system and the management of the skies. .

I had proposed, (unfortunately I have no capacity ...) to be able to develop the simulator from this point of view by adopting the skies system adopted by Eurotruck Simulator 2, with automatically interchangeable skies for the complete transitions dawn \ day \ evening \ night ..
it would be interesting to understand the intentions of those who want to graphically develop this simulator since, however, having a new graphics engine such as monogame, this would in theory be possible .. just as it would be possible to modify the atmospheric and water rendering ..

I think it is fundamental from this point of view, given that, you cannot combine it with a secondary program such as reshade that adds effects to the simulator, slowing it down or making it crash .. !!

I am attaching a screen shot of one of my many scenarios under construction just to show the potential of all this .. especially when you have a detailed route under construction ..!

Attached thumbnail(s)

• 

[Genma Saotome]

MSTSSky.cs and Sky.cs are the two blocks of code used to make the skydome, including a dome for clouds, the sun, and the moon. Perhaps the first one is no longer used, I dunno. Much of what is there is beyond my comprehension (no surprise to me) but what I think I understand is this:

The radius of the skydome is 24 segments to cover a radius of 6000m. I assume this refers to a whole sphere, which, if correct, means 12 segments from pole to equator and 24 segments for each horizontal circle. There is some code for another 6 segments below the horizon to ensure there isn't a visible gap.

IMO 24 segments is far too small for so large a sphere (the angle at any joint will be 15d) and this is probably the entire reason for the complaint of the skydome being rather chunky. 360 segments comes to mind first but going that far could introduce performance issues but it certainly would be worth a try to see what happens.

The code dynamically builds the entire mesh for the dome... there are numerous comments all with reference to the number 24.

Someone could simply change (on one line) the value of 24 to something else, compile the code and see what happens. I must add that it appears any change that is not a multiple of 24 may result in very surprising and unwanted results to the mesh.


Elsewhere is a very straightforward bit of code that assembles the string that makes the path to the \content directory within the OR installation and from there reads several .png files needed to present a complete skydome. A note says this should be moved to the loader and, yeah, it probably should be. Given how basic the command is I will hazard a guess that it would be pretty trivial to edit this to first look at a to-be-identified directory within the route files for the same type of files and if not found continuing on and executing the extant code as a default.

The code can be downloaded from the OR site if you want to look at it yourself. In the downloaded archive you'll find it in "\Source\RunActivity\Viewer3D\Sky.cs"

[scottb613]

Weter, on 31 March 2021 - 02:22 PM, said:

Excuse me, did I understood right:
-the attached clouds.png file is just an alfa to substitute original Openrails clouds;
-the attached images can de saved on PC and then used as a new skkydome variants with different amount of clouds?

Hi...

I only uploaded one 10,000x10,000 pixel image intended for actual use in one of the previous posts here.

All the others I've posted are just very low resolution jpg examples not intended for use.

Here's the link again to the previous file I uploaded:
https://mega.nz/file...EDFen4UMldnSARs

Like this one - it took me over 16 hours to render the full size image. The more clouds - the more time to Ray Trace. Unfortunately - the ORTS introduced distortion makes it look bad in the sim - so currently this is a waste of time and money. It's a shame because this seems to have great potential for improving our visuals and adding some variety - without having to completely replace our existing environment model. The larger the clouds are by the horizon - the more noticeable the distortion becomes.

Genma Saotome, on 31 March 2021 - 08:38 PM, said:

MSTSSky.cs and Sky.cs are the two blocks of code used to make the skydome, including a dome for clouds, the sun, and the moon. Perhaps the first one is no longer used, I dunno. Much of what is there is beyond my comprehension (no surprise to me) but what I think I understand is this:

The radius of the skydome is 24 segments to cover a radius of 6000m. I assume this refers to a whole sphere, which, if correct, means 12 segments from pole to equator and 24 segments for each horizontal circle. There is some code for another 6 segments below the horizon to ensure there isn't a visible gap.

IMO 24 segments is far too small for so large a sphere (the angle at any joint will be 15d) and this is probably the entire reason for the complaint of the skydome being rather chunky. 360 segments comes to mind first but going that far could introduce performance issues but it certainly would be worth a try to see what happens.

The code dynamically builds the entire mesh for the dome... there are numerous comments all with reference to the number 24.

Someone could simply change (on one line) the value of 24 to something else, compile the code and see what happens. I must add that it appears any change that is not a multiple of 24 may result in very surprising and unwanted results to the mesh.


Elsewhere is a very straightforward bit of code that assembles the string that makes the path to the \content directory within the OR installation and from there reads several .png files needed to present a complete skydome. A note says this should be moved to the loader and, yeah, it probably should be. Given how basic the command is I will hazard a guess that it would be pretty trivial to edit this to first look at a to-be-identified directory within the route files for the same type of files and if not found continuing on and executing the extant code as a default.

The code can be downloaded from the OR site if you want to look at it yourself. In the downloaded archive you'll find it in "\Source\RunActivity\Viewer3D\Sky.cs"

Hi Dave,

Thanks for the interest.

Hmm - this is by far the most information I've ever seen on the topic. I'll definitely take a look but that's probably all I'm capable of doing.

Regards,
Scott