Transport Tycoon Forums

Zuu wrote:...it might be an interesting and perhaps good idea to introduce a new L-axis[1] that follows the track. Then for the gfx engine the L-coordinate have to be translated to an XYZ-coordinate, but internal movement of trains might have use for a such L-axis. In an application where I have only one-way "tracks" I've implemented this aproach, but I understand it will be a bit more difficult with two-way "tracks".

Could you please explain this concept? I'm not sure I get what you are trying to say. (And specifically how its used)

The L-axis is, I believe, the line that follows the path of tracks, so instead of saving/updating a high-precision XYZ triple, by splitting the velocity into its three components and adding each component to the corresponding coordinate, you only have to save/update a high-precision L, plus (more rarely) a low-precision XY origin, and then when the train needs to be drawn, you compute the XYZ from the XY, the landscape info, and L. Since speed is known, L is very easy to update -- simply multiply the speed by an appropriate constant and add that to L. Assuming that L stays small relative to the size of the visible window, it's pretty fast to discount most vehicles, by simply generating a cube with sides of 2L, centered around the XY origin, and discounting the vehicle if that cube is completely outside the visible region.
A sphere would be more accurate, but also harder, and probably not much benefit.

DaleStan wrote:The L-axis is, I believe, the line that follows the path of tracks, so instead of saving/updating a high-precision XYZ triple, by splitting the velocity into its three components and adding each component to the corresponding coordinate, you only have to save/update a high-precision L, plus (more rarely) a low-precision XY origin, and then when the train needs to be drawn, you compute the XYZ from the XY, the landscape info, and L. Since speed is known, L is very easy to update -- simply multiply the speed by an appropriate constant and add that to L. Assuming that L stays small relative to the size of the visible window, it's pretty fast to discount most vehicles, by simply generating a cube with sides of 2L, centered around the XY origin, and discounting the vehicle if that cube is completely outside the visible region.
A sphere would be more accurate, but also harder, and probably not much benefit.

Ahh, I get you!

Lets say a path was defined by the following function
f(t) = a + b.t + c.t^2
Then what you are saying is that the L value is simply the parametric parameter of the path.

Close, but not quite. L, as I'm interpreting it, is the distance traveled along that line.

Given the parametric equations:
x=t, y=t and x'=2t', y'=2t'
The value of L for (2,2) would be 2*sqrt(2), for both equation sets, while t would be 2 and t' would be 1.

I think L is just the position of a vehicle on a line (from a certain point). This would mean that L can be from 0-100% and you can calculate the XYZ of the vehicle by calculating the XYZ position of the point in the line at L. This would mean that you also need to save the ID of the line where the vehicle is currently on. This way you would only need 2 variables, one for the line ID and another for L and you can calculate distance from that. TRoS can do most of the line calculations for you, so it shouldn't be too hard.

How will collision detection work then? If you have a segment what is the start point? A segment has actually two ends you can start from...

-edit-
I am not sure if it's good have an additonal system L,
and if it is from 0..100% you still need to lookup the lenght of the segment.
And transforming between coordinate systems can always add some conversation failures ...

eis_os wrote:How will collision detection work then? If you have a segment what is the start point? A segment has actually two ends you can start from...

In the following text I assume that each track-part have a double linked list of all trains on it (since we allow trains to go in both dirrections).

Trains can only collide with next train and the previous train. If two trains collide there is at least one train that head into the other in its driving dirrection. So you can for each train check if you are colliding with the next train (in driving dirrection) by comparing their L-coordinates. Asuming that L-coordinates are the traveled distance.

When there is no next train on the current track-part it becomes a bit more difficullt. Especially if there are many coices where to go. But the problem to find the next train at a split is not really related to if the L-axis is used or not.

eis_os wrote:-edit-
I am not sure if it's good have an additonal system L,
and if it is from 0..100% you still need to lookup the lenght of the segment.
And transforming between coordinate systems can always add some conversation failures ...

I don't know if the L-system is the best way to go. I've implemented it in a program where all "tracks" are one-way which makes the situation a bit different. The program also have very strict build/simulation mode which discards all traffic when changing to build mode. Still I don't know if the L system is better. It simplify the simulation part of my program but require some extra calculations to export the L-coordinates to XYZ for the graphics engine.

I just wanted to share this idea since it might be usable for TE. Still I don't know if it is a good way to go.