Replacement A-Tracks Disappear with Fog

[wmuzeke]

It seems like fog causes the replacement A-tracks and ballast to disappear. This example is on the ATSF La Junta-Pueblo Sub. When I restore the old shape files from 2001 in the Global folder it looks normal. You can test it quickly with Shift and - (decrease) or = (increase). I'm using default-track-atrack-28may24.zip (File ID 88570).

Open Rails 2024-10-14 09-41-53.jpg Open Rails 2024-10-14 09-40-14.jpg

[oper190]

I concur, though never ran with this much Fog. With same degree of Fog and position from ground level, can see road textures fine, yet track texture is completely in "white out". Other 3D objects appear fine.
Open Rails 2024-10-15 02-02-28.jpg
Taken on Pocahontas Route.

[oper190]

Just ran a quick test with different track textures.

Bluefield: can see track

Open Rails 2024-10-15 02-26-52.jpg

Mactier some pieces go to 'whiteout':

Open Rails 2024-10-15 02-25-04.jpg

Could that be dynamic track pieces?

[oper190]

Ran a test in video - from cabview without cab textures -interesting as track pieces seem to appear and disappear then reappear with full fog.
track test.zip

[eric]

Perhaps the fog is creating some Z fighting with the alphas, or maybe LOD confusion. Anyone know how it's implemented?

Sent from my SM-S911U using Tapatalk

[oper190]

Running the new VRE Activities on RFP3

Here's some shots, this seems to appear on runs of straight track only as track fades in and out.

Start of the Part1 Act all is well, seen here after Fredricksburg:
Open Rails 2024-10-22 01-11-41.jpg

Later as more fog set in track began to white out: time 07:56:30
Open Rails 2024-10-22 01-25-59.jpg
Nearly whited out -Time 07:56:44

Open Rails 2024-10-22 01-26-14.jpg
Beginning to return - Time 07:56:50

Open Rails 2024-10-22 01-26-20.jpg
Now back to normal - Time 07:56:55
Open Rails 2024-10-22 01-26-24.jpg

All in a matter of 25 seconds, and continues like this on straight sections, fading in and out.

[oper190]

This shot as a good example.
Open Rails 2024-10-15 02-22-31.jpg
Note the switch the engine is on is in fair detail, the switching piece going to the left is totally whited out, and the other straight piece to the left is less whited out.

[wmuzeke]

Hope the activities are running smoothly for you. Another error that I was getting when testing the 312 activity that may or may not be related to this was "Warning: At least one precipitation index is out of bounds: x = 256, z = 154, Location.X = 1024, Location.Z = 208.66, BlockSize = 8, HeightDimensionX = 256, HeightDimensionZ = 256 ; fixing it" That also seemed to go away when changing back to the 2001 track shapes. I ended up dialing back the precip intensity and the error went away.

[oper190]

Hope the activities are running smoothly for you.

So for other than the track and fog issue, find it is running fine.

I was doing a little testing and went to one of my routes that I use the US Track version. Again in the issue only appears to happen with straight track and is not uniform as pictured:

Notice depth of Whiteout is not unform with all track pieces. Those further away are seen clearer. None of this track is dynamic either. As I panned the camera the amount of whiteout does not change with each track piece, (close or distant).

Open Rails 2024-10-25 02-35-05.jpg

Open Rails 2024-10-25 02-36-19.jpg
Here precipitation and overcast was removed, fog only.

Open Rails 2024-10-25 02-37-41.jpg

[pschlik]

I'm wondering if there's something wrong with the normal vectors given inside the shape files. Funky lighting usually means funky normals.

[eric]

Could be. The shapes themselves are script generated from Doug Jones' trackshape.py for Blender.

[EldoradoRailroad]

Could be. The shapes themselves are script generated from Doug Jones' trackshape.py for Blender.

Does the code from Doug Jones "dump" the created shape in blender BEFORE export to .s? If it does, it is rather simple to see the "normals" to the plane of each polygon. If those "normals" to the polygon plane are missing or errant, they can be re-created to point outwards. This might be also done programmatically in python in blender as an extra step. I am sure that Pete could look into this, when he has some time.

If this is not the source of trouble, then, have you tried different versions of OR to see if the same effect occurs? Very sadly, simple text file editing of the .fx files has been trashed with more recent versions of OR. Any changes you make with .fx files have to be re-compiled before you can see their effects, if any, in runactivity.exe. I have written elsewhere that this is a huge step backwards to the .xnb days with the XNA platform we once used.

The alligators of life are still biting my rear, so there is little time at present to indulge in one of my favorite hobbies. Some other kind soul will have to do this work. A long, hot summer, keeps my sim machines off for many months to save on AC costs.

Steve

[peterman]

Howdy y'all,

This issue with fog is not new and has been around for a couple of years. I believe I first noticed it with the introduction of "weather randomization" in the options of OR. If I were to hazard a guess, I would have a look at the shader used in the X-Track shapes. BlendATexDiff might be a culprit. As I said, just a guess.

Peter

[eric]

BlendATexDiff is definitely used. What's a better alternative to preserve the alpha?

Sent from my SM-S911U using Tapatalk

[peterman]

BlendATexDiff is definitely used. What's a better alternative to preserve the alpha?

Sent from my SM-S911U using Tapatalk

Hi Eric,

I did a quick Google search this morning and the only shader that I could find that might work is one called... "AddATexDiff". I believe that Railworks uses the same shaders as MSTS and Open Rails, as I found it in a link to them. Hopefully OR can support this, otherwise we'll just have to keep using the "Shift + -" to tone down the fog issues.

Peter