[DD] Scale and limits

Development discussion about Transport Empire. Other discussion to General forum please.

Moderator: Transport Empire Moderators

User avatar
aarona
Traffic Manager
Traffic Manager
Posts: 221
Joined: 26 May 2006 15:54
Location: Perth, Australia
Contact:

Post by aarona »

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)
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
aarona
Traffic Manager
Traffic Manager
Posts: 221
Joined: 26 May 2006 15:54
Location: Perth, Australia
Contact:

Post by aarona »

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.
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
XeryusTC
Tycoon
Tycoon
Posts: 15415
Joined: 02 May 2005 11:05
Skype: XeryusTC
Location: localhost

Post by XeryusTC »

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.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
Image
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
Image Image Image Image Image Image Image
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os »

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 ...
User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu »

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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Post Reply

Return to “Transport Empire Development”

Who is online

Users browsing this forum: No registered users and 7 guests