Middle Geometry...Bug?

[3DTrains]

While creating and testing new track models, I noticed something odd - that the Population Frequency value for middle geometry is set along a level path instead of being set along the path of the object. Thus, if you create separate or spike plates for your track, and then draw a line at grade - say 1% - the area where you started laying looks fine, while the end can be off several inches. Not much of a problem for near-level stretches, but I have a number of areas where the grade is in excess of 2.5%, and the resulting offset of the middle geometry on at the end is quite noticeable! The greater the grade, the worse the problem becomes.

I managed to get around some of the problem by using the split tool to break a length of track into shorter sections (every 50m or so), and this seems to reset the middle geometry. A question however, would breaking track into smaller chunks have an effect on frame rates?

[ightenhill]

Not sure that it effects the fps as such but it will proably have a negative effect on the stutter syndrome..

[AndiS]

All the track geometry always sees lengths as level. This greatly simplifies the calculations in the game engine and introduces inaccuracy as you describe it.

To work around that, I would create about 6 versions of your loft, for 0%, 0.5%, 1%, ... Then, the error should be to small to notice (I hope). More precisely, the error will only show for lengths that are not problem to break.

100 m, 0.5%, length deviation is 1.25 mm. With perfect placement of the right version of loft, you would only get half of that (for 1.25% you use the 1% version, for 1.26%, you use the 1.5% version). But assuming that grade changes often and the track layer does not want to fiddle too much with getting the right version.

Maximum length of track pieces is 500m, sure Kuju decided that this is not bad for the frame rate. Deviation for 500m, would be 6.25 mm. You need to have a sharp eye to see that on the rail.

[3DTrains]

I have shadows painted on the ties, while the spike plates are separate objects used for the middle geometry. Even a slight offset of a few inches stands out like a sore thumb.

[AndiS]

If your spike plates are 3D shapes, then the sleepers/ties would not add so many polygons, if you model them in 3D, too. Sure, there is this persistent problem with the switches/turnouts. But there must be a solution to that, too.

E.g., you could make all the ties the starting geometry of a dedicated track type for a #X switch (with X being the usual range of switches). You could even add the rails, too, which would buy you beautiful guiderails and free you from the welded-track bug. You can make the given radius the minimum radius and instruct the user to always use that, and to lay only a prescribed length of this "ribbon". The straight track would be a stretch of invisible track then. Laying track would be more complicated, and the solution presumes straight track.