Trainz Plus Beta 100134 (Mac) and 1000136 (PC)

Tried the same test as in thread #19, which is on a test track of 5 tracks in concentric circles on a 3x3 baseboards. Each track is made up of four splines (procedural track) with five different trains at full throttle. Speeds range from 64 to 147 mph. No topology changes and one population of live oak trees in the upper left (north-east) corner outside the largest circle. Using the chase camera on the highest speed train, the objects (trees) come into view about a quarter of the time for a complete lap. Three trains are running counter-clockwise and the other two clockwise, so there's passing in bot directions. At times, all five trains are in view as well as the objects.

I'm getting a almost steady 60 fps until I pass close to the trees, and then it drops to 40. I'm using Sysinternals Process Explorer (recommended -- www.sysinternals.com) to watch my GPU usage. Simply right click TRS19.exe in Process Explorer and right-click "properties", then "GPU Graph." I get ~38% GPU usage until the trees come into view and the shadows begin to appear, and then it goes up to ~60%, depending how many other trains are in view.

I think this is very good performance, especially since I'm running dual 4K monitors with my Chrome browser, Process Explorer, Corsair Link (for cpu/gpu temp protection), Notepad, FRAPS, and TrainZ. I'm not sure what happened last night, but I was going back-and-forth between Surveyor and Driver.

Been 28 minutes so far and everything is steady. I'll leave it go for a couple hours and check back.

Not doing this plus thing however considered doing a prebuild in trainzutil? which should sort out any caching problem. Just a thought.

jfike said:

With 100136, I didn't see the fps degradation after an hour or so I saw with the previous builds. However, as mentioned, the Speedtrees really impact frame rates. When they come into camera view on my test track, it down from 60 fps to 15-20 fps.

Click to expand...

Hi again,

I've installed latest (published yesterday) Nvidia driver, updated to TRS to 100136 and alas no changes on Predator GTX1070.
Same scene as before - start with 40 fps, after 60 minutes there is only 24 fps. Procedural track switches are not rendered any more.
If I change Video settings in driver there is no impact on fps except for caps distance - cd=6000 = 22 fps, cd=1000 = 29 fps.
With speedtrees it comes to (almost) slide show.
And there is another "feature" which bothers me more and more - AI drivers are unable to push 5 cars with steady speed (yard switching). Speed is set to 5 mph. No problems with pull - steady 5 mph to next trackmark. Same command with push - speed varies widely 3 - 7 mph. AI just reacts hastily which could also be observed with Drive via TM command. Upon reaching TM speed decrease dramatically and instantly for some 5 - 7 mph. Train weight is 3000 tons but reaction is Ferrari like. Not cool.

Kind regards
Darko

Update to my post #21. Hour and a half in, and fps is now varying between 8 and 22%. GPU usage down between 9 and 18% (it actually goes lower when the trees come into view!) So the degrade is still in this version.

I saved off the session when it was running good and just now when it's bad. I think I'll try a fresh reboot and load the "bad" one first, to see if it starts normal or degraded.

Well that's strange... I rebooted my PC and launched TSS19 and loaded my last session (the degraded one -- post #24) and got the "camera mode is incompatible with the world editing tools...." I had to click Ok twice (the session was saved with the chase camera active.) It's now back to running at mostly 60 fps, losing only a couple fps when trees are in view and shadows drawing.

jfike said:

Well that's strange... I rebooted my PC and launched TSS19 and loaded my last session (the degraded one -- post #24) and got the "camera mode is incompatible with the world editing tools...." I had to click Ok twice (the session was saved with the chase camera active.) It's now back to running at mostly 60 fps, losing only a couple fps when trees are in view and shadows drawing.

Click to expand...

The incorrect camera thing is a known issue and is being worked on. This happens when loading a saved session.

Rebooting and stuff is better indicates what is called a memory leak occurring as time goes on. The reboot clears the RAM (DIMMs) and that allows stuff to run fresh again. Watch your session over time and see how long before it takes to degrade. Try loading the same session multiple times as well. That will prove there's a leak somewhere.

Update to my post #23
Same think in Surveyor - started with 25 fps - just idling for 3 hours and now it shows 9 fps.

Kind regards
Darko

Hi Tony,

"The question with speedtrees is not whether they affect performance, but whether it is worse than other versions." Worse than release version.
"<AI drivers are unable to push 5 cars with steady speed (yard switching)." On all TRS version. Maybe a more visible with latest betas at low speeds. Same goes for speed drops over Drive via Trackmark.

I'm testing on backdated (to 1955 PRR) Jointed Rail Coal Country route with upgraded components (trees, track, PBR textures,....). There are no changes on the route for last month. All rolling stock is US. I'll do some test tomorrow with European rolling stock to see if there is any difference.

Kind Regards
Darko

buci said:

Hi Tony,

"The question with speedtrees is not whether they affect performance, but whether it is worse than other versions." Worse than release version.
"<AI drivers are unable to push 5 cars with steady speed (yard switching)." On all TRS version. Maybe a more visible with latest betas at low speeds. Same goes for speed drops over Drive via Trackmark.

I'm testing on backdated (to 1955 PRR) Jointed Rail Coal Country route with upgraded components (trees, track, PBR textures,....). There are no changes on the route for last month. All rolling stock is US. I'll do some test tomorrow with European rolling stock to see if there is any difference.

Kind Regards
Darko

Click to expand...

the release version worked like a dream for me, i could build for hours apon hours and hold 60 fps locked or over 100fps unlocked, everything just worked. i hope we see the same with the newest version when finished. i am actually installing the release version again side by side the beta until things get sorted out. i want to work on my route. as soon as another build is released i will go back and test it.

nugget2225 said:

the release version worked like a dream for me, i could build for hours apon hours and hold 60 fps locked or over 100fps unlocked, everything just worked. i hope we see the same with the newest version when finished. i am actually installing the release version again side by side the beta until things get sorted out. i want to work on my route. as soon as another build is released i will go back and test it.

Click to expand...

I recommend doing this anyway first to ensure nothing gets broken that we want to keep, and second to be able to compare apples to apples. Even if the test-version, aka the beta, works okay, it's still a test version that can and will have problems. What we don't want is problems that break our working copy. With the two separate versions, we can then see if something did it work before, or was this already an issue? With all the subtle differences, changes, and things it's difficult sometimes to remember if something was broken or not beforehand.

What I recommend doing is copy your database from your working version to a test database. When you install your beta-version, point that version to your test database. What this will do is ensure that both copies have the same content, making testing a lot easier too because you can then test the same route in the same place in both versions.

Mesh Libraries and poly validation

The use of mesh libraries has increased significantly as Trainz versions become more complex.
Given that a library can contain a collection of images from different assets that may have no relation to each other in a LOD sense, it is inevitable that a mesh library will run foul of the three poly rules.
This then impacts on many dependant assets.
It is illogical therefore to apply the poly validation to them.

TB 4.6 Procedural-track example:

Mesh Library

kind "mesh"
kuid <kuid2:132952:154968:4>
username "SAM Trk - III/B v11ru mesh lib"
trainz-build 4.6
category-class "HM"
category-region "CZ;DE;PL;SK"
category-era "1910s;1920s;1930s;1940s;1950s;1960s;1970s;1980s;1990s;2000s;2010s"


mesh-table
{
track-lod0
{
mesh "track_lod0.trainzmesh"
auto-create 1
}

track-lod2
{
mesh "track_lod2.trainzmesh"
auto-create 1
}

track-lod3
{
mesh "track_lod3.trainzmesh"
auto-create 1
}

sleepers-lod0
{
mesh "sleepers_lod0.trainzmesh"
auto-create 1
}

sleepers-lod3
{
mesh "sleepers_lod3.trainzmesh"
auto-create 1
}

sleeper_single-lod0
{
mesh "sleeper_single_lod0.trainzmesh"
auto-create 1
}

chairs-left-lod0
{
mesh "chairs_left_lod0.trainzmesh"
auto-create 1
}

chairs-left-lod1
{
mesh "chairs_left_lod1.trainzmesh"
auto-create 1
}

chairs-left-lod2
{
mesh "chairs_left_lod2.trainzmesh"
auto-create 1
}

chairs-right-lod0
{
mesh "chairs_right_lod0.trainzmesh"
auto-create 1
}

chairs-right-lod1
{
mesh "chairs_right_lod1.trainzmesh"
auto-create 1
}

chairs-right-lod2
{
mesh "chairs_right_lod2.trainzmesh"
auto-create 1
}

chair_single_left-lod0
{
mesh "chair_single_left_lod0.trainzmesh"
auto-create 1
}

chair_single_left-lod1
{
mesh "chair_single_left_lod1.trainzmesh"
auto-create 1
}

chair_single_right-lod0
{
mesh "chair_single_right_lod0.trainzmesh"
auto-create 1
}

chair_single_right-lod1
{
mesh "chair_single_right_lod1.trainzmesh"
auto-create 1
}

rail_left-lod0
{
mesh "rail_left_lod0.im" 864 polys
auto-create 1
}

rail_left-lod1
{
mesh "rail_left_lod1.im" 18 polys
auto-create 1
}

rail_left-lod2
{
mesh "rail_left_lod2.im" 10 polys
auto-create 1
}

rail_right-lod0
{
mesh "rail_right_lod0.im" 864 polys
auto-create 1
}

rail_right-lod1
{
mesh "rail_right_lod1.im" 18 polys
auto-create 1
}

rail_right-lod2
{
mesh "rail_right_lod2.im" 10 polys
auto-create 1
}

endcap_prev
{
mesh "endcap_lod0.trainzmesh"
auto-create 1
}

endcap_next
{
mesh "endcap1_lod0.trainzmesh"
auto-create 1
}

endcap_prev_lo
{
mesh "endcap_lod1.trainzmesh"
auto-create 1
}

endcap_next_lo
{
mesh "endcap1_lod1.trainzmesh"
auto-create 1
}

wingrail_left
{
mesh "wingrail_left.im" 296 polys
auto-create 1
}

wingrail_right
{
mesh "wingrail_right.im" 296 polys
auto-create 1
}

checkrail_left
{
mesh "checkrail_left.trainzmesh"
auto-create 1
}

checkrail_right
{
mesh "checkrail_right.trainzmesh"
auto-create 1
}

blade_left
{
mesh "blade_left.im" 328 polys
anim "blade_left.kin"
animation-loop-speed 0.25
auto-create 1
}

blade_right
{
mesh "blade_right.im" 328 polys
anim "blade_right.kin"
animation-loop-speed 0.25
auto-create 1
}

blade_stretcher
{
mesh "stretcher.im" 36 polys
anim "stretcher.kin"
animation-loop-speed 0.25
auto-create 1
}

blade_slidechair_left
{
mesh "slidechair_left.trainzmesh"
auto-create 1
}

blade_slidechair_right
{
mesh "slidechair_right.trainzmesh"
auto-create 1
}
}
mesh-table-lod-transition-distances 0
description "A mesh library for a Polish TRS19 (and above) track; not suitable for earlier version of Trainz family (TRS2004, TRS2006, TC, TS2009, TS2010, TS12, T:ANE)"
author "samplaire, photos by lxd2-352, sna25, jamie78, Pawel_15"
organisation "PTT"
license "PTT Open Content: http://trainz.krb.com.pl/?licencja-ptt-open-content,108"


thumbnails
{
thumbnail
{
image "thumbnail.jpg"
width 240
height 180
}
}


kuid-table
{
}

Validation

- <kuid2:132952:154968:4> VE109: The low-detail meshes total more than 500 polygons. This may have a negative impact on performance: 0: 5810, 1: 5810
- <kuid2:132952:154968:4> VE111: The meshes in LOD level 1 must total at least 20% fewer polygons than the next higher LOD: 0: 5810, 1: 5810

Dependencies

These are the dependants that display Faulty dependencies aka the Mesh Library:

<kuid2:132952:154963:4> SAM Trk - III/B v11ru Rail-Right
<kuid2:132952:154964:5> SAM Trk - III/B v11ru
<kuid2:132952:154965:4> SAM Trk - III/B v11ru Chairs-Right
<kuid2:132952:154966:4> SAM Trk - III/B v11ru Sleepers
<kuid2:132952:154967:4> SAM Trk - III/B v11ru Chairs-Left
<kuid2:132952:154969:4> SAM Trk - III/B v11ru Rail-Left






I don't have the tools to examine the *.trainzmeshes, but look at the IM LOD meshes. No problem there if consider each type separate.

Can someone determine the Trainzmesh polys please.

Author now has 43 faulty mesh libraries affecting 254 MD as of 14 Apr 19

ianwoodmore said:

Given that a library can contain a collection of images from different assets that may have no relation to each other in a LOD sense, it is inevitable that a mesh library will run foul of the three poly rules.

Click to expand...

Turn off auto-create on the meshes, and they won't be counted against the total.

chris

I tried driving a large route I've been building, except I didn't start any trains -- everything still (I guess the environment -- clouds, sun, shadows was active) so basically a still image form the chase camera. Getting 60 fps for a little over an hour, then started degrading down to 24 fps. Ran one train and it went to 14 fps. GPU usage started at 74% but was down to around 38% when the fps started degrading.

Exited driver and then went right back in -- still low fps (~24.) It seems whatever problem caused the desegregation, stays with TRS19 until exiting everything.

jfike - We've fixed up a memory leak (which is most likely what you're seeing). Updates for Mac and PC to confirm that we've fixed the issue will be released today.