Something doesn't make sense...

[Chuft-Captain]

Here's the orbit definition for Io from solarsys.ssc:

Code: Select all

   CustomOrbit "io"

   # Overridden by CustomOrbit
   # EllipticalOrbit
   # {
   #    Epoch 2443000.00038375
   #    Period         1.769138
   #    SemiMajorAxis  421600
   #    Eccentricity   0.0041
   #    Inclination    0.040
   #    AscendingNode    312.981
   #    LongOfPericenter  97.735
   #    MeanLongitude    106.724
   # }

Now, to my way of thinking, I would expect that the CustomOrbit overriding the older EllipticalOrbit definition should place Io in a similar (if more accurate) position to the older definition.

Therefore, if I create a test object and give it the old Io orbit defiition:

Code: Select all

    EllipticalOrbit
    {
       Epoch 2443000.00038375
       Period         1.769138
       SemiMajorAxis  421600
       Eccentricity   0.0041
       Inclination    0.040
       AscendingNode    312.981
       LongOfPericenter  97.735
       MeanLongitude    106.724
    }

then I would expect it's orbit (if not it's position in the orbit) to be quite similar to that of Io.

I can understand that it's position in the orbit may be considerably advanced or degraded from Io's CustomOrbit position, however what I find that it's (the test object) orbit is also considerably inclined to Io's orbit (something like 30 degrees).

Can anyone explain what's going on here?
Surely the inclination of Io's orbit won't have changed through the use of a CustomOrbit rather than EllipticalOrbit definition?

A similar thing happens if I go through the same exercise with Earth's Moon... what is causing this difference in inclination?

Cheers
CC

[selden]

I can only think that you've made a typo somewhere.

I created a separate test_object.ssc using the commented-out parameters from solarsys.ssc

Code: Select all

"test_object" "Sol/Jupiter"
{
   Radius   1821.6
   Color [ 1 1 0]

    EllipticalOrbit
    {
       Epoch 2443000.00038375
       Period         1.769138
       SemiMajorAxis  421600
       Eccentricity   0.0041
       Inclination    0.040
       AscendingNode    312.981
       LongOfPericenter  97.735
       MeanLongitude    106.724
    }

   BodyFrame { EquatorJ2000 {} }

    UniformRotation
    {
       Inclination    25.50
       AscendingNode 358.05
       MeridianAngle 200.39
    }

   Albedo         0.61
}


Then, for this url:
view io and test_object
Celestia drew this:

test_object.jpg

These two orbits look reasonably close to me. There's certainly no 30 degree tilt.

[John Van Vliet]

--- edit ---

[PlutonianEmpire]

Yeah, this is precisely why ReferenceFrames can be so irritating to work with in Celestia. Hardly anything goes right when working with them.

urhgaaugh.png

This pretty much sums it all up with ReferenceFrames.

[Chuft-Captain]

I can only think that you've made a typo somewhere.
...
These two orbits look reasonably close to me. There's certainly no 30 degree tilt.

Thanks for replicating this. It's useful to know that it worked for you, and examining the differences between your implementation and mine, enabled me to isolate the cause...

The only difference is that I had the following statement as well:

Code: Select all

   OrbitFrame {
      EquatorJ2000 { Center "Sol/Jupiter" }
   }

(Add this to your code if you want tol see what was happening for me.)
Why this causes a problem, I wish I understood , but commenting it out does solve the problem.

that "tilt" sounds like an error with

BodyFrame { EclipticJ2000
vs.
BodyFrame { EquatorJ2000

issue

I know what you're getting at John, but only in the context of an OrbitFrame statement. Your example uses a BodyFrame which affects the Orientation of the object itself, rather than it's orbit.

Thanks guys.
CC

[PlutonianEmpire]

The only difference is that I had the following statement as well:

Code: Select all

   OrbitFrame {
      EquatorJ2000 { Center "Sol/Jupiter" }
   }

(Add this to your code if you want tol see what was happening for me.)
Why this causes a problem, I wish I understood , but commenting it out does solve the problem.

Using the "EquatorJ2000" frame simply causes an object's orbit or orientation to be locked to the Earth's equatorial plane as it was on January 1, 2000, regardless of what body it orbits.