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"; 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:
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";
};
}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:
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";
*****
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.
