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

[edwardk]

It looks as if I may be running into a dead end. The purpose of this project was to extend the weather around the train. The first step to doing this was reintroducing the 32bit index with a test to check for 16bit devices. The initial test files uploaded worked, but I stressed using the LAA option which when used, all is well, but I found out that people are using systems that are unable to take advantage of the LAA option. In this case, you would more than likely get the out of system memory error.

Initially, I was able to improve the situation by changing MaxIntensityPPSPM2 to a lower value and this worked. Until I took advantage of SLI's 50% off sale and purchased some train sets. The first set running was SLI's GP9u with their default consist. With clear skies and no precipitation, I started getting out of memory errors(LAA disabled)??? MaxIntensityPPSPM2 was set at 0.025f. Another consist with a different locomotive would work, but not this. I am not blaming the locomotive, but I realized at this point there is a resource issue. Lowering MaxIntensityPPSPM2 to 0.015f would work, but at this point we are defeating the purpose of the project.

The cause could be anything. I do know that the precipitation process must initialize the index no matter what. With clear skies, resources are still being used. There is always the possibility that OR is unable to manage resources properly or with all that is running, the LAA process is mandatory. Any thoughts or ideas??

Edit: I initially used 300 meters for the precipitation box height. Changing it to 250 would work, but there is still the question as to how memory is being used.

Edward K.

[edwardk]

Good news is that I found a way around the roadblock. Finally realized I can test if UseLargeAddressAware has been selected. If it is not selected, than additional variables for precipitation box size and MaxIntensity with smaller values can be used.

Edward K.

[edwardk]

I have a test candidate to be tested. What is different is that I added a test to check if Large Address Aware is checked. The critical part is if it is not checked. I started experiencing out of memory errors so I created another set of variables for the precipitation box size and MaxIntensity. The values used here are much lower, but still above the 16bit values being used. Using the values below, I have not experienced any crashes. If you do experience crashes when not using Large Address Aware, Please let me know. I am uploading both runactivity.exe and runactivityLAA.exe. Both are needed and are based on X3169.

Note: The test is only for the 32bit graphic device.

Here are the new values if Large Address Aware is not checked
// 32bitbit Box Parameters for systems that are unable to take advantage of LAA
const float ParticleBoxLengthM_Limited_32 = 1970;
const float ParticleBoxWidthM_Limited_32 = 1000;
const float ParticleBoxHeightM_Limited_32 = 160;

public const float MaxIntensityPPSPM2_Limited = 0.015f;

Edward K.

Attached File(s)

•  Weather3169.zip (1.24MB)
  Number of downloads: 143

[James Ross]

So I've been running some tests on the 18th June patch.

The current/existing code allocations look like this:

Allocation for 16,124 particles:
      2,579,840 B RAM vertex data
        193,488 B RAM index data (temporary)
      2,579,840 B VRAM DynamicVertexBuffer
        193,488 B VRAM IndexBuffer

That's 2.6MB, or 0.1% of the 32bit virtual address space.

With the patch applied and the larger index buffers in use, the allocations look like this:

Allocation for 1,627,614 particles:
    260,418,240 B RAM vertex data
     39,062,736 B RAM index data (temporary)
    260,418,240 B VRAM DynamicVertexBuffer
     39,062,736 B VRAM IndexBuffer

That's 285MB, or 14% of the 32bit virtual address space, and the same on the graphics card.

It's no wonder you're running out of memory. :)

The information can be shown with the following line (with the patch):

            Trace.TraceInformation(String.Format("Allocation for {0:N0} particles:\n  {1,13:N0} B RAM vertex data\n  {2,13:N0} B RAM index data (temporary)\n  {1,13:N0} B VRAM DynamicVertexBuffer\n  {2,13:N0} B VRAM IndexBuffer", MaxParticles, Marshal.SizeOf(typeof(ParticleVertex)) * MaxParticles * VerticiesPerParticle, (graphicsDevice.GraphicsDeviceCapabilities.MaxVertexIndex > 0xFFFF ? sizeof(uint) : sizeof(ushort)) * MaxParticles * IndiciesPerParticle));

[edwardk]

Thanks for the information James. I believe you just confirmed what I was recently researching. If you try to search for XNA and weather, you will not find much. What I did find is that particle generation takes up resources which you just pointed out. My latest test that I uploaded scaled things down further in both areas so it would be interesting to see how much of a difference there is.

What steps do I have to take to do what you just did?

Edit: Never mind. The answer was right in front of me at the very bottom :)

Edward K.