[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: 194

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

[edwardk]

James Ross, on 06 June 2015 - 06:53 AM, said:

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.

James,

Now that Carlos has submitted his project, I have been able to get back to fine tuning certain values. You are correct in that the values I have been testing with have been quite high. Keep in mind that I have been testing with them. What do you think the effective value should be for MaxIntensity? 16bit value will always be 0.015f. For 32bit, I brought it down to 0.030f. The default values that Carlos is using for pricipitationIntensityPPSPM2 is 0.010f.

I just recently found out from Carlos that since his system is unable to take advantage of LAA, the 32bit value was definitely too high. Testing at 0.030f with no LAA has resulted in no errors. At this point, there is nothing else that I can do on my end. If you wanted to improve the look of precipitation without touching MaxIntensity, graphics would probably be the way to do it, but like Carlos, graphics is not my area.

Personal observations:

I have been testing snow at 0.0075f and it still looks quite good. Rain on the other hand needs work and this is still using the additional drops that were included.

Using snow as the example. It appears that the falling precipitation is better when further away from the train. Around the train it appears rather thin.

Edward K.

[James Ross]

edwardk, on 15 June 2015 - 01:18 AM, said:

What do you think the effective value should be for MaxIntensity?

Basically as high as we can go without using more than a few (1-5) percent of the 2GB in non-LAA situations, would be my guess. I have not worked out how much the current 16bit buffers use up though. Do you have any ideas on how much the old or new values might be consuming?

[edwardk]

James Ross, on 15 June 2015 - 12:39 PM, said:

Basically as high as we can go without using more than a few (1-5) percent of the 2GB in non-LAA situations, would be my guess. I have not worked out how much the current 16bit buffers use up though. Do you have any ideas on how much the old or new values might be consuming?

Considering the fact that there are many different systems running OR, hard coding settings that will work on all systems is tedious. How would you feel about adding two settings to the experimental options screen? This would be for MaxIntensity and pricipitationIntensityPPSPM2.

Edward K.

[James Ross]

edwardk, on 17 June 2015 - 01:07 PM, said:

Considering the fact that there are many different systems running OR, hard coding settings that will work on all systems is tedious. How would you feel about adding two settings to the experimental options screen? This would be for MaxIntensity and pricipitationIntensityPPSPM2.

I don't consider that a solution, just a cheat. The 2GB VA is fixed across all systems (though many will be 4GB) so work within that, please. You don't need to measure anything that is specific to your system - virtual memory usage is not like that.

If you want to attach the current changes as a patch, I can figure out the VA usage myself and see where we are.

[edwardk]

James Ross, on 17 June 2015 - 01:26 PM, said:

I don't consider that a solution, just a cheat. The 2GB VA is fixed across all systems (though many will be 4GB) so work within that, please. You don't need to measure anything that is specific to your system - virtual memory usage is not like that.

If you want to attach the current changes as a patch, I can figure out the VA usage myself and see where we are.

James,

Here is the patch along with the runactivity.exe which is based on V3163.

Once you actually study how the 2 variables are used, you will possibly understand why I came up with the previous idea. The situation is we want close to realistic weather, but as we get closer to what may be realistic, we must realize that resources will be needed. Both MaxIntensityPPSPM2 and pricipitationIntensityPPSPM2 play a big part in this area. This is assuming the current precipitation process is efficient. I lowered the default snow value for pricipitationIntensityPPSPM2 to 0.0015f and it still looks good. Who knows, maybe the issue is not with values being used, but how the particles are being created and utilized.




Edward K.

Attached File(s)

•  OR3163.zip (639.18K)
  Number of downloads: 193