Reference frames

[Malenfant]

It's still a darn sight more complicated than what we're doing now though. Will there be a 'dumb orbit' option whereby we don't have to enter all the extra stuff? If we don't include the frame definitiosn etc, does it default to anything or will it just not rendered at all?

And what is we're trying to do a fictional planet around another star? What reference or Epoch are we supposed to use? Before, we could just define its elliptical orbit and leave it at that - but with this new code we also have to puzzle about reference frames, custom orbits, and epochs. I just don't think it should be required for everything.

Basically, I don't mind all this if it's optional. If it's required for everything now though, it's a major pain.

[chris]

It's still a darn sight more complicated than what we're doing now though. Will there be a 'dumb orbit' option whereby we don't have to enter all the extra stuff? If we don't include the frame definitiosn etc, does it default to anything or will it just not rendered at all?

And what is we're trying to do a fictional planet around another star? What reference or Epoch are we supposed to use? Before, we could just define its elliptical orbit and leave it at that - but with this new code we also have to puzzle about reference frames, custom orbits, and epochs. I just don't think it should be required for everything.

Basically, I don't mind all this if it's optional. If it's required for everything now though, it's a major pain.

It's all optional. All of the systems that you've created to date will work just as before in 1.5.0.

I should also have made it clear exactly what was different in my barycentric Pluto definition. The CustomOrbit has always been there in Pluto definition in solarsys.ssc. I defined the object "Pluto-Charon" an an object of type Center--this is really just the same as making an object of class invisible, but it's a little bit easier to understand.

The other difference is this:

Code: Select all

OrbitFrame
{
        EclipticJ2000 { Center "Sol/Pluto-Charon" }
}


I could instead just make Pluto a child object of Pluto-Charon, but that has the disadvantages I listed in my last post.

So, for comparison, here's the old way of doing things. You can see that there's not much difference:

Code: Select all

"Pluto-Charon" "Sol"
{
    Class "invisible"
    CustomOrbit "pluto"
}

"Pluto" "Sol/Pluto-Charon"
{
    EllipticalOrbit
    {
        ...
    }
}


Again, the above definition will still work in 1.4.1, but I use the new form in 1.5.0 because I don't want to change the full name of Pluto from Sol/Pluto to Sol/Pluto-Charon/Pluto and break a bunch of scripts.

--Chris

[Cham]

I'm pretty sure there's a simpler way of doing all this. I don't see what, yet, and I'll think about it. We should be able to find a way to define parameters in the same style as the nice old easy way, something like this :

Code: Select all

Function1
{
       parameters
}

Function2
{
       parameters
}

etc...


without introducing more {} inside each functions, like this :

Code: Select all

Function1
{
   function1B
    {
           parameters
     }
}

Function2
{
   function2B
    {
            function2C
            {
             parameters
             }
     }
}



this is becoming pretty insane !

[t00fri]

Frames and the transformations between them are part of my daily professional "bread and butter", except my frames are way more complex than the frames Celestia is concerned with .

It's great to see Chris work with so much energy on this important issue....yet, had some experts like myself been consulted BEFORE the coding took place, most probably, we would have JOINTLY arrived at a more convincing viz transparent implementation...

Since usually, Chris communicates AFTER he has written the code, I lost active interest in the frame issue already quite some time ago.

Cheers,
Fridger

[Malenfant]

Since usually, Chris communicates AFTER he has written the code, I lost active interest in the frame issue already quite some time ago.

Since you know so much about it then, why not offer some useful input to help instead of sitting on the sidelines? It doesn't matter when Chris discusses things with people, I can't imagine him turning down any assistance or input.

[t00fri]

Since usually, Chris communicates AFTER he has written the code, I lost active interest in the frame issue already quite some time ago.

Since you know so much about it then, why not offer some useful input to help instead of sitting on the sidelines? It doesn't matter when Chris discusses things with people, I can't imagine him turning down any assistance or input.

Well,

one reason is certainly that I am insainly busy & travelling etc these days. You surely noticed my extended absence from the forum.

Since Chris seems to prefer this way of development to what I consider 'teamwork among experts', it is fine with me, given my other stringent boundary conditions...

[chris]

Since Chris seems to prefer this way of development to what I consider 'teamwork among experts', it is fine with me, given my other stringent boundary conditions...

The whole point of this thread was to encourage teamwork in the development of the frames feature. I would welcome your comments, suggestions, and code--I'd assumed that your silence was due to lack of interest. If you'd prefer to handle it on the dev list, that's fine, but I also think that this forum topic is important for Celestia add-on creators. Even though code has already been written, the implementation can change if there's a better way to do things.

--Chris

[ajtribick]

From the point of view of adding binary stars and other such objects (e.g. exoplanets for which inclinations are known), it would be handy to have a skyplane (as viewed from Earth) reference frame available.

[buggs_moran]

I know I am probably not reading all this through like I should be, but when I use FixedPosition [ 1821.6 X Y], what are X and Y measured in. I know they aren't Long and Lat, but how do I define an object's position on a moon using this? 1821.6 is the moon's radius, and I know what long and lat I need...
-----------------------------------------------------------------------
Edit: Okay, now I understand that I have to convert to XYZ from lat long info. I am using...

x = (radius)cos(lat)cos(lon)
y = (radius)cos(lat)sin(lon)
z = (radius)sin(lat)

but I come up short of the location I am shooting for by a couple hundred kilometers...
-----------------------------------------------------------------------
Edit: DUH, radians...

All set.