the orientation-key in planetinfo.plist

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

Post Reply
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

the orientation-key in planetinfo.plist

Post by Commander McLane »

This is going to be a lengthy post.

While scripting some new planets and trying to make them look nicely I noticed that the orientation-key in planetinfo.plist does not work as I would have expected it to do. I say it's broken. And it appears to be broken for a long time, perhaps never worked correctly.

What's the issue?

If you create your own, private planet, you have to define it and set it up in planetinfo.plist. In the definition-part you can alter its appearance in pretty many ways, in the set-up part you call it into being, together with setting other parameters for the system.

Two basic settings for a planet are its position and its orientation. The position is definied by the position-key. Looks like this:

Code: Select all

        position = "0 -5000000 0"

The example is taken from tianve.oxp, where the famous Tianve Pulsar is pretty far away. The co-ordinates are given according to the internal co-ordinate system, not according to any of the wpm and the like. In all cases I tested the internal co-ordinate system was similar to a minus wpm, meaning that the origin seems to be close to the witchpoint, and the z-axis runs away from the planet. Note, however, that this is not exactly so. The origin is only somewhere close to the witchpoint, and the z-axis appears to not pointing directly away from the planet, but there is a certain angle to it, that may vary from system to system.

The orientation-key looks like this:

Code: Select all

        orientation = "1.0 1.0 0.0 0.0"; 
The example is again taken from tianve.oxp. The four values represent a quaternion, which defines a rotation.

What do I suppose it to do?

I suppose the orientation-key to define the planet's orientation in space, or, in other words, the direction into which the planet's axis is pointed. So with different quaternions I could make its north pole face to the sun, or away from the sun, or in a certain angle to the witchpoint, or in a 90-degree angle to the sun-planet-witchpoint plane in order to always see its equator, or whatever. I hope you get the idea. And of course I suppose the planet, if I give it a spin, to turn around its axis which I previously have defined.

Furthermore I expect the planet's texture to be wrapped around it from the north pole to the south pole, meaning the top border of my texture should be at the north pole, the bottom border at the south pole, and the left and right borders should meet at the date line, so to speak. Pretty much as I'm used to from the way a plain global map represents the globe. Wouldn't you expect the same?

Problem is: None of this is actually the case in Oolite!

In order to show this I have written a small OXP (actually modifying tianve.oxp). Here are its ingredients:

First a texture for the planet. I have drawn a grid, in order to show how a texture is wrapped around a planet. Drag the image to your desktop in order to save it on your computer:
Image
I would expect fields 1-4 to be the north polar region, fields 13-16 to be the south polar region and the line between 5-8 and 9-12 to be the equator of my planet.

Then we need the planetinfo.plist. It contains four copies of the same planet, conveniently placed close to each other, only differing in orientation. And I took four very basic orientations for that purpose, namely no rotation for the first moon, and rotations by 90 degrees around each of the axis for the following three:

Code: Select all

{
    "2 239" = {
        "script_actions" = (
            "addMoon: gridmoon1", 
            "addMoon: gridmoon2", 
            "addMoon: gridmoon3", 
            "addMoon: gridmoon4"
        ); 
    }; 
    gridmoon1 = {
        orientation = "1.0 0.0 0.0 0.0"; 
        "polar_color_factor" = "0.2"; 
        position = "0 -50000 0"; 
        radius = 500; 
        "rotational_velocity" = 6; 
        seed = "1 2 3 4 5 6"; 
        texture = "grid.png"; 
    }; 
    gridmoon2 = {
        orientation = "1.0 1.0 0.0 0.0"; 
        "polar_color_factor" = "0.2"; 
        position = "0 -100000 0"; 
        radius = 500; 
        "rotational_velocity" = 6; 
        seed = "1 2 3 4 5 6"; 
        texture = "grid.png"; 
    }; 
    gridmoon3 = {
        orientation = "1.0 0.0 1.0 0.0"; 
        "polar_color_factor" = "0.2"; 
        position = "0 50000 0"; 
        radius = 500; 
        "rotational_velocity" = 6; 
        seed = "1 2 3 4 5 6"; 
        texture = "grid.png"; 
    }; 
    gridmoon4 = {
        orientation = "1.0 0.0 0.0 1.0"; 
        "polar_color_factor" = "0.2"; 
        position = "0 100000 0"; 
        radius = 500; 
        "rotational_velocity" = 6; 
        seed = "1 2 3 4 5 6"; 
        texture = "grid.png"; 
    }; 
}
Note: The two numbers in the top line specify the galaxy and the system where the four new planets shall appear. I've taken the numbers of the place where my testpilot happens to be at the time. Lave would be specified by "0 7", being system number seven in galaxy number zero.

Now here's what I saw when I was there, close to the witchpoint. First the view out of my right window, showing planets (or moons) 1 and 2, then the view from my left window showing planets 3 and 4:
Image

Image

I have marked the rotational axis of all of the planets (either the south or the north pole, depending on which is visible from my position) with an "x". And the axis of all the planets, their north and south poles are all perfectly in line. No change of the rotational axis at all. They all happen to rotate around the y-axis of the internal co-ordinate system. And this behaviour never changes, no matter what the script says.

The only thing that does change and therefore is influenced by the orientation-key is the way the texture is wrapped around the planet. Here we may be able to see changes of 90 degrees from one planet to the next, but it's hard to determine, because the rotational axis in none of the cases goes from the top border to the bottom border of the texture. In none of the cases the line I meant to be the equator actually is located at the equator. All planets are spinning at funny angles, as far as their texture is concerned.

And this makes is completely unpredictable for a scripter how the texture he chose for his planet actually will look on it. If you would take a texture of the Earth (e.g. from Celestia) and use it to texture a planet in Oolite, this planet would spin in a way the Earth never does.

As it is now, there is only one single entry for the orientation-key that at least makes a texture cover its planet from north to south and keeps the equator as it is meant in the texture. It represents a turn by roughly 16 degrees around the x-axis. It's still a little bit off, but for the time being it's as close as I could get.

Code: Select all

        orientation = "0.9613 0.2756 0.0 0.0"; 
If you want your planet-texture to cover it exactly from north pole to south pole you have to choose these values. But you cannot stop it from rotating only around the system-internal y-axis.

*****

The bottom line (and the reason for this post to be in this section) is that I request the coders to have a look into the way extra planets are created and especially their orientation in space.

I still think the original intention of the orientation-key was to allow to turn the actual axis of the planet, not the texture only.

And sorry if this was a bit exhausting. :wink:
ilnar
Above Average
Above Average
Posts: 21
Joined: Wed Oct 03, 2007 10:34 pm

Post by ilnar »

:D
i noticed that,,,,,
was atemping to script an orbital moon station thingy, like a rock hermit only bigger and rotating,

sincee you cant change the angle of rotation it means the docking bay is always in the same place, on multiple moons, a bit boring realy,,, i want several to spin all in different direction and orbits :D
User avatar
nijineko
---- E L I T E ----
---- E L I T E ----
Posts: 353
Joined: Wed Jul 04, 2007 3:37 pm
Location: two strange quarks short of a graviton....
Contact:

Post by nijineko »

i agree. when i get around to making custom solar system objects, i want control over the rotation and the axial angle of inclination.
arukibito ga michi wo erabu no ka, michi ga arukibito wo erabu no deshou ka?

Image
Play games. Win Amazon gift cards! Brag. Repeat.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

I have a basic fix for this (took about ten minutes… a detailed bug analysis is very helpful). However, it results in a fixed offset (looks like more than 16 degrees) for reasons that aren’t clear.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane »

Ahruman wrote:
it results in a fixed offset (looks like more than 16 degrees)
Probably it's something like 32 degrees? When I posted the description I forgot that quaternions are calculated as

Code: Select all

W = cosine( 0.5 * a )
X = x * sine( 0.5 * a )
Y = y * sine( 0.5 * a )
Z = z * sine( 0.5 * a )
So the actual angle is double the degrees I took the sine and cosine of.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Yeah, that looks about right. Wonder where it’s coming from.
User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

Post by Hoopy »

argh! I went to wikipedia to read about quartenions and got sidetracked into reading about tensors and general relativity! How am I going to get any oolite playing/work done now!

:)
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

Its a long standing bug, but it is solved with to-days trunk Revision 2923.

Like all good things (like wine) it takes a while before things are ready for use. Planets are now always rotating around their vectorUp as rotation axis. When changing the orientation by JS script, the orientation axis of planets is also changed with the new orientation.

I made a variation of mcLanes test oxp: Planet rotation tester. This tester adds four mini planets near the witchpoint, each with a different orientation. 3 of them have a w-buoy placed near them for easier finding.

Actually I tried to fix it already half a year ago but failed. Now the new planet code adds visible poles on the main planet I looked again at the rotation code. Yesterday I suddenly noticed what had to be changed.

Additional info:
The main planet always has an orientation in space, in a way that the equator is oriented towards the sun. This has always been this way with old Oolite versions at the initialisation of the system, but rotation was never around the poles. Maybe an oxp like orbits should make use of this and also copy the mainPlanet orientation to all its planets that are repositioned?
Last edited by Eric Walch on Fri Jan 01, 2010 11:58 am, edited 1 time in total.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Actually, Eric, the problem you fixed is completely unrelated to the one McLane had. It still needed fixing, though. ;-)

(The original problem is that the old planet model simply doesn’t have a vertex at the pole, and the “texture pole” was instead a vertex off to the side. Oh, and the angle McLane was looking for was tan⁻¹ 1/τ ≈ 31.7175°, where τ is the golden ratio – see Wikipedia on the construction of a regular icosahedron. The new problem was that the new planets were rotated a less confusing 90°.)
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Glad to see that both problems are resolved in trunk now.
Thanks Eric, nice work on fixing them! ;)
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
Post Reply