QDirection()
#1
Posted 04 January 2019 - 07:29 PM
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?
#2
Posted 05 January 2019 - 03:31 AM
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.
#3
Posted 05 January 2019 - 06:36 AM
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
#4
Posted 05 January 2019 - 10:38 AM
#5
Posted 06 January 2019 - 06:50 AM
Genma Saotome, on 04 January 2019 - 07:29 PM, said:
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.
#6
Posted 06 January 2019 - 10:31 AM
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.
#7
Posted 11 January 2019 - 04:48 PM
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
#8
Posted 12 January 2019 - 10:19 AM
Genma Saotome, on 11 January 2019 - 04:48 PM, said:
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?
#9
Posted 12 January 2019 - 11:00 AM
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.
#10
Posted 12 January 2019 - 01:11 PM
Genma Saotome, on 12 January 2019 - 11:00 AM, said:
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'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?