Distortion Based on Track Length

[leezer3]

Apologies if this isn't the right thread, I'm new to BVE so I don't know the full history of implementations and how they relate to each other, but I'm having an issue that looks similar to others in this thread with both new and old route files.

Even using curved objects that match a Track.curve angle, I get large gaps between blocks when rail 1 is the outer rail in a curve:

I initially thought this must be a result of my inexperience, so I examined some other routes and noticed that this happens in some of the higher-quality (yet older) NYCT routes. For example, here's route 6 (from BVEStation) at position 6650 where rail 0 is the left-most rail:

Is this a known interpolation issue or is there a best practices way to overcome having secondary rails that have to cover a "longer distance" within the same block depending on their orientation to rail 0's current curve?

Originally posted by @alex-wenzel in https://github.com/leezer3/OpenBVE/issues/1045#issuecomment-2420126673

[leezer3]

@alex-wenzel This is one of the more fundamental issues with the BVE route format. It's common to both the 'classic' CSV / RW route formats and the newer BVE5 TXT format.

Essentially, the entire basis of the world is calculated around Rail 0. The relative world-position of other rails is then calculated from their X / Y position at the specific distance on Rail 0 at which each command is placed. There's currently no compensation for relative rail lengths in either format, and it's up to the author currently to provide an object which hides these gaps.

I'll do some thinking and playing around at some stage in the future and see if I can get something to work; This is the sort of thing that actually could be quite useful in some cases. (Another thing I keep meaning to think about more carefully is procedurally generated track, but something like that might well end up being rather slow to load....)

[leezer3]

FWIW, the 'normal' way to deal with this is to use slightly over-length track objects. You then have one end very slightly higher than the other (0.01m or so), and the overlap hides itself.

Best practice wise, I'm not sure anyone has ever managed that for anything. BVE content has always been rather fragmentary, with plugins only really working on the subset of routes that they've been designed for.

---

Very marginally related:

There are two very approximate standards for track run sounds I'm aware of: BVETSS (Most UK routes): https://railsimroutes.com/bvetss/index.php

HK BVE: http://bve.i-circle.net/guideline-and-standard/track-sound/

This is another area that's on the ridiculously long list of things I really ought to try and properly sort out, but it's very much a case of getting developers to actually use any new standard.....

[alex-wenzel]

Thanks for the explanation, that all makes sense. I was experimenting with creating rail CSV objects and also stumbled on the realization that I could make the rail meshes slightly longer than my block length, but that of course only looks ok in map up to a certain point, and creates potential z-fighting issues on straight track. I initially thought there might be some way to scale objects in the z-axis relative to their offset from rail 0, but I think that would cause some really weird distortions where the repeating parts like the rail ties look oversized.

I suppose having a library of rail objects whose z-axis length depends on the curve radius and rail 0 offset is the best solution in the current framework.