[Genma Saotome]

A question of curiosity: Why did KUJU use QDirection() as defined instead of

Pitch ( {sign}nnn.nnnn UnitOfMeasureCode ) <<relative to level>>
Direction ( [sign]nnn.nnnnn ) <<relative to north>>

The later accomplishes exactly the same result, offers a bit more flexibility to the route developer by allowing him to do the pitch in a unit he is familiar with and is much easier to understand and edit values.

Has there ever been a need for yaw?

Is there any reason why a future world file should not use the later structure?

[Goku]

The thing you propose is called Euler Angles rotation and the angles are usually called pitch, roll and yaw. Roll is not used for tracks, but for scenery objects it is sometimes useful.
QDirection is a different type of representing rotations - Quaternions. They are superior to euler angles, avoiding gimbal lock, having much better performance and allowing for features that are not possible or extremely difficult using euler angles - animations for example. There is no interactive 3d world without quaternions.

Here you can read article from 1998y about then.
http://www.gamasutra...quaternions.php

Storing pitch, roll and yaw would be useful for track editing. TSRE stores these values until you quit the app. It allows to remember the original placemet point of reversed track. But anyway it must be always converted to quaternion.

[dennisat]

Hi,

Apparently, standard 3D matrices can produce undefined / discontinuous results for some rotation combinations. Quarternion methods avoid this so called "Gimbal Lock" in simulations as well as engineering. Engineering also requires suitable mechanisms as well, of course.

Search Wikipedia for "gimbal lock Apollo 11". This probably won't assist the understanding of Quarternions very much but is interesting in that Gimbal Lock caused the Apollo 11 guidance system to seize repeatedly on the last few hundred feet of descent to the moon. Listening to the crew's conversation on the descent you can hear them reporting computer guidance errors several times.

Dennis

[Genma Saotome]

Thanks, that's all very interspersing. Hearing that TSRE does the translation from one to the other suggests OR could do the same thing when the loader reads the world files but perhaps seeing/editing the Euler values in TSRE is enough.

[James Ross]

Genma Saotome, on 04 January 2019 - 07:29 PM, said:

Is there any reason why a future world file should not use the later structure?

As mentioned, using the QDirection / quaternion storage is strictly better than using Euler angles, in terms of correctness and functionality, so that's what the game will use.

However, editors could convert most quaternions into Euler angles for display and editing, and we might provide a means of storing them in scenery placement file format to make this easier.

[Genma Saotome]

I'm sure mow that the argument for using quaternion data for game processing is unimpeachable. My remaining question is whether the use of Euler numbers is feasible and if yes where the conversion from Euler data to quaternion occurs. The world file requires but that requirement need not apply to a replacement file.

IMO being able to see and set Euler values in real numbers is greatly advantageous to the route builder (both in an editor and in the file holding the saved data) as you can understand what the Euler numbers mean whereas quaternion values are not so readily apparent (if at all). Perhaps a conversion in the loader thread?

Please give some consideration to this matter when defining the replacement to the world file.

[Genma Saotome]

Another question:: are there multiple ways to come up with a Quaternion value based on the placement of an object in 3d space and what will appear in one of our world files?

I ask as I have seen several instances of Quaternion values in the the QDirection() field created by TSRE which are not accepted as valid in both KUJU's RE and the Object Rotater spreadsheet. For example, teh two lines I have at the end of this post.

Not being too sharp in higher maths I probably won't understand in the ins and outs of what's going on... I really just need to know what the angle is between these crossing lines and a layman-level explanation for why these numbers work on OR and not RE or the spreadsheet.

Position ( 312.658 68.4491 299.154 )
QDirection ( -0.00322149 -0.175969 -0.000575871 -0.98439 ) <-- aimed southwest

Position ( 386.533 69.7221 698.132 )
QDirection ( -0.00047883 -0.969808 -0.00190423 -0.243864 ) <-- aimed northeast

[James Ross]

Genma Saotome, on 11 January 2019 - 04:48 PM, said:

Another question:: are there multiple ways to come up with a Quaternion value based on the placement of an object in 3d space and what will appear in one of our world files?

I ask as I have seen several instances of Quaternion values in the the QDirection() field created by TSRE which are not accepted as valid in both KUJU's RE and the Object Rotater spreadsheet. For example, teh two lines I have at the end of this post.

Not being too sharp in higher maths I probably won't understand in the ins and outs of what's going on... I really just need to know what the angle is between these crossing lines and a layman-level explanation for why these numbers work on OR and not RE or the spreadsheet.

Position ( 312.658 68.4491 299.154 )
QDirection ( -0.00322149 -0.175969 -0.000575871 -0.98439 ) <-- aimed southwest

Position ( 386.533 69.7221 698.132 )
QDirection ( -0.00047883 -0.969808 -0.00190423 -0.243864 ) <-- aimed northeast

My understanding is that there is only one quaternion <-> Euler angle mapping outside of gimbal lock, and I found a page that'll do it for you - http://quat.zachbennett.com/ - you'll need to put the 4th QDirection value into q1, and shuffle the other three along, to get the right answer as this website uses WXYZ order and MSTS uses XYZW order.

If my reading of the Wikipedia pages on quaternions and the OR code are correct, the first three values of QDirection form a vector in 3D space about which the rotation is performed. The fourth value is the angle of rotation. The four values are normalised so that they represent a unit vector in 4D space.

I don't know why MSTS RE or Object Rotater wouldn't accept them, as there doesn't look to be anything wrong with those QDirection values, although they don't seem to be particular southwest and northeast to me; putting them into the website above, I get:

• 0, 20, 0
  
• 0, 152, 0

The angle between these two is only 132 degrees, with 20 in the 1st quadrant and 152 in the 2nd quadrant. I couldn't tell you which way that was rotating in MSTS without more work, but do those numbers make sense to you?

[Genma Saotome]

Ooops, my verbal directions were pasted tot he wrong lines.... SORRY!!

Both objects are switches. Positioning the camera as close to the points as I can get to look along the tangent to the far end of the shape I see the first shape is a couple of degrees west of north, call it -3 to -5. I thought it was angles a bit more to the right.... The other one is aimed SW and that looks to be pointing about 220d on the compass display, so call it -140.

I'm actually rather concerned about the fact that neither of those qdirection() values work in the spreadsheet. I use the spreadsheet regularly... from calculating the direction between two points on a line (I use some push pin shapes for this), calculating offsets along a specific direction (to place multiple buildings at exact locations, right down to sharing a common wall), figuring out what the degrees of curvature are needed for the third leg of a wye, figuring out the angle of descent for anything over a 500m run, and so on. TSRE has reduced my need for it in many cases, a simple rotate 90d for instance, but there are still matters where it is the only tool to obtain the correct solution.

[James Ross]

Genma Saotome, on 12 January 2019 - 11:00 AM, said:

Ooops, my verbal directions were pasted tot he wrong lines.... SORRY!!

Both objects are switches. Positioning the camera as close to the points as I can get to look along the tangent to the far end of the shape I see the first shape is a couple of degrees west of north, call it -3 to -5. I thought it was angles a bit more to the right.... The other one is aimed SW and that looks to be pointing about 220d on the compass display, so call it -140. The angle between the two should be between ~135, give or take a few.

No worries at all, I'm glad the numbers seem to match up in the end!

Genma Saotome, on 12 January 2019 - 11:00 AM, said:

I'm actually rather concerned about the fact that neither of those qdirection() values work in the spreadsheet. I use the spreadsheet regularly... from calculating the direction between two points on a line (I use some push pin shapes for this), calculating offsets along a specific direction (to place multiple buildings at exact locations, right down to sharing a common wall), figuring out what the degrees of curvature are needed for the third leg of a wye, figuring out the angle of descent for anything over a 500m run, and so on. TSRE has reduced my need for it in many cases, a simple rotate 90d for instance, but there are still matters where it is the only tool to obtain the correct solution.

I've downloaded and set up Object Rotator 2. I'm getting the following:

https://james-ross.co.uk/temp/orts_163.png

https://james-ross.co.uk/temp/orts_164.png

I don't know if the bank=180 is right or not, but the heading looks correct (it's negative what the website I found gives, but MSTS often has things with the opposite sign to "normal"). What are you seeing and how is it incorrect?