Ideas about map and track laying
Moderator: Transport Empire Moderators
Ideas about map and track laying
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
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
-
- Transport Empire Developer
- Posts: 699
- Joined: 03 Feb 2003 09:30
- Location: Back at the office
Re: Ideas about map and track laying
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.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:
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%).The map is probably the biggest object to store and render.
Interesting...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 .
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?But you need to do that only when the viewport (point-of-view) changes.
This would make a really nice way of changing the LOD on different zoomlevels, but also on different video cards.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.
What is stored in memory? The transformations themselfs or the results of the transformations?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.
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 )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 like idea in the last sentence .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.
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).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.
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.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
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Code: Select all
+------------Oo.------+
| Transport Empire -> |
+---------------------+
Under construction...
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: Ideas about map and track laying
1024x1024 map made of: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.
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;
};
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Re: Ideas about map and track laying
Polymorphism in a tight loop is never a good thing.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%).
Exactly. Of course we don't need the rest of the map if we are zoomed on a small portion of it.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?But you need to do that only when the viewport (point-of-view) changes.
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.What is stored in memory? The transformations themselfs or the results of the transformations?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
Ahhh good! The last time I looked at this stuff was 7 years ago. Gee I'm old...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 )
You are right, we could simplify the network that way. Much less nodes to traverse when analysing it means faster results.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).
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]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.
Re: Ideas about map and track laying
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".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
True, I also fear the overhead of computing the triangles on the fly. You think it will be too much?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).
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.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).
err.... Right. And a map without cliffs or sharp mountains would be a bit dull. I didn't think of that.Also - bezier patches would disallow making cliffs except for places which make patches join.
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.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: Ideas about map and track laying
You are right.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".
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
};
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.
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.True, I also fear the overhead of computing the triangles on the fly. You think it will be too much?
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).
Well. I more think about is the effect really worth the extra MIPS to calculate it.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 - 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.err.... Right. And a map without cliffs or sharp mountains would be a bit dull. I didn't think of that.
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.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.
But I'm all for the tool that proves most useful
True, trueBeside 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.
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
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.
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
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
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.
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.
Free-form track laying
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.
Re: Free-form track laying
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 wrote:Actually for those who think that free form track laying is not an option, if I remember correctly, Railroad Tycoon 2 had that
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.
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)
Junctioneer (a traffic intersection simulator)
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
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.
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
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
RT3
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 :
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.
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.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
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.
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Who is online
Users browsing this forum: No registered users and 3 guests