[edwardk]

At this time, I thought it was best to create this post under the discussion area. This should include all areas, sky included.

Under the precipitation issue in the bug area, I indicated that precipitation would start just above the locomotive. I worked on two areas which would represent the foundation. With help from James, the first was taking advantage of 32bit devices. Currently, the precipitation is processing in the 16bit area. This is why you you can see the rain and snow appear just above the train. Under the 16bit process the size of the precipitation box which includes the height can't be improved. I reintroduced the 32bit process along with a test to check which graphics device is being used.

The next step was to take advantage of the 32bit process. I was able to change the size of the precipitation box without impacting the frame rate. I was able to do this by breaking the box size down to length, width, along with height. This allowed me to use a length of 1970 meters which would cover most trains.

With this in mind, I am including RunActivity.exe and RunActivityLAA.exe for the latest experimental release which is X3138. Unless you are running a 16bit device, it is necessary to use the LAA option since more resources are being utilized.

I will include a patch as well.

Edward K.

Attached File(s)

•  Runactivity3138.zip (1.24MB)
  Number of downloads: 150

[James Ross]

If you start with rain or snow it seems to be working well, with what looks like an about 300m high box. Something doesn't seem to be right if you change the weather with Alt-P though, the rain seems to initialise weirdly.

[eric from trainsim]

If you're looking at precipitation, there were two suggestions I'm recalling...

1) change the size of snow to something smaller, or at least make it a variable
2) "accumulate" on terrtex by changing how microtex is applied vs. a snow texture

[edwardk]

 James Ross, on 31 May 2015 - 01:05 AM, said:

If you start with rain or snow it seems to be working well, with what looks like an about 300m high box. Something doesn't seem to be right if you change the weather with Alt-P though, the rain seems to initialise weirdly.

I would not think too much about this since I just found out that Carlos also has plans. My initial plans you can say were accomplished. I am not sure what Carlos has in mind, but he does know what I have been working on. Any additional work on my part could make his plans more complicated. Unofficially, its possible we could be working together on this, but I will not know until he is ready to work on it. This leads to the question of submitting whats been done. With the exception of the rain issue which only happens if you change the weather yourself, everything else appears to be fine. Since I just recently uploaded the files for testing, I will wait to see if there are any serious issues and if you feel that this can be submitted, then it will be submitted.


Edward.

[Csantucci]

Hi Edward,
even if I have in mind to generate an event-driven weather (in short time I have intention to produce a blueprint, if I finally end up discovering bugs...), "old" manual commands like Alt-P will remain and therefore will need to continue working well.

[Genma Saotome]

A long time ago I suggested using an ordinary text file where rows represented time of day and commands on those rows instructed what to do w/ changing precipitation and cloud cover by some user specified percentage (o = none, 100 = maximum) and user specified direction (e.g., more or less). Easy to set up, should be easy to execute.

It would probably be best to have an Activity and/or timetable specify the command file name to use rather than have the user name the command file for an activity. That way one command file could be used w/ multiple activities as desired.


Having set up the code to check whether a command should be executed I suspect you will have in hand the means to deal with other similar instructions based on time of day, like commands for when to enable and disable night textures for those models that use them and possibly even changing terrtex art from dry to rainy or to snow covered.

[edwardk]

At this point, the biggest step for OR would be to have a 64bit version. Under the current 32bit process, I found the limit that the precipitation level can be set at until it refuses to run due to lack of memory and this is with LAA. Working with snow, I set pricipitationIntensityPPSPM2 to 0.70 and OR would not run due to lack of memory. I initially thought snow was bad with resources, but it turns out that rain is worse since the frame rate will drop quite a bit with rain well before the memory limit is reached.

Edward K.

[edwardk]

I would like to show you the results of the max setting with snow which is 0.85. I would not attempt this with rain.

Edward K.

Attached thumbnail(s)

• 

[Genma Saotome]

 edwardk, on 05 June 2015 - 12:27 PM, said:

At this point, the biggest step for OR would be to have a 64bit version.

FWIW when the project was started Wayne made it pretty clear to all involved that little to no concern be given to accommodating obsolete hardware & operating systems. IMO that might have been a bit harsh prior to 1.0... maybe still a bit harsh prior to producing an adequate replacement for AE. BUT it is also, what, 5 years later? Seems to me that those folks for whom circumstances do not allow for more modern hardware have a MSTS replacement in hand. An independent Open Rail simulator can legitimately have it's own requirements suitable for the coming 5+ years. I dunno if 64 bit is necessary for OR vs. just nice to have, but surely moving past .XNA and DirectX 9 should be reasons for taking big steps in what the sim can do and what hardware/OS is required..

[James Ross]

 edwardk, on 05 June 2015 - 12:27 PM, said:

Under the current 32bit process, I found the limit that the precipitation level can be set at until it refuses to run due to lack of memory and this is with LAA. Working with snow, I set pricipitationIntensityPPSPM2 to 0.70 and OR would not run due to lack of memory.

If you're genuinely running out of address space in 32bit with LAA then you're going to need to tone it down a lot before it's acceptable for inclusion, unfortunately. Even if we were 64bit, going much beyond the 32bit with LAA limit means you're likely to be overflowing the GPU VRAM even on good cards which is very bad for performance.

I definitely want lots more particles (or the appearance thereof) though; we currently use particles/second/m^2 values up to 0.01 (and you've gone up to 0.70) but according to my figures heavy rain equates to something in the region of 60: heavy rain is 0.0073m/h and a large raindrop is 4mm diameter, which is 0.0000000335m^3, so we have 0.0073 / 3600 / 0.0000000335 = 60.5 particles/second/m^2.