Ideas about map and track laying

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

Moderator: Transport Empire Moderators

Shrimp
Engineer
Engineer
Posts: 22
Joined: 02 Oct 2004 01:14
Location: Montreal, Canada

Ideas about map and track laying

Post by Shrimp » 02 Oct 2004 03:26

The first thing that is said in the design doc is that this game is going to be 3D. However, from what I see, the rest of the concept is still tile-based. Since it works in 3D, the map doesn't really need to be grid-based. both horisontally and vertically. We could use new ways (comparing to TTD and Loco) of laying tracks and road. Let me explain:

The map is probably the biggest object to store and render. Rendering nowadays is "simple" if the scene is setup properly in the graphic card and if the polygon count is low enough. But how to keep a reasonable polygon count for the map and still have the zooming feature? My suggestion is to use Bezier Maps. Please check this little demo (not mine) : http://www.cse.ogi.edu/~andy/applets/bezier.htm

With Bezier maps, you only need to store the skeleton in memory. When rendering, polygons need to be computed before the actual image render is made but only for the current viewport . But you need to do that only when the viewport (point-of-view) changes. As demonstrated in the applet, it is easy to vary the subdivisions as we like. When zoomed closely, we can increase the number of divisions for more detail. When zoomed far away, we can reduce the number of divisions to keep an acceptable number of polygons. Anyway, when away, you don't need as much detail.

The next question is: what about landscaping made by the user? For that I will borrow another idea from 3D packages such as Softimage, which is deformations (see http://www.softimage.com/community/exp/ ... mation.pdf) for an example of what I mean, its the part where they explain how to draw the roots of the plant). These objects don't add anything to the scene. They just modify existing objects. So with these operators, you can lower or raise the existing polygons. Normally, players will lower or raise the land to make room for tracks, roads, stations or airports. When one object of this type is put on the map, we can simply apply a transformation operator with it to level the terrain automatically, without having to prepare the terrain beforehand. You'll see how this blands well with the next topic, track laying.

For track laying (or road laying), I'd like to propose we use bezier curves and B-Splines. Please see examples of this here: http://www.idi.ntnu.no/~mlh/codebase/grafisk2/
A bezier curve is defined with 4 points (or actually 2 pairs). The starting pair define the starting point and the tangent at the start point. The end pair does the same thing at the end. By joining multiple segments like this and keeping the tangents locked between the segements, you can define a path (a B-Spline). This is very far in my head so I don't remember the details. But I know it can be done.

Using this the player can simply click and draw a series of segments and the curvature of the track would be automatically adjusted (of course the handles to adjust the curvature would need to be available so the player can increase/decrease the radius). For slopes, I suggest having a system like locomotion where you have a button to force flat building and buttons to force a slope (could be a slider as well). For exemple, if the player is building in "flat" mode, we apply proper deformation operators to the map surface to dig or raise the land so the track says level. Same for slopes. However, at a certain height or depth, the track need to become either a bridge or a tunnel. At the end, just click a big "build this" button to actually put the track down. This way the player can build and review his track before spending the money.

If we think about algorithms and structures for this, it is easy to imagine that each segment point is a "node" in a big network. Having such a network redily available is very usefull for pathfinding using Djikstra shortest path algorithm.

This overall system has the following features:
- Relatively low memory footprint for the map
- Infinite zoom level with appropriate performance adjustment
- You can lay long stretches of track with 2 clicks (like in TTD)
- You can lay curves of *any*curvature in 2 to 4 clicks
- You can have undeground tracks or high bridges (like in Loco)
- Tracks can be in *any* direction, not only the 8 standard ones.
- Can apply to roads as well
- UI model matches conceptual model (segments linking nodes together)
- Track/road information takes less space than in a tile-based model (each tile need to keep the info).
- Takes advantage of the 3D world, not only for display.

Drawbacks:
- Generating the polygons might take time (need prototyping)
- Bezier based method is probably new to many players.
- ???

Ouf... Ok this was long and I threw lots of things at you so I'll stop here. Sorry if it is not clear, I'm not sure how to explain it. I'll try to find time cook some screenshots to illustrate this during the weekend. Don't hesitate to shoot these ideas to pieces :)

Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Re: Ideas about map and track laying

Post by Hellfire » 02 Oct 2004 13:23

Shrimp wrote:The first thing that is said in the design doc is that this game is going to be 3D. However, from what I see, the rest of the concept is still tile-based. Since it works in 3D, the map doesn't really need to be grid-based. both horisontally and vertically. We could use new ways (comparing to TTD and Loco) of laying tracks and road. Let me explain:
There are indeed some references to a tile based map in the design documents. In my opinion, other map styles are still open for discussion, like tringle maps, hex maps or even non-tile based maps.
The map is probably the biggest object to store and render.
True. I've made a small prototype to benchmark polymorphism on map tiles. Didn't work: 1,000,000+ member function calls per frame produces too much overhead (around 10%).
Rendering nowadays is "simple" if the scene is setup properly in the graphic card and if the polygon count is low enough. But how to keep a reasonable polygon count for the map and still have the zooming feature? My suggestion is to use Bezier Maps. Please check this little demo (not mine) : http://www.cse.ogi.edu/~andy/applets/bezier.htm

With Bezier maps, you only need to store the skeleton in memory. When rendering, polygons need to be computed before the actual image render is made but only for the current viewport .
Interesting...
But you need to do that only when the viewport (point-of-view) changes.
The first thought that came up to me was "why?" Buf of course, you mean that the polygons are only computed for the visible section of the bezier map. Right?
As demonstrated in the applet, it is easy to vary the subdivisions as we like. When zoomed closely, we can increase the number of divisions for more detail. When zoomed far away, we can reduce the number of divisions to keep an acceptable number of polygons. Anyway, when away, you don't need as much detail.
This would make a really nice way of changing the LOD on different zoomlevels, but also on different video cards.
The next question is: what about landscaping made by the user? For that I will borrow another idea from 3D packages such as Softimage, which is deformations (see http://www.softimage.com/community/exp/ ... mation.pdf) for an example of what I mean, its the part where they explain how to draw the roots of the plant). These objects don't add anything to the scene. They just modify existing objects. So with these operators, you can lower or raise the existing polygons. Normally, players will lower or raise the land to make room for tracks, roads, stations or airports. When one object of this type is put on the map, we can simply apply a transformation operator with it to level the terrain automatically, without having to prepare the terrain beforehand. You'll see how this blands well with the next topic, track laying.
What is stored in memory? The transformations themselfs or the results of the transformations?
For track laying (or road laying), I'd like to propose we use bezier curves and B-Splines. Please see examples of this here: http://www.idi.ntnu.no/~mlh/codebase/grafisk2/
A bezier curve is defined with 4 points (or actually 2 pairs). The starting pair define the starting point and the tangent at the start point. The end pair does the same thing at the end. By joining multiple segments like this and keeping the tangents locked between the segements, you can define a path (a B-Spline). This is very far in my head so I don't remember the details. But I know it can be done.
I've had a class on the mathematics of B-splines in school two weeks ago. I still remember ;) (And the pdf sheets on my harddrive remember even better :P)
Using this the player can simply click and draw a series of segments and the curvature of the track would be automatically adjusted (of course the handles to adjust the curvature would need to be available so the player can increase/decrease the radius). For slopes, I suggest having a system like locomotion where you have a button to force flat building and buttons to force a slope (could be a slider as well). For exemple, if the player is building in "flat" mode, we apply proper deformation operators to the map surface to dig or raise the land so the track says level. Same for slopes. However, at a certain height or depth, the track need to become either a bridge or a tunnel. At the end, just click a big "build this" button to actually put the track down. This way the player can build and review his track before spending the money.
I like idea in the last sentence :D.
If we think about algorithms and structures for this, it is easy to imagine that each segment point is a "node" in a big network. Having such a network redily available is very usefull for pathfinding using Djikstra shortest path algorithm.
In this network, you would have a lot of nodes with just two edges. I suggest having a second network, without nodes of degree two, which can be made from the first network by removing all nodes with just two edges and joining those two edges into one larger edge. Information stored in the old edges (like for example, length of the edge) can be combined into the new edge. (which means adding the two lengths of the older nodes).
This overall system has the following features:
- Relatively low memory footprint for the map
- Infinite zoom level with appropriate performance adjustment
- You can lay long stretches of track with 2 clicks (like in TTD)
- You can lay curves of *any*curvature in 2 to 4 clicks
- You can have undeground tracks or high bridges (like in Loco)
- Tracks can be in *any* direction, not only the 8 standard ones.
- Can apply to roads as well
- UI model matches conceptual model (segments linking nodes together)
- Track/road information takes less space than in a tile-based model (each tile need to keep the info).
- Takes advantage of the 3D world, not only for display.

Drawbacks:
- Generating the polygons might take time (need prototyping)
- Bezier based method is probably new to many players.
- ???

Ouf... Ok this was long and I threw lots of things at you so I'll stop here. Sorry if it is not clear, I'm not sure how to explain it. I'll try to find time cook some screenshots to illustrate this during the weekend. Don't hesitate to shoot these ideas to pieces :)
Actually, I like your ideas, but I wonder if the players of the game will like them. To quote you: "need prototyping". Build some toy examples and let some people play with it. See if it works.
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...

User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2134
Joined: 10 Jan 2003 12:21
Location: Wroclaw, Poland / Katowice, Poland

Re: Ideas about map and track laying

Post by uzurpator » 02 Oct 2004 14:41

Shrimp wrote:The map is probably the biggest object to store and render. Rendering nowadays is "simple" if the scene is setup properly in the graphic card and if the polygon count is low enough. But how to keep a reasonable polygon count for the map and still have the zooming feature? My suggestion is to use Bezier Maps. Please check this little demo (not mine) : http://www.cse.ogi.edu/~andy/applets/bezier.htm

With Bezier maps, you only need to store the skeleton in memory. When rendering, polygons need to be computed before the actual image render is made but only for the current viewport . But you need to do that only when the viewport (point-of-view) changes. As demonstrated in the applet, it is easy to vary the subdivisions as we like. When zoomed closely, we can increase the number of divisions for more detail. When zoomed far away, we can reduce the number of divisions to keep an acceptable number of polygons. Anyway, when away, you don't need as much detail.
1024x1024 map made of:

Code: Select all

struct tile
{
unsigned short int lower_corner_height;
unsigned short int right_corner_height;
unsigned short int upper_corner_height;
unsigned short int left_corner_height;
};
Takes 8 MB. This is the geometry saved by using bezier curves. What is ON the tile takes much more memory then the geometry alone. Obviously using bezier curves the contents will take as much (or more) memory - with overhead required to calculate triangles (triangulating a square is banal) and positions of objects (tiles have all their structural data stored explicly while bezier patches only have nodes).

Using large bezier patches (for terrain that would normally eat 10x10 tiles) would make landscaping very rough since the basic element (patch) is ver large - unless a patch had 9x9 nodes, but that defies the point of using a patch (and counting 9th power equations is sorta time consuming).

Also - bezier patches would disallow making cliffs except for places which make patches join.

Patches are very inflexible for terrain storing. But they are very good for terrain creation and modification. This way very precise and take several tiles at once.

For creation it would involve several patches creating a surface that would later be tiled. These patches would take very little space so the can be transferred via network/internet - unlike ready tiled map.

For modification - a player would span a patch over some tiles and modify just the nodes - and the patch would modify the tiles it spans over.

As for the tracklaying - I am all for the survey first -> project -> build method.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.

User avatar
Arathorn
Tycoon
Tycoon
Posts: 6939
Joined: 30 Nov 2002 17:10

Post by Arathorn » 02 Oct 2004 14:48

I agree, that would also solve the problem that I build something wrong, demolish everything and start anew, wich is highly unrealistic.

About the technical stuff of the map i can't comment because I don't understand anything of it.

Shrimp
Engineer
Engineer
Posts: 22
Joined: 02 Oct 2004 01:14
Location: Montreal, Canada

Re: Ideas about map and track laying

Post by Shrimp » 02 Oct 2004 18:48

True. I've made a small prototype to benchmark polymorphism on map tiles. Didn't work: 1,000,000+ member function calls per frame produces too much overhead (around 10%).
Polymorphism in a tight loop is never a good thing.
But you need to do that only when the viewport (point-of-view) changes.
The first thought that came up to me was "why?" Buf of course, you mean that the polygons are only computed for the visible section of the bezier map. Right?
Exactly. Of course we don't need the rest of the map if we are zoomed on a small portion of it.
The next question is: what about landscaping made by the user? For that I will borrow another idea from 3D packages such as Softimage, which is deformations
What is stored in memory? The transformations themselfs or the results of the transformations?
My idea was to keep only the transformation e.g. "Raise 10 units along vector (1,2,3)-(9,8,7)". I don't know however how many transformations would be made by the user and if applying them at render time would be too time-consuming. Like I said this need a prototype.
I've had a class on the mathematics of B-splines in school two weeks ago. I still remember ;) (And the pdf sheets on my harddrive remember even better :P)
Ahhh good! :) The last time I looked at this stuff was 7 years ago. Gee I'm old...
In this network, you would have a lot of nodes with just two edges. I suggest having a second network, without nodes of degree two, which can be made from the first network by removing all nodes with just two edges and joining those two edges into one larger edge. Information stored in the old edges (like for example, length of the edge) can be combined into the new edge. (which means adding the two lengths of the older nodes).
You are right, we could simplify the network that way. Much less nodes to traverse when analysing it means faster results.
Actually, I like your ideas, but I wonder if the players of the game will like them. To quote you: "need prototyping". Build some toy examples and let some people play with it. See if it works.
I will take a while because it's currently crunch time at work so I'll be working 60+ hours a week for the next month or so. Bleh, I shiver just thinking of it. As you can see, you don't get much more free time after university... [/quote]

Shrimp
Engineer
Engineer
Posts: 22
Joined: 02 Oct 2004 01:14
Location: Montreal, Canada

Re: Ideas about map and track laying

Post by Shrimp » 02 Oct 2004 19:17

Takes 8 MB. This is the geometry saved by using bezier curves. What is ON the tile takes much more memory then the geometry alone. Obviously
Correct me if I'm wrong, but the great majority of the tiles in TTD have nothing on them. But still we need to keep memory for each of them anyway. I think it is better to use a system where you keep objects in a separate structure where you simply specify the position of the object and its type. That way you dont use memory to store "emptyness".
with overhead required to calculate triangles (triangulating a square is banal) and positions of objects (tiles have all their structural data stored explicly while bezier patches only have nodes).
True, I also fear the overhead of computing the triangles on the fly. You think it will be too much?
Using large bezier patches (for terrain that would normally eat 10x10 tiles) would make landscaping very rough since the basic element (patch) is ver large - unless a patch had 9x9 nodes, but that defies the point of using a patch (and counting 9th power equations is sorta time consuming).
For landscaping, like I said, I would not change the bezier patch itself. I would apply a local transformation to a patch of triangles (all points +10 in Y for example). But this methode might be more usefull for terrain creation like you said. Depends how much computing power it needs.
Also - bezier patches would disallow making cliffs except for places which make patches join.
err.... Right. And a map without cliffs or sharp mountains would be a bit dull. I didn't think of that.
For modification - a player would span a patch over some tiles and modify just the nodes - and the patch would modify the tiles it spans over.

We can have other tools than a bezier patch for modifications. A simple vector that pushes or pulls triangles for example. You only need to transfer the vector and if it pushes or pulls.

Beside bezier patches, there are other ways we could generate the map depending on the zoom level. I still think we should research in that direction.

User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2134
Joined: 10 Jan 2003 12:21
Location: Wroclaw, Poland / Katowice, Poland

Re: Ideas about map and track laying

Post by uzurpator » 02 Oct 2004 20:50

Shrimp wrote:Correct me if I'm wrong, but the great majority of the tiles in TTD have nothing on them. But still we need to keep memory for each of them anyway. I think it is better to use a system where you keep objects in a separate structure where you simply specify the position of the object and its type. That way you dont use memory to store "emptyness".
You are right.

I thought of that. My idea for a tile was something like this:

Code: Select all

struct tile
{
unsigned short int lower_corner_height; //height of lower corner
unsigned short int right_corner_height; //height of right corner
unsigned short int upper_corner_height; //height of upper corner
unsigned short int left_corner_height; //height of left corner
unsigned short int type; //type of the tile (desert, grass etc)
void *content; //pointer to contents of the tile
unsigned char owner_north; //owner of the north triangle
unsigned char owner_east; //owner of the east triangle
unsigned char owner_south; //owner of the south triangle
unsigned char owner_west; //owner of the west triangle
};
void pointer then would be projected into a type of contents (NUL, trees, building etc).

The rough map at 1024x1024 takes 18 MB + contents.

Another option would be to make a matrix of objects with their coords of objects and skip the binding of the to the tiles/patches.

Depends which of those two is faster I guess.

BTW with patches it would be annoying to decide who owns the land.
True, I also fear the overhead of computing the triangles on the fly. You think it will be too much?
200 visible tiles is 400 triangles or 4000 triangles/sec. The calculation is really easy. With gouraud shading it is pretty much impossible to tell the triangles apart.
For bezier patches the polycount can be similar, but the extra calculations to extract the triangles might not be worth it (Even if they are not all that important).
For landscaping, like I said, I would not change the bezier patch itself. I would apply a local transformation to a patch of triangles (all points +10 in Y for example). But this methode might be more usefull for terrain creation like you said. Depends how much computing power it needs.
Well. I more think about is the effect really worth the extra MIPS to calculate it.
err.... Right. And a map without cliffs or sharp mountains would be a bit dull. I didn't think of that.
Well - tiles are not so great here also - to get real irregular cliffs either bezier patches or tiles would have to get irregular (high polycount) shapes. The point is however, that a cliff can be made only on the edge of the basic map elements - and patches are by default larger then tiles.
We can have other tools than a bezier patch for modifications. A simple vector that pushes or pulls triangles for example. You only need to transfer the vector and if it pushes or pulls.
Well - single vector - even if modifies several tiles/patches - is still a single vector - so it only rises/lowers. 5x5 patch allows to make a complex shape (like a valley) in a few clicks on pretty much any scale.

But I'm all for the tool that proves most useful :)
Beside bezier patches, there are other ways we could generate the map depending on the zoom level. I still think we should research in that direction.
True, true :)
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.

User avatar
Korenn
Tycoon
Tycoon
Posts: 1628
Joined: 26 Mar 2004 01:27
Location: Netherlands, Enschede
Contact:

Post by Korenn » 03 Oct 2004 01:34

building tracks in any directions sounds like wonderful freedom...

but on the other hand, I spend hours of time in ttd / loco to make my networks as pretty looking as I can. I'm afraid that tracks might look crooked when you have a 360 degree arch to work with, resulting in ugly networks.
Creator of the Openttd Challenge Spinoff, Town Demand patch
The path to riches, a report on playing on a daylength server on ultra hard mode.

eXinion
Engineer
Engineer
Posts: 77
Joined: 22 Jun 2004 09:56
Location: Eindhoven, Netherlands

Post by eXinion » 03 Oct 2004 10:01

Some nice stuff I'm reading here...

Off-topic:
Hellfire: what class did you take in B-splines? I had a class of those last week too, it's called "Numeriek computergebruik" or "Numerical computerusage" (I think) in English. It also covered the Bezier-splines, but as we saw, that's just a special case of B-splines.

User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13189
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus » 03 Oct 2004 12:26

8 directions is more than enough. See the possibilities in Locomotion!

User avatar
Arathorn
Tycoon
Tycoon
Posts: 6939
Joined: 30 Nov 2002 17:10

Post by Arathorn » 03 Oct 2004 12:31

For gameplay reasons we might limit the building of train tracks and roads to 8 directions, but it would be very nice if we could have unbound plane and ship movement, as you don't have the fuss of creating infrastructure for those transport types (except for their dock/airport).

User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13189
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus » 03 Oct 2004 12:47

16 directions for air/water movement might be sufficient to create an animated fluency in movement.

Shrimp
Engineer
Engineer
Posts: 22
Joined: 02 Oct 2004 01:14
Location: Montreal, Canada

Free-form track laying

Post by Shrimp » 04 Oct 2004 02:21

Actually for those who think that free form track laying is not an option, if I remember correctly, Railroad Tycoon 2 had that (I don't know if it is still like that in RT3). Plus a very fine range of slopes. It was a good system. Much better than TTD or Locomotion in my opinion. If you wanted you could drag over a very long distance in any direction and use that track. Not that it would be the most efficient track, but you could do it. But it lacked lights and one-way tracks so you could not really build a network like in TTD. It was more a simulator of the economics of trains companies than engineering of tracks networks.

ChrisCF
Transport Empire Developer
Transport Empire Developer
Posts: 3608
Joined: 26 Dec 2002 16:39
Location: Over there --->

Re: Free-form track laying

Post by ChrisCF » 04 Oct 2004 03:50

Shrimp wrote:Actually for those who think that free form track laying is not an option, if I remember correctly, Railroad Tycoon 2 had that
Actually, it used square tiles and eight discrete directions. In fact, if you looked hard enough, there was even an option to show the tile grid which was normally hidden. ;)

Shrimp
Engineer
Engineer
Posts: 22
Joined: 02 Oct 2004 01:14
Location: Montreal, Canada

RT2

Post by Shrimp » 04 Oct 2004 15:19

Oh well, I stand corrected ;)

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu » 06 Oct 2004 08:22

Im the one who always liked to make the hypercomplex(and unrealistic) junctions.

I think that 8 directions is the ultimate. Also I think that slopes shuld be limited to a fixed amount of degrees. Ex 0, 25, 45, 65, 90. If we shuld allow 90 degrees or not, Im not sure. Technicaly it will wont be to difficult. Maby as a compromise allow a maximun height for vcertical slopes or make them more expencive than using usal slope.

There shuld not be to many diffrent degrres of slopes. A user shuld be abble to see a slope and tell which one it is. If we allow to many diffrent values, it will be more difficult to make a good user interface. Also as a player I dont want to have a perfect solution, becuse then there is no more tweeking to find a better soulution.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2134
Joined: 10 Jan 2003 12:21
Location: Wroclaw, Poland / Katowice, Poland

Post by uzurpator » 06 Oct 2004 14:13

Shrimp:

RT2 map is something that I want to achieve. It is tiled - but tiles can have any slopeness imaginable.

As for tracklaying - I wonder if bezier-curve would be a good solution. IT would make fairly easy to control minimum curvature (vertical and horizonal) that a train could handle. It would also make possible to auto-terraform large spaces.

If the bezier patches were built by control points then making perfectly parrallel tracks - and as a bonus - very wide curves - which are also railroad-like spiral ones. Good stuff Imvho.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.

User avatar
PJayTycy
Route Supervisor
Route Supervisor
Posts: 429
Joined: 09 Mar 2004 20:30

Post by PJayTycy » 06 Oct 2004 18:58

I'm an addicted RT3 and RT2 player, and although I know most of you don't like those games, I'll just tell what my feelings with their track-laying features are:


RT2
  • Rectangular grid, with 8 directions.
  • Height is stored for the grids cornerpoints (1 value for the 4 tiles sharing one corner).
  • If 4 points can have any arbitrary height, you run into problems when the 2 diagonals don't run through each other. You have to split the square in 2 triangles along one of those diagonals. The choice of diagonal has a great effect on the looks of a tile.
  • Tracks can be laid in 8 directions.
  • 90° turns are not possible (= a good thing)
  • Diagonal tracks can cross each other in the middle of a tile or at the corner of a tile.
  • Horizontal/vertical tracks can cross each ohter in the middle of a tile.
  • Track is laid from midpoint to midpoint
  • Although there is no signalling system visible, each cell of the grid acts as if it is one block. No 2 trains can be in movement on the same cell (except for double track ofcourse). Non-moving trains are grayed out and can be passed by other trains. Just imagine they are parked on an invisible siding.
  • The most important exploit here : diagonal tracks crossing at a corner point will not block each other. If you create such a crossing, the trains will run through each other without any harm (they are never on the same cell). :)

RT3
  • Rectangular grid (Yes, even that full-3D game uses a grid for its map).
  • Again 1 heightpoint for each corner, without any restrictions.
  • The problem for non-crossing diagonals is solved very neatly here : They don't divide the square in 2 triangles, but in 4. They calculate the mean height of the cell. They then draw 4 triangles with the tops in the calculated middle of the cell, and the bottom along the edge of the cell. If you do not create funky height differences (and even with the grid turned on), it's almost impossible to notice.
  • Track laying has nothing to do with those cells. Or atleast, so it seems to anybody who uses it. It's truly freeform from a user's perspective.
  • The tracks still look as "segments", but these are a lot smaller than the ground-mesh cells. I guess there is a very fine grid (perhaps 32*32 gridpoints/cell) where they align the segments to. Those segments have a lenght of +/- 16 gridpoints long and 8 gridpoints wide.
  • You can lay these down in virtually any direction. Any direction on a grid, with fixed length segments? Yes, it's possible. The lenghts are changed a little so the actually start/end on a gridpoint. Nobody will notice the difference in length between a segment of length 15.7 and one of length 16.3
  • There is only one 3D model for all these segments (well, there is one for single track and another one for double track), which is then stretched/shifted by the graphics card to slightly to addapt itself to the given start/stop points.
  • Each of these segments acts as a "block" of track.
  • Each segment has a single slope %.
  • Slowdowns for turns are calculated based on the sum of the angles between the different sections the train currently drives on.
  • To give an idea : a train with 6 cars typically occupies 8-10 of these segments.
  • To create a switch, they just create a second segment of track that shares the same gridpoint as another one.
  • To limit the radius of the turns, they just make it impossible to build segments with an angle of more than +/- 20° between them.
  • There are again problems with collision detection: if you create a switch, but don't branch of far from the original track, your new track can run "through" the original track for a few sections. Trains running on both of these parts of the track won't block each other, but run through each other.


I like the system behind RT3's track system, it's just the GUI for laying down track that lacks "control". You can only drag track, and are at the mercy of a very fancy track-laying-AI that will decide for you if you need a tunnel through that mountain, a bridge over that gap, or if will just take the grade. The radius of turns is also something that gets decided for you.

If they just allowed us to actually "see" the very fine grid they use to allign the tracks on,
If they just allowed us to put down sections of track one by one by hand.
If they just allowed us to decide by ourselves if (and exactly where) we want a tunnel through that mountain
If they would just allow us to turn of the snapp-to feature (so we could lay tracks very close parallel to each other)
If ...
Then a lot of track-control freaks like us would have liked their track system a lot better.


about splines for the tracks
I have played with this idea a little, and I think 3DTT has it (I only played the demo a little bit).
There are 2 big (related) problems:

1)Creating switches. You are restricted to the points where your spline starts/stops to add one. If you want to add a switch later in the game in a spot you didn't think about when you first built your track, there are 2 options:
A) The user has to bulldoze this section of track and lay it down again, and making a stop at that location.
B) The game provides some intelligence that automaticly splits up splines at any location the user wants, they then can continue without a problem. I didn't find any algorithms to do this kind of stuff. Remember, even if you can find the Real/Continuous location of the spot, and calculate the Real/Continuous tangents at that spot, they'll have to be turned into a discrete value somehow, which might make the track look jerky around that point.

2) Bulldozing a small part of track if you used one long spline to place it. This is the same problem as above: splitting splines.




conclusion
If you want the illusion of "freeform" track, I suggest you use something like the RT3 system to store the track internally in the game. Provide 2 sets of track-laying tools :
  • Some spline-like things, where you can lay a long section in 1 go. Make sure we can actually control the length and direction of the tangents at the start/stop locations. (Don't let some in-game intelligence decide that for us). Have some options as what to do with heights on the map:
    • Just follow them up and down = RT3 style,
    • cut-through / bridge-over everything to get 1 single grade for the whole spline = 3DTT style.
    • A hybrid system, that follows the ground if grades are less than x% and creates bridges/tunnels if the grades are higher.
  • Another set of tools that allows users do lay their tracks section by section

A lot of info in this post, but I don't think any of it has any chance to get in the final game? I have the feeling too many of you just want 8 directions again.

User avatar
Arathorn
Tycoon
Tycoon
Posts: 6939
Joined: 30 Nov 2002 17:10

Post by Arathorn » 06 Oct 2004 21:45

I would love freeform if it would be pratical. I've played the TT&T demo a little bit and I found it hard to place a station right.

User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2134
Joined: 10 Jan 2003 12:21
Location: Wroclaw, Poland / Katowice, Poland

Post by uzurpator » 06 Oct 2004 22:03

PJay.

That was a very good post. Altho The basic is a track with 4 directions.

Anyway.

Methinks that a perfect system would be bezier curves with snapping of control points to 4-way system.

This way both extensions would be easy to achieve and wide curves would be possible.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.

Locked

Return to “Transport Empire Development”

Who is online

Users browsing this forum: No registered users and 1 guest