Elvas Tower: Proposal for variable weather definition using weather file - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Proposal for variable weather definition using weather file

#1 User is offline   roeter 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,996
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 07 March 2017 - 03:00 AM

The blueprint linked below defined the proposal to set variable weather patterns during the day when running in timetable mode :
Weather File

Some additional notes :
  • Why restricted to timetable mode?
    This is not a technical issue but for practical reasons. In activity mode it is already possible to influence the weather using certain waiting point definitions. It would be at least confusing to have two separate sources of weather definitions.
    I will leave it up to the developers which maintain activity mode what they want to do regarding this new feature. Technically, it would require only a very minor program change to allow the use of weather files in activity mode.

  • Weather file and Kosmos environment
    I do not have any experience with the Kosmos environment, as I have never used it. But if it would be usefull to add parameters to the weather file, for instance to select specific Kosmos environments linked with specific weather, I'm open to any proposal in that direction.

  • Wind
    Wind definitions are not included in the present set of definitions. I have been looking at the code which generates 'wind', and this is set up in such a way that it was difficult to make it controlable through an external file.
    Also, I do not think precipitation generation is taking wind into account in a proper way. In high winds, precipitation should not fall vertically, but should have a strong horizontal movement as well. That horizontal movement is missing. Getting that right would require complete rewrite of the precipitation code, and that was well beyond the intentions of this proposal.


Regards,
Rob Roeterdink

#2 User is offline   Csantucci 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 4,934
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 07 March 2017 - 05:34 AM

Rob,
only a small correction: in activity mode weather change is driven by activity events and not waiting points.

#3 User is offline   roeter 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,996
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 08 March 2017 - 04:02 AM

View PostCsantucci, on 07 March 2017 - 05:34 AM, said:

Rob,
only a small correction: in activity mode weather change is driven by activity events and not waiting points.


I stand corrected.

#4 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,182
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 19 March 2017 - 08:00 AM

View Postroeter, on 07 March 2017 - 03:00 AM, said:

The blueprint linked below defined the proposal to set variable weather patterns during the day when running in timetable mode :
Weather File

I disapprove of the use of STF/SIMIS format for brand new data files, particularly as JSON has seemingly been agreed since late 2011 (!).

Otherwise, the structure and data in the file feels okay, but I think it might benefit from having fog be a different element type (e.g. FogSetting) to clearly distinguish it from WeatherSetting with clear/rain/snow, since the two groups run independently, if I understood correctly.

One small note: if the code doesn't already do this, I'd recommend sorting the blocks by time, so the order in the file doesn't matter.

View Postroeter, on 07 March 2017 - 03:00 AM, said:

Why restricted to timetable mode?
This is not a technical issue but for practical reasons. In activity mode it is already possible to influence the weather using certain waiting point definitions. It would be at least confusing to have two separate sources of weather definitions.
I will leave it up to the developers which maintain activity mode what they want to do regarding this new feature. Technically, it would require only a very minor program change to allow the use of weather files in activity mode.

I'd recommend we add a new ORTSWeatherFile option to activity files. I was expecting something similar to be added to timetable files, but I don't see any mention of it. Is this currently just a user-selectable option in the menu?

View Postroeter, on 07 March 2017 - 03:00 AM, said:

Weather file and Kosmos environment
I do not have any experience with the Kosmos environment, as I have never used it. But if it would be usefull to add parameters to the weather file, for instance to select specific Kosmos environments linked with specific weather, I'm open to any proposal in that direction.

Kosmos was just a specific means of setting up the MSTS environment file, but those do cover more things than this weather file (they cover water as well as sky) but they do it in a very precise way (exact list of textures for water and sky, movement, etc.). When we finally add non-MSTS water, we should make sure it responds to the weather settings and that's probably it.

View Postroeter, on 07 March 2017 - 03:00 AM, said:

Wind
Wind definitions are not included in the present set of definitions. I have been looking at the code which generates 'wind', and this is set up in such a way that it was difficult to make it controlable through an external file.
Also, I do not think precipitation generation is taking wind into account in a proper way. In high winds, precipitation should not fall vertically, but should have a strong horizontal movement as well. That horizontal movement is missing. Getting that right would require complete rewrite of the precipitation code, and that was well beyond the intentions of this proposal.

Hmm, the particles themselves should and appear in the code to be given wind direction, but the setting up of the "Wind" field looks to be sub-optimal and simply based on the precipitation level.

#5 User is offline   roeter 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,996
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 20 March 2017 - 02:37 PM

View PostJames Ross, on 19 March 2017 - 08:00 AM, said:

I disapprove of the use of STF/SIMIS format for brand new data files, particularly as JSON has seemingly been agreed since late 2011 (!).

The problem with JSON is that no 'support' is provided yet within the program structure (e.g. method library for error handling etc.), all of which is readily available for STF.
Also I do not have any knowledge of or experience with JSON myself - I've never used it in either my professional or personal work.
Admittedly, when I created this function I had no intention of ever committing it - it was just intended as a 'personal' addition, just a bit of eye candy for fun. So it did it 'quick and dirty' using STF. But as I was now working on a more public update for signals and timetables I thought I might as well include it as others may perhaps also like it. But I do not have the time at the moment to sort out what it should look like in JSON, so if that is required, I will have to drop it.
I would like to suggest a compromise : I will include the processing of the information (i.e. the processing of the class as such), but not the reading of the file. Later on I may find the time to work out what it should look like in JSON, or perhaps someone else with that knowledge can pick up that part.

Quote

Otherwise, the structure and data in the file feels okay, but I think it might benefit from having fog be a different element type (e.g. FogSetting) to clearly distinguish it from WeatherSetting with clear/rain/snow, since the two groups run independently, if I understood correctly.

It was not intended to define fog and precipitation at the same time, but I must admit I do not know what will happen if you define rain or snow before defining that the fog should lift. I will have to look into that.

Quote

One small note: if the code doesn't already do this, I'd recommend sorting the blocks by time, so the order in the file doesn't matter.

Good suggestion, haven't done it yet (as I said, it was all very basic).

Quote

I'd recommend we add a new ORTSWeatherFile option to activity files. I was expecting something similar to be added to timetable files, but I don't see any mention of it. Is this currently just a user-selectable option in the menu?

The idea was that it would be possible to run the same timetable in different weather conditions, so it is indeed just an entry in the menu and no part of any timetable as such. If no file is selected, the present basic weather is used.
By the way, having an additional option in the activity still leaves the problem of two separate mechanisms to influence the weather (the activity events and the weather file), something will have to be decided on how that should be handled.

Quote

Kosmos was just a specific means of setting up the MSTS environment file, but those do cover more things than this weather file (they cover water as well as sky) but they do it in a very precise way (exact list of textures for water and sky, movement, etc.). When we finally add non-MSTS water, we should make sure it responds to the weather settings and that's probably it.

OK - clear.

Quote

Hmm, the particles themselves should and appear in the code to be given wind direction, but the setting up of the "Wind" field looks to be sub-optimal and simply based on the precipitation level.

Wind was the one item which was both difficult to define and to set up - it is much more variable than the other elements. For instance, in showery weather, those showers often bring strong gusts of winds (the famous 'squally showers'), which may actually come from different directions as the prevailing wind as such.
I did a number of experiments but whatever the wind definition was, it seemed to make little difference to the way the precipitation particles were behaving. So, it was difficult to define and difficult to set up and did not have any noticeable effect - and so I just dropped it.

Regards,
Rob Roeterdink

#6 User is offline   Jovet 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 2,136
  • Joined: 14-January 08
  • Gender:Male
  • Location:Omaha, Nebraska.
  • Simulator:MSTS/Open Rails
  • Country:

Posted 21 March 2017 - 03:23 AM

This may be an example of something where "request for comments" and brainstorming of ideas would be fruitful before sitting down to write final code and implementation begins.

#7 User is offline   cjakeman 

  • Superintendant
  • PipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 1,877
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 21 March 2017 - 02:12 PM

View Postroeter, on 20 March 2017 - 02:37 PM, said:

The problem with JSON is that no 'support' is provided yet within the program structure (e.g. method library for error handling etc.), all of which is readily available for STF.

I'll be using JSON for the new camera and camera set files so that should flush out any missing functionality.

#8 User is offline   edwardk 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,326
  • Joined: 11-December 09
  • Gender:Male
  • Location:Chula Vista, CA
  • Simulator:MSTS
  • Country:

Posted 21 March 2017 - 05:39 PM

As it is now, the snow particles fall the same way. Even with wind, random or not random, it looks odd with the snow particles falling the same way. The physics would have to be changed so that each particle has its own random method of changing direction as it falls.

Edward K.

#9 User is offline   septf 

  • Apprentice
  • Group: Status: Dispatcher
  • Posts: 44
  • Joined: 28-July 14
  • Gender:Male
  • Simulator:MSTS OpenRails
  • Country:

Posted 14 October 2017 - 09:37 AM

It is possible to use this file. If yes how?

Regards
Jean-Marc

#10 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Owner
  • Posts: 13,571
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 14 October 2017 - 10:59 AM

In the blueprint there is one concept missing and that is the distance from the camera where the fog reaches a certain level (either opaque, some percentage of opaque, or starts, it doesn't matter). as well as something that moves that location closer or further away from the camera in some rate of change.

IMO the current fog when (it is raining) is fully opaque far too close to the camera and AFAIK it is always at that distance. I've complained about that for a very long time. Real fog density is not identical, it always changes over time and so since the fog we have seems to be a mechanism to convey that the falling rain obscures vision rather than just fog as fog the opacity needs to change hand in hand with the rate of rainfall as does the distance where it becomes opaque.

If it would be possible to take one more step along this path of thought, please consider that ground fog can occur many hours after a rainfall (when the dew point changes) and so it would be very nice if ground fog could be a weather feature that's pretty much identical to what is being proposed for rain and snow.

IOW one type of fog represents the obscuring nature of falling rain or snow (based on the rate of fall) and a different type is fog itself, rising from damp ground which often occurs w/o current precipitation.

Last thought, really a question: What is the current situation in the code to to provide for rain tertex? To allow falling snow w/o snow tertex?

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users