4 réponses à ce sujet

[Boozehound Blue]

For my Spelljammer project, I'm trying to update the positions of (in this case) Realmspace celestials OnClientEnter. (I had made some complex calculations with my Realmspace Astrology UI, based on our own solar system; but I want to hopefully simplify and incorporate their unique orbital properties.) My brain is fried on this.

Setup:
28x28 walkable interior area with sun centered (z=10). Celestials painted at module start time 't0' locations, establishing distance from sun "r" (since true scaled distances unworkable)

I'm assuming all orbits are circular, with orbital elements arbitrarily defined (though some some need be derived based on painted location).

So, Orbital Elements:
Eccentricy e0 = 0 (perfectly circular orbits for all, assumed
Semimajor axis a0 = r (derived from painted position as magnitude of vector sun->celestial)
Inclination i0 (derived from painted postion [x,y,z] where sin(i) = z/r
Longitude of Ascending node Ω0 (fixed, arbitrary ?)
Argument of periapsis ω0,= 0 (?)
Mean anomaly at epoch M0 = 0,

How can make the orbital predictions?


(additional source, from which I derived UI calcs)

If I can determine them, then I can determine whether or not they have moved enough to warrant respawmning (or moving) to new location. Additionally, I may need to perform a similar area heartbeat calc for faster moving objects, since a heartbeat may advance time by 1 day+.

Modifié par Boozehound Blue, 22 octobre 2010 - 07:59 .

[Boozehound Blue]

This might be one of those times where just writing about the problem helps solve it; but I'm no astrophysicist...

from here:
(Mercury's orbital elements)
    N =  48.3313 + 3.24587E-5 * d
    i = 7.0047 + 5.00E-8 * d
    w =  29.1241 + 1.01444E-5 * d
    a = 0.387098  (AU)
    e = 0.205635 + 5.59E-10 * d
    M = 168.6562 + 4.0923344368 * d

If I wanted to simpify this to represent Anadia:
(constants arbitrary)
    N =  48.3313
    i = 7.0047
    w =  0
    a = 0.5  (AU) //relative to Toril
    e = 0
    M = 168.6562 + 2*π*d/T, where T is orbital period = 30 days, so
    M = 168.6562 + 0.20952380952*d

I can plug these numbers into my already NWscript-converted equations, solve for heliocentric coordinates, and adjust to area coordinates by adding them to the sun's area position (something like 160,160,0) That should do it, right? (Satellites would be found relative their parent's position.)

If I can accomplish that, the next problem is accessing the celestials. Since the celestials may not lie on the walkable plane (being above or below the elevated walkmesh helper), I need to be able to trigger a conversation when the ship gets as close as it can. I assume I can spawn a speaktrigger under/over celestials out of plane and that the ship will pathfind into it should the player click on that celestial from afar. Is this possible? (Perhaps I could have an OnLeftClick script that moves the ship to the trigger location instead?)

If that's not possible, then I can either 1) have no inclinations, assuring the ship can walk up to every celestial (and trigger an OnUsed convo), which would make the system look pretty flat; 2) have a universal orbital plane which is inclined, in conjunction with an inclined walkmesh to give the illusion of depth while still allowing direct access; or 3) create and exterior area with a complex walkmesh that allows access to every celestial, no matter the z position- requiring a heightmap both hard to make and smoothly navigate. (These are not scripting problems, I know.)
 

Modifié par Boozehound Blue, 23 octobre 2010 - 01:03 .

[rjshae]

You should be able to use Kepler's third law to determine the period. From there, if the orbits are simple circles on a flat plane, all you need to care about is the position along the orbit at a given starting point. I believe this is your mean anomaly at the given epoch. From there, determining the current orbital position should be pretty straight forward. Just take the time elapsed and divide by the period; mod it; then treat the remainder as the fraction of a complete orbit from the starting point at the epoch for that planet.

I wouldn't mess with more complex orbits; that's probably too much work for your purposes.

Modifié par rjshae, 25 octobre 2010 - 04:00 .

[Boozehound Blue]

For a circular orbit, M = v = E, so the position of the celestial simplifies from:

   //Eccentricity
    E = Iterate( M, e);
    //Distance r and true anomaly v
    xv = a * ( cos(E) - e );
    yv = a * ( sqrt(1.0 - e*e) * sin(E) );
    v = atan2( yv, xv );
    r = sqrt( xv*xv + yv*yv );   //(AU)
    //Heliocentric position in 3-dimensional space:
    xh = r * ( cos(N) * cos(v+w) - sin(N) * sin(v+w) * cos(i) );
    yh = r * ( sin(N) * cos(v+w) + cos(N) * sin(v+w) * cos(i) );
    zh = r * ( sin(v+w) * sin(i) );

to:
    v = M;
    //parent-centric position in 3-dimensional space:
    float x = a * ( cos(N) * cos(v) - sin(N) * sin(v) * cos(i) );
    float y = a * ( sin(N) * cos(v) + cos(N) * sin(v) * cos(i) );
    float z = a * ( sin(v) * sin(i) );

    return Vector(vParent.x+x,vParent.y+y,vParent.z+z);

where vector vParent is the parent celestial's position (Sun, or Toril if calculating Selune, etc.) I think this is correct, from what I've read.

Mepoch (M0), corresponding to v0, is basically the angle between the ascending node and the celestial's painted postion (diagram), which is:
M0 = N + VectorToAngle(vector vPosition), limited to <360 degrees.
I think.

Of course, it's improbable that the celestials will be painted in such a way that their positions gel perfectly with their orbital elements, therefore 'a' must be derived and the initial z position must be adjusted via an initialization process (or  i  will need to be derived to fit z):
   z = a * ( sin(v) * sin(i) );
  or
   i = asin(z/(a*sin(v)); //where v = M0

This is an arduous process, but I'm imagining being able to 'easily' set up a realm with some plot-critical alignment in the toolset, tied to some arbitrary future time (Mepoch) from module start, and have the celestial 'rewind' their orbits through initialization so that they may approach this epoch event as the ship goes about its travels. Mostly, though, this is about having a dynamic solar system that's easily constructed and obeys some rules.

Another thing I'm trying to work out is setting the facing of non-spherical objects that orbit a parent , such as the Tears of Selune (which orbit Toril, not Selune)- a boulder pile placeable:
   fFacing = iFacing+ (fAngleNew - fAngleOld);
  where fAngles = GetAngleBetweenObjects(oParent, oCelestial) before and after movements.

[rjshae]

You will, of course, need to compensate for the travel time between the orbits. The planet will have moved by the time you get there. Good luck.