[ott3d] Tracks

Discussions related to programming Transport Empire.

Moderator: Transport Empire Moderators

ohlidalp
Engineer
Engineer
Posts: 98
Joined: 27 Aug 2007 18:46
Location: mapy.cz/?query=rajhrad
Contact:

[ott3d] Tracks

Post by ohlidalp »

----------------------------------------------------------------------------------------------------
* NOTICE *

The OTT3D project, which is discussed here, is DISCONTINUED.
However, the proposed track-system is implemented in OgreRails project.
----------------------------------------------------------------------------------------------------


Hello.

In this thread I'd like to discuss implementation of tracks in the ott3d branch.

The chosen method is to use pre-designed track sections (separate meshes) which would snap to each other. This is a simple and effective method IMO. However, there are still many unresolved issues.

Firstly, there are no rules regarding sizes and shapes of track sections. This could make it impossible to connect two ens of track because no piece fits there.
Secondly, the track pieces can be laid absolutely freely, which may cause the previously mentioned problem even if all track sections are standartised - the player can simply start two tracks separately in such relative positions that no set of sections can join them.

My suggestion adressing both above problems is outlined in the attached pdf.

Finally, a track section management system needs to be developed. Currently, the sections are hard-coded, which works for a temporary solution, but it's unacceptable as a final solution. For one thing, nobody else but lonwolf can create new track pieces ( and I'd like to make some ).

My suggestion:
  1. Create an abstract representation of a track section, i.e.:

    Code: Select all

    struct TrackSection{
        Ogre::Entity* mTrack;
        Ogre::SceneNode* mCheckpointA;
        Ogre::SceneNode* mCheckpointB;
    
        Ogre::SceneNode* build(unsigned x, unsigned y, unsigned z, unsigned direction);
    }
  2. Create a track-description file which will link checkpoint data to ogre resources, thus making it possible to add sections dynamically. For example:

    Code: Select all

    <xml>
        <section mesh_name="StraightTrack.mesh">
            <checkpoint name="A" x="1" y="2" z="3"></checkpoint>
            <checkpoint name="B" x="3" y="2" z="1"></checkpoint>
        </sections>
    </xml>
~An00biS

EDIT: Added the "DISCONTINUED" notice.
Attachments
TrackProposalByAn00biS.pdf
(147.01 KiB) Downloaded 479 times
Last edited by ohlidalp on 15 Oct 2011 09:15, edited 1 time in total.
Rigs of Rods maintainer.
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

Firstly, there are no rules regarding sizes and shapes of track sections. This could make it impossible to connect two ens of track because no piece fits there.Secondly, the track pieces can be laid absolutely freely, which may cause the previously mentioned problem even if all track sections are standartised - the player can simply start two tracks separately in such relative positions that no set of sections can join them
I'm aware of that, and thinking of something to make it possible.
Your proposal is interesting, however it won't allow you to place everywhere, which reduces the freeform mode. (except the build_checkpoints you add to simulate a graph something like the one in the pdf).

And yes, if you start to build a track from 2 ends, there's a probability of slightly over 90% that they won't fit very well (a little error margin can be added to reduce that chance).

There might be another way, and i was thinking about this: make very slim track pieces to allow you to fine tune the track linking (i.e., a simple forward track is 6 units in lenght, the slim version should have 1.5 + some curved 1.5 sections). Thus, working with small values, may result in placing tracks under the error margin and solve this problem with close tracks not fitting.

Finally, a track section management system needs to be developed. Currently, the sections are hard-coded, which works for a temporary solution, but it's unacceptable as a final solution.
You want me to script a filesystem using std::istream ? or if you have a simple xml library i'll leave that to you.

Also a tip about structures in C++: never use functions in struct{}. I know, C++ allows it, but it's not clean, you can't distinguish a structure variable from a class instance object and will mess up the code. If you want to use functions in it, make it a class.

Also, i liked the idea however i didn't really got why are all the params declare as unsigned and undeclared type (it should be Vector3 pos and Vector3 dir, or Quaternion Orientation;)
And, the current code attributes 4 checkpoints ( 2 near the primary 2) at auto-fit.
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

Here's a pic describing what i had in mind.
linking_problem.jpg
linking_problem.jpg (31.31 KiB) Viewed 24871 times
The first 2 rows show how it is supposed to work.

The third (marked by red) is an example where the algorithm will refuse to place it due to the 3 vectors non-alignment (2 vectors describing the direction of the 2 tracks, and a third, describing the direction from the primary checkpoint of one track to the primary checkpoint of the other)

The fourth (green) shows how it would also work for linking 2 curve tracks also if they are properly aligned.

If you ever reach case 3, then you need to destroy a track and place a different curved one (more curved tracks with different angles needed here...)

That will solve the problem (besides adding more tinier tracks, not just a 1.5 length, and also note, all of them straight).

Also note, we need to make them more standard so cases like the third should be reduced. At the moment they are modeled just to show how the auto-fit should work, but not designed for linking 2 different tracks.
ohlidalp
Engineer
Engineer
Posts: 98
Joined: 27 Aug 2007 18:46
Location: mapy.cz/?query=rajhrad
Contact:

Re: [ott3d] Tracks

Post by ohlidalp »

lonwolf89 wrote:Your proposal is interesting, however it won't allow you to place everywhere, which reduces the freeform mode...
Sometimes too much freedom complicates gameplay. I really don't like the idea of designing a new game to require inaccurate track placement. I think my suggestion is fine if the endpoint-grid is dense enough - the player gets a lot of freedom and it's still possible to design track pieces which fit perfectly.
lonwolf89 wrote:If you ever reach case 3, then you need to destroy a track and place a different curved one (more curved tracks with different angles needed here...)
Not very player-friendly. Seems more like a design flaw to me, no offense.
lonwolf89 wrote:...or if you have a simple xml library i'll leave that to you.
I suggest incorporating tinyXML. And, I'm willing to do the coding myself. But first we need to settle on the track implementation (I still ain't giving up on my proposal 8) )
lonwolf89 wrote:never use functions in struct{}. I know, C++ allows it, but it's not clean
http://en.wikibooks.org/wiki/C%2B%2B_Pr ... eclaration :
http://en.wikibooks.org/wiki/C%2B%2B_Pr ... Structures:
As you can see, a struct and a class are practically the same thing. A struct can be used anywhere a class can be and vice-versa. The only technical difference is that class members defaults to private and struct members defaults to public.

I've read there is some C-compatibility in structs however. So okay, I'll stick to "class" keyword.
Rigs of Rods maintainer.
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

Okay then, sounds reasonable, let's settle the grid.

The current code allows you to move and place the tracks at more or even less than 0.1 units in Ogre space. That ads absolute freeform but it's a b*&%$ with building from different start points.

To avoid those nasty cases the placing can be forced to use 0.25 divisions for example (that should be 25 cms at a 1:1 model scale and sounds reasonable enough?) or 0.2. Or even 0.1;

So it's either a 4x4 grid on a square meter or a 5x5 (or a 10x10). I can't figure it out on the pdf you uploaded what's the exact "grid" scale, but after this is set, the designing of new tracks can start, so they fit quite nicely.

Apart from that, i can write the autoClamp() function to make the mBuild entities attached to the mBrushNode move only on that grid.

Also using this grid might have some impact on autoFitTracks() in terms of possible slight optimizing.

[edit] i'm leaving the tinyXml for you to code then, but code it after i wrap the mBrush and autoFitTracks() into a new class (probably called Brush) so it will clean up GameManager.
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

There's also a major flaw with the grid system tho.
If you use a square grid you can have only 4 orientations for straight tracks (including stations) and using a triangle system will add 4(i think) more orientations. That just blows the freeform away. The reason: a straight track will fit only on the same length grid pieces and you will eventually end up with something like in OTTD but with nice smooth curves. That's why i wouldn't recommend it.

However i have thought about a more simple and clean solution to the current placing form.
If you ever reach case 3 and 4 in the above picture (2-3 posts up) i can script a tool that automatically moves the entire track piece to perfectly fit the other (only if close to each other). Sounds not a good solution? let's analyze it:

Pros:
-complete 360 degree and any coordinates for tracks - ultimate freeform
-simple to use for players, no grid for user calculations required
-simple and clean to code
-you can specify what track piece to clamp
-uses the same data-storage as the Pathfinding algorithm

Cons:
-not realistic (but hey, name me a game that's 100% real)
-won't be able to move an entire existing track if it's something in the way (so you would need to make a workaround) - but that's your fault for constructing 2 separate stations in very tight locations and then worrying about linking them instead of designing from 1 end to the other.

The cons are somewhat something i would consider since i won't think about sacrificing this freeform.

The fact is, if we use grids, it will heavily limit the tool, no matter what density you use (just because of a basic math principle, the only equal plane closed object is a triangle with all edges equally designed, but limits orientations to 60 degrees rotations - and that's asking a lot).

The conclusion? grid = sacrificing everything i thought about the very base of this game and will have a building system close to TTD and TE.

Except for modeling tracks at runtime (doable, but a pain to work with vertexes since Ogre is not a 3dsMax tool but a simple rendering engine), i can't think of anything that keeps this system alive.

Also, this solves the current problem and it's easy to fix and keep things running freeform and allows accurate track placing :)
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Re: [ott3d] Tracks

Post by Hyronymus »

Let me start with saying I don't understand anything of the coding issues mentioned above. I'm just kicking in here from the player point of view. How will a track algorythm work if you want to double an existing single track? And what if my track isn't for a a tran or car but a canal for ship?
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

Let me start with saying I don't understand anything of the coding issues mentioned above.
Well, in short terms, imagine you place 2 stations in random points of the map. Then you start placing track pieces and try to connect each other. Since the clampTracks() function isn't in v0.02, you will most likely end up with 2 track ends that need to be connected, but there is no track piece to properly connect them (i.e. they are in straight line, the distance between them is 1 unit, and the shortest straight track is 6 units long). What's the deal with the clampTracks() function? well simply put, you can use it to select one of the track ends, and move it in perfect place with the other. You can do this to the remaining track pieces (including the station) or, try the extended version clampAllAdiacentTracks() to move all the track pieces from one side, in such a way to perfectly fit the other track - and you have a connection. This will only work if the distance between the 2 track ends will be very small.

Why bother with this function? it's the simplest method to link improper placed tracks and keep the ability to build anywhere and at any angle.
How will a track algorythm work if you want to double an existing single track?
you mean placing another track along it? simple, just start placing a station near the original and build along the other track.

Well, i can't explain the algorithm in depth here. But, if you wait for it to be coded (shouldn't take more than a few days(depends if i'm home or not) to make it working) and you can download the ott3d folder from the ftp after a newer version will be released (pre-compiled for windows) and play with it then. And, optionally, give some feedback on how everything is turning along.
And what if my track isn't for a a tran or car but a canal for ship?
well, i for one never used canals in ottd (noobish me maybe?) - i've always seen the ships act stupid in most of the cases and not efficient at all - but it will probably coded the same.

the best way to see how it works is to wait for a release to play with it.

Note: there will no be any station name, or the guarantee that 2 stations placed along each other will be viewed as one, since that's not a priority - it can be easily coded based on the current algorithms and they need to be finished first.
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Re: [ott3d] Tracks

Post by Hyronymus »

OK, I'll keep an eye on a release with track laying enabled.
ohlidalp
Engineer
Engineer
Posts: 98
Joined: 27 Aug 2007 18:46
Location: mapy.cz/?query=rajhrad
Contact:

Re: [ott3d] Tracks

Post by ohlidalp »

lonwolf89 wrote:If you use a square grid you can have only 4 orientations for straight tracks...
That's not true. Look:
Demonstration of possible track section orientations.
Demonstration of possible track section orientations.
DiagonalTrack.png (65.28 KiB) Viewed 24718 times
lonwolf89 wrote:...try the extended version clampAllAdiacentTracks() to move all the track pieces from one side, in such a way to perfectly fit the other track - and you have a connection.
That only helps if you're connecting separate tracks. If you're connecting two parts of one track, i.e. building a circle, you're stuck again.

The grid is a limitation, but I'd consider it an advantage. It would help the player to build two tracks with a constant spacing or equal height when building elevated track. Myself, if a free track system is chosen, I'd still appreciate an optional snap-to-grid feature.

As for the grid size, I'd say 1m is a minimum, everything smaller would be nearly freeform. 2m would be fine.
A 1x1 meters grid
A 1x1 meters grid
EndpointsGrid.png (170.06 KiB) Viewed 24720 times
[edit] I'd also suggest to build stations along existing track like it's done in all games apart of Transport Tycoon.

~An00biS
Rigs of Rods maintainer.
User avatar
Arathorn
Tycoon
Tycoon
Posts: 6937
Joined: 30 Nov 2002 17:10

Re: [ott3d] Tracks

Post by Arathorn »

An00biS wrote:[edit] I'd also suggest to build stations along existing track like it's done in all games apart of Transport Tycoon.
I don't really like that approach in other games. Maybe it's just a problem of implementation, but you never get a nice multi-track station that way. In reality, stations are build first too.
User avatar
CommanderZ
Tycoon
Tycoon
Posts: 1872
Joined: 07 Apr 2008 18:29
Location: Czech Republic
Contact:

Re: [ott3d] Tracks

Post by CommanderZ »

An00biS wrote:...
Are you aware how many possible tracks will you have to create?

With 4*4*4 grid you have (I hope my calculation is correct) 4^6 possible tracks. Some of these are impossible, but most are completely valid. And you seem to be planning the possible grid to be much larger...
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

Are you aware how many possible tracks will you have to create?

With 4*4*4 grid you have (I hope my calculation is correct) 4^6 possible tracks. Some of these are impossible, but most are completely valid. And you seem to be planning the possible grid to be much larger...
he is completely right. you can't place a 12 meter track on a 360 degree angle on that system, so you have to create at least 10 versions of it with variable length. That's a pain to do.
lonwolf89 wrote:
...try the extended version clampAllAdiacentTracks() to move all the track pieces from one side, in such a way to perfectly fit the other track - and you have a connection.

An00bis wrote:
That only helps if you're connecting separate tracks. If you're connecting two parts of one track, i.e. building a circle, you're stuck again.
I got a friend in this (real life mate) and he has redesigned and remodeled the tracks (looking way better and accurate).
If you use my tracks of course you won't be able to make a circle because they were modeled in 4 minutes!

On the other hand, the new track sets fit perfectly for circles (and symmetric loops) . If you use asymmetric tracks with wrong checkpoints (which is the case of the tracks in 0.02 since they were modeled in a rush and have inaccurate checkpoints) they won't fit in loops and circles :)

you will see with your own eyes in 0.03
(i will also add a class to handle checkpoint data from a standard txt file, so if you want to script a xml tool based on what i do, you can change that class easily and give it a nicer format :] )
ohlidalp
Engineer
Engineer
Posts: 98
Joined: 27 Aug 2007 18:46
Location: mapy.cz/?query=rajhrad
Contact:

Re: [ott3d] Tracks

Post by ohlidalp »

lonwolf89 wrote:
4^6 possible tracks.
he is completely right.... That's a pain to do.
It isn't that bad. I'd only create a reasonable amount of track sections because if there were too many, only a subset would be actually used. Remember the pieces can be rotated and mirrored along both axes, so for example an X1Y3 piece actually gives you 8 possible directions. And, I volunteer to do the work.
lonwolf89 wrote:remodeled the tracks (looking way better and accurate). ...you will see with your own eyes in 0.03
I can't wait :))
lonwolf89 wrote:(i will also add a class to handle checkpoint data from a standard txt file, so if you want to script a xml tool based on what i do, you can change that class easily and give it a nicer format :] )
Sure will

~An00biS
Rigs of Rods maintainer.
User avatar
lonwolf89
Engineer
Engineer
Posts: 55
Joined: 09 Sep 2009 18:36
Skype: same as y!
Location: Bucharest
Contact:

Re: [ott3d] Tracks

Post by lonwolf89 »

just a small update to show that there's no need to worry about closed loops :]
you can do tracks like this one using any combination of pieces :mrgreen: (so far i only scripted the 90 degree one and used 4 of them)
screenshot_1.jpg
screenshot_1.jpg (92.47 KiB) Viewed 24622 times
User avatar
Zhall
Tycoon
Tycoon
Posts: 1237
Joined: 17 Jul 2007 01:36
Skype: moonray_zdo
Location: Teh matrix, duh.
Contact:

Re: [ott3d] Tracks

Post by Zhall »

So... Transport empire has become ott3d? hmm...
User avatar
CommanderZ
Tycoon
Tycoon
Posts: 1872
Joined: 07 Apr 2008 18:29
Location: Czech Republic
Contact:

Re: [ott3d] Tracks

Post by CommanderZ »

Sapphire united wrote:So... Transport empire has become ott3d? hmm...
No, the OTTD3D guys just completely abducted TE's forum and wikipedia :twisted: :roll:
User avatar
Zhall
Tycoon
Tycoon
Posts: 1237
Joined: 17 Jul 2007 01:36
Skype: moonray_zdo
Location: Teh matrix, duh.
Contact:

Re: [ott3d] Tracks

Post by Zhall »

hmm.. seems like the name of the forums should be changed... seems more promising in a much shorter time than the other devolopement :D
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Re: [ott3d] Tracks

Post by Hyronymus »

Hmm, how did that happen?
ohlidalp
Engineer
Engineer
Posts: 98
Joined: 27 Aug 2007 18:46
Location: mapy.cz/?query=rajhrad
Contact:

Re: [ott3d] Tracks

Post by ohlidalp »

CommanderZ wrote:
Sapphire united wrote:So... Transport empire has become ott3d? hmm...
No, the OTTD3D guys just completely abducted TE's forum and wikipedia :twisted: :roll:
Myself, I think of OTT3D as a TE branch, i.e a sub-project of the whole TE effort. I don't think we're hijacking the web of forum, all posts/pages are prefixed OTT3D to mark them separate from the TE trunk stuff.

I support the idea replacing the current trunk because Uzurpator is probably the only one willing to continue it.

Anyway, let's not get off-topic here. :wink:
Rigs of Rods maintainer.
Post Reply

Return to “Transport Empire Coding”

Who is online

Users browsing this forum: No registered users and 4 guests