Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TFO cars dislocated on converging track #1099

Open
alex-wenzel opened this issue Dec 4, 2024 · 2 comments
Open

TFO cars dislocated on converging track #1099

alex-wenzel opened this issue Dec 4, 2024 · 2 comments

Comments

@alex-wenzel
Copy link

alex-wenzel commented Dec 4, 2024

Route File

Route.Comment Perpendicular merging TFO test,
Route.Gauge 1435,
Route.Change 1,

Route.TfoXML _test_perp_rail_tfo.xml,

Options.BlockLength 10,

With Structure,
.Rail(1) sdbve\track\str_ground_blue-ballast_10m.csv,

.Ground(1) sdbve\ground\desert_ground.csv,

Texture.Background(0) sdbve\sny_sky_2.png,
Texture.Background(0).X 1

Train.Folder sdbve\22000_IE\22000 3car

With Track,
0,
	.ground 1,
	.back 0,
	.railtype 0;	1,
	.height 0.18
	.sta "Station 1";10.0000;10.0015;0;0;0;	0;;15;100;;,
	.stop,
50, .railstart 1;	101.00;	0.00;	1,
60,.rail 1;	86.82;	0.00;	1,
70,.rail 1;	55.16;	0.00;	1,
80,.rail 1;	39.35;	0.00;	1,
90,.rail 1;	28.19;	0.00;	1,
100,.rail 1;	19.75;	0.00;	1,
110,.rail 1;	13.24;	0.00;	1,
120,.rail 1;	8.26;	0.00;	1,
130,.rail 1;	4.56;	0.00;	1,
140,.rail 1;	2.00;	0.00;	1,
150,.rail 1;	0.50;	0.00;	1,
160,.rail 1;	0.00;	0.00;	1,
250,.sta "Station 2";10.0400;10.0415;0;0;0;0;;15;100;;,.stop,

TFO

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TrackFollowingObject>
    <Definition>
      <AppearanceTime>10.0000</AppearanceTime>
      <AppearanceStartPosition>-10</AppearanceStartPosition>
      <AppearanceEndPosition>300</AppearanceEndPosition>
      <LeaveTime>10.0500</LeaveTime>
    </Definition>
    <Train>
      <Directory>..\..\..\..\Train\sdbve\22000_IE\22000 3car</Directory>
    </Train>
    <Stops>
      <Stop>
        <Decelerate>0</Decelerate>
        <StopTime>00.0000</StopTime>
        <StopPosition>120</StopPosition>
        <Accelerate>1.71</Accelerate>
        <TargetSpeed>15</TargetSpeed>
        <Direction>1</Direction>
        <Rail>1</Rail>
      </Stop>
      <Stop>
        <Decelerate>1.71</Decelerate>
        <StopPosition>500</StopPosition>
        <StopTime>00.0030</StopTime>
        <Accelerate>0</Accelerate>
        <TargetSpeed>0</TargetSpeed>
        <Direction>1</Direction>
        <Rail>1</Rail>
      </Stop>
    </Stops>
  </TrackFollowingObject>
</openBVE>

Behavior (video)

tfo_comp.mov

I went through some of the old threads about TFO development and I saw a few similar issues, but I think this might be a slightly different one. This is one of the issues where I'm not sure where "bug report" ends and "feature request" begins, but is it possible to improve the interpolation of the individual car locations within the existing TFO framework, or is this similar to the offset from rail0 effect we're used to seeing, like with my Structure.Rail objects in this video?

Edit: I think I'm using 1.11.0.6

@leezer3
Copy link
Owner

leezer3 commented Dec 4, 2024

It's somewhere in between a bug and a feature.

Basically, this is a fundamental issue with the concept of zero-based (as opposed to absolute wpos) routefile notation.

TLDR:
Each element must have a zero-based absolute starting position assigned to it.
These have to be contingous with that of Rail0 due to the routefile format.
However, as you've just demonstrated, a curve not aligned with Rail0 is actually longer than Rail0 itself.
Interpolation simply can't cope well with this differential. It moves to the 'end' of the track piece, and then glitches slightly onto the next.

There's not really any way around this without dropping the zero-based routefile notation. I suppose it might be possible to write some sort of internal conversion between the internal 'real' distance and the routefile distance, but to do that you're essentially dumping the whole parser, and at that point you might as well just drop the whole zero-based concept.

Essentially, you've just found one of the reasons nearly everything uses a tile based format :)

@alex-wenzel
Copy link
Author

Thanks for the explanation! The 0-based system makes sense and it seems like this wouldn't have been much of an issue (since rail objects can be bent and extended to hide the gaps) until the "invention" of TFOs more recently, so I don't think it's a surprising or "bad" design decision on anyone's part.

I'm curious if a solution downstream of the actual route parsing and closer to where the actual rendering is being done would be possible. I could imagine some function that takes the 0-based coordinates for what they are and tries to draw a more continuous path for the TFO's movement when actually rendered. In my example, I obviously never use .turn or .curve since I'm "curving" the non-player rail, but there does seem to be a function somewhere that is smoothing the TFO's car's rotations in the x-z plane to almost give the impression that a smooth curve exists, except for where the block jumps happen. I suppose the concern would be that implementing such a solution means the TFO is not really following the track anymore, and that might create more problems than it solves in unexpected ways.

Let me know if I'm making sense or not. I may go spend some time looking through the code myself later, but I'm curious how easy or difficult you think this might be in a broad sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants