What is the current wisdom on splines?

To do city settings, I like to place single buildings of reasonable detail trackside, but then "fill in the gaps" by running some city splines in the distance where you might glimpse them between the trees and buildings that are close to the tracks.

In the past versions splines were touted as being hard on frame rates.

Is this still considered true? The ones I use are pretty blurry (small textures) and simple shapes, but I dont want to find this technique blows my FPS later when I have more scenery in place.

Interesting questions.

I use splines sparingly, track and roads being the exceptions although I have lately started using dirt textures for many dirt roads - most dirt road splines just don't look right. I occasionally use an orchard or vegetable garden spline when needed but TurfFX layers may eventually replace those (there have been some interesting screenshots of new crop TurfFX assets under development).

I have also been influenced by the view that splines are hard on frame rates. I have also heard that splines are rendered by the CPU and not the GPU and further reduce efficiencies.

On the other hand, hardware is now much faster and Trainz itself is now much more efficient at dealing with graphics. T:ANE saw the switch to 64bit instructions and other "under the hood" improvements which gave a noticeable boost to performance over TS12 on the same hardware.

So I don't know if the same "wisdom" on splines is still appropriate. I will be interested in the discussion.

Since TS2009, splines could be made with meaningful LOD schemes to help reduce their effect on frame rates. So restricting your splines to builds of at least 2.9 or 3.0 (?) would be a start. However the operative word was “meaningful”. There are good and bad LOD set-ups and rating their quality is a bit of an art. The best you can do is to look at the spline’s meshes and check things like;

-whether a set of descending levels of detail (polygon count) actually exist.
-what the poly counts are and do they eventually get down to very low numbers per mesh.
-the length of the repeating mesh (or more precisely, the poly count per linear metre of mesh at each LOD).
-the LOD transition distances set in the track-lod-tree part of the config. Shorter lod-distance values are better for frame rates, but they can’t be too short because the transitions are not meant to be very noticeable.
-how many texture materials are used (fewer is better, ideal is 1).
-whether the spline is set not to render at some distance. Look at the last low-detail entry in the track-lod-tree, if it is empty of any mesh tags, that means it it set to be culled.

Another option is to use CM’s preview asset facility. Personally I find it very difficult to interpret or get a straight answer from it.

You might also try setting up a test layout on which you can lay a standard length of spline and check frame rates as you vary the distance from spline to camera. Having the scene statistics visible on screen (interface settings in Surveyor, I think) may help you to see where the lod transitions are actually happening (as opposed to where the config says they should be happening).


.

pware said:

Interesting questions.
I have also heard that splines are rendered by the CPU and not the GPU and further reduce efficiencies.
So I don't know if the same "wisdom" on splines is still appropriate. I will be interested in the discussion.

Click to expand...

Thought the myth that splines were rendered by the CPU had been put to bed a long time ago.
In a nutshell nothing is rendered by the CPU, splines as all other assets textures etc are rendered by the GPU, things like scripts would be CPU and if you monitor the usage while running Trainz TANE upwards it is negligible compared to TS12 when the CPU did all the work.
What applied in obsolete versions of Trainz no longer applies now with a totally different game engine that is GPU based.

The only splines that can cause a performance hit are those large wide grass splines, if used in large quantities, mainly due to the high poly count without lod. Splines for walls fences roads etc IMO now have a much less effect on performance in TANE and TRS19 as they are NOT rendered by the CPU which did nearly all the work up to and including TS12.

Past needs leaving there, it's 2021 and a different Game engine.

For any game or computer an exact copy (clone) is lighter to process than single items
A spline is just that, mesh(es) cloned, so the game just needs to remember a reference/distance where
for the GPU of course everything you see needs to be processed.
Our pc's are so much faster now, don't think there is any problem using splines
wish we had speedtree splines, so i can finally replace the old.
greetings GM

I have never been in a position to run Trainz on anything other than a machine which is marginal for whatever version of Trainz I am using. I have always used a lot of splines on my routes, including grass splines, but I have used them sparingly, rarely more than two or three 'widths' either side of the track, and I rarely mix grass splines, there are seldom more that a handful in total on an entire route, and rarely more than two in the same view...

In short, given all of the above, TS10 stuttered, TRS19 sings......

Andy

Thanks Malc, Dinorius and others for your clarifications.

One of the main problems I have with scenery splines is their short repeating units. This is not an issue with track, road, fence, telegraph line splines were you expect them to repeat but I find it a problem with building and tree splines. Nature does not put a Elm Tree followed by a Birch then a Pine, etc in that sequence repeated endlessly. Likewise buildings along a street never (in my experience) appear as repeating units (terrace houses being an exception). For houses I have found a series of non-spline assets that have a randomised sequence of houses. They can be mixed and matched to avoid "repeats". These are perfect for distance settings with surrounding trees, etc. An example is shown below.



Spline based building and trees also have a "stretch" issue. The distance between the spline points (circles) must be exact otherwise they look squashed/stretched.

My opinions.

pware said:

Thanks Malc, Dinorius and others for your clarifications.

One of the main problems I have with scenery splines is their short repeating units. ....

Click to expand...

These are legit, tho more creative than technical, concerns.

You do have to be careful to find the sweet spot of length, and unless the vertex height is defined, they conform to the terrain, so the ground must be flat.

Where I put them they are somewhat obvious in the overhead god view, but down on the ground they're a distant backdrop, blocking your view between the up close structures. I like them better than flat backdrops tho as they still have paralax and aren't so obvious in that on the ground point of view.