Track

[beni]

Here the discussion about the track we want to implement in a real short amount of time.
Reading the code of the TrackManager, TrackElement, Curve, TrackNode and PilotNode I finally understood how the track works.
The "new" track is somehow different from the original design, but still has a lot in common. Some function will be exactly the same and I think that the TrackElement will have to be used again.
Track is actually a new TrackManager which approaches the problem in another way.

Things the Track has to be able to do:

• addPoints(Vector)
• create the track
• set the speed of the TrackNode
• get the position/orientation on the track after a certain time has elapsed (getPosition(float dt), getDirection(float dt))

It should be possible to create several tracks (not so hard to establish) so they can be used by the camera, the player or enemies.

I just created the class and was thinking about how the track will be used.
Does the spaceship create it's own track? That'll be stupid. So we have to get the tracks from somewhere and attach the camera, player or enemies to the TrackNode of the track we want them to follow.

Please be free to post any ideas or advices. I also might think into the wrong direction. Please tell me as soon as you can.

BTW: I work in the playability branch because it's connected to michel's project. I don't think I will interfere with his or the weapon brother's work. I've chosen the project also because michel's branch is closest to the vertical scroller view.

Now I go to sleep, tomorrow is implementation day.

[patrick]

hi beni,

Yea, you got some good ideas.

I just integrated the track again into the build process of Orxonox. As it was to be expected, there were some major compiling errors. I fixed all the bugs that are not directly related to the track subsystem (as the new object model etc.). As most of the old code didn't compile anymore, I just commented it out.

Loading Issue:
I implemented it directly into the WorldEntities: they now can have a Track object they are following. This is the simplest approach. Perhaps later, we will be able to use the ObjectInformationFile (.oif) that comes with the mounting point system.

For the camera it needs to be implemented also, but I will take care about this.

So it's now possible to define a Track for each WE directly into the XML file:

Code: Select all

<SpaceShip>
  <Track>
    <addPoint>10, 34.2, 45.5</addPoint>
    <addPoint>11, 34.2, 45.5</addPoint>
    <addPoint>1, 34.2, 45.5</addPoint>
  </Track>
</SpaceShip>

[beni]

Hey Paede (Damn if you write an umlaut the whole text is deleted!!)

Thanks for the quick work on that track. Now I can start the actual work on the track. What I did yesterday was mainly to get a idea of what we will need in our track.
When I'm not mistaken we can also go without the TrackElement, because it seems that this class is only for parts between special points like forks, joins or savepoints.
That means, one curve per track is enough.

What I now have to do is make the code compile and then play with the track so I figure out if and how you can regulate the speed on that thing.

[beni]

So far I'm finished with the track .

Nah, not yet ...

I'm finished with most of the implementation. When it compiles now the whole track should get created and everything. The problem which is still there is the duration.
One can set the speed directly over the duration. I'm not sure yet how the track is gone through by the tracknode. That means there is still the testingphase.
Also I think it's stupid to calculate the whole thing from the duration. We should rather calculate the duration from the length of the curve. But that length is not so easy to get.
That's my main concern now.

[bensch]

the idea we started off with was that the track should be able to set the speed itself, so each part of the track has a certain length, and this part is trotted through with a certain speed.
So the conclusion was, that we defined a timeframe for each of these parts, and thus combining the length and the speed. Also it should have been possible to play the sound synchronous with the track

But you are right. It should be possible to make some track-parts get the lenght of each part, and set the speed, rather than the duration, because it is much more enlightening

To get the length of a track, just step through the track with say dT=.05 and take a measure of the distance between the two points before and after the time-step. Add them together and you got the lenght.

Hope this helps, and please do not let yourself be confused by the first remark about why we implemented it that way... it was a long time ago... ages

[beni]

Yah, Patrick told me the same idea last time. Integrate over the curve to get the length. I will certainly do that.

Yesterday I nearly segfaultet my computer when I forgot to create the new Track in the Spaceship before I bound the ship on its tracknode, stupid me.

[beni]

Okay

The track has reached a state which is quite interesting.

Somehow the track is connected with the spaceship. I created a circle as a track and now the whole circle banks with the ship. It's really stupid and absolutely not useable, but at least I know where to search for the error. I'm gonna comment out a few lines in the spaceship to see where I make a mistake. After that the track could work perfectely.

Look forward to that, fellows.

EDIT: Something came to my mind. The structure in the XML-File for the track looks like this:

Code: Select all

    <SpaceShip>
      <name>Player</name>
      <abs-coor>0,0,0</abs-coor>
      <Size>100</Size>
      <playmode>Horizontal</playmode>
      <Track>
        <addPoint>0,0,0</addPoint>
        <addPoint>33,0,40</addPoint>
        <addPoint>66,0,40</addPoint>
        <addPoint>100,0,0</addPoint>
        <addPoint>66,0,-40</addPoint>
        <addPoint>33,0,-40</addPoint>
        <addPoint>0,0,0</addPoint>
      </Track>
    </SpaceShip>

Now simple from the structure in the XML-File one can assume that the track is so much a part of the ship, that when we move the ship, the track will move as well. I know it's probably a stupid idea, but I don't know how the XML-Input works and if the input interpretes the track to be a child of the spaceship Pnode (or whatever) that would explain the problem.
Anyone who can help me with that?

[beni]

New awareness: Drawing the track does not work. the track itself is okay though. By making the tracknode visible one can see that the node follows the "real" track perfectly, even after the drawn track banks and moves with the ship.

So drawing the track does not make much sense anymore. I will now try to stick the ship to the tracknode

EDIT: The spaceship moves now perfectly according to the track. Only problem now is that the direction of the track is not so well defined and the spaceship goes crazy when the track has a curve in it.

Hope I figure out a solution soon.

PS: There is now a possibility to get the length of the track (approximately) and to set the speed in the oxw-file. All of this needs lots of improvements though. Check it out if you're interested and have some time.

[patrick]

yo beni!

this realy is great news! I thought about implementing a whole new track system in the next days (what probably is absolutely impossible), since I didn't get it to run either.

I will check it out now and have a look at it!

thx!!

EDIT: looks good. hmm... is there a problem in the space ship drawing? because it looks very strange and is turned to the wrong side, i think
I guess, the problem at the end of the track is because of the floating (undefined) track end, isn't it?

[beni]

The problem with the spaceship twisting and turning is the not so well defined "direction" of the track. Of course the track goes from A to B and as long as the ship is on the track, that works so far so good. The big problem is not the free end of the track I think. Somehow this doesn't look SO bad.
What worries me more is that the direction of the curve is only given by its derivation. Somehow that does not return the right value and the ship does not know how much it has to turn around its x-axis (the one through the front). That's why the ship acts so strange when the track makes a curve and why the whole ship flies on its head.

I though of some methods for a solution, but none of them seems to cover all problems. I'm afraid we have to extend the tracksystem by a attribute defining some kind of rotation around the track.
I'm happy and open for inputs and suggestions. I'm also happy to answer all your question, because my explenation of the problem may be a bit fuzzy.

[patrick]

How about going dt into the future (something like calc(current time + dt)). This gives you a vector where your ship will be in the next step and therefore where the ship should look at.
From this vector you get you can easily create a quaternion.

Alternatively you get the position at: -dt, 0, +dt and take the mean direction over these three points, giving you some sort of local derivation.

Do you like it?

[beni]

If that vector helps me to create a proper quaternion, that idea would be great. I'll try this. It looks like the easiest way.

[beni]

The vector and the already implemented function calcDir() return approximately the same value. So it comes down to quaternion problem.

Also I figured, that the track should only be able to alter the rotation of the ship's local z and y vector (meaning go up and down and left and right but not turn around the track). So what's missing is a function for the track which receives orders to let the ship rotate around the track.

[bensch]

As I remember it, there was an option called something like banking.
Banking is the rotation around the flight-direction-axis

Somehow I fought with the very same problem when we first implemented the track and maybe you find some "leftovers" in the code.
cheers