Re: [Celestia-developers] reference frames broken in current cvs
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Chris L. <cl...@gm...> - 2006-10-31 19:35:09
|
On 10/31/06, Selden E Ball Jr <se...@le...> wrote: > Chris, > > > Sorry, I neglected to comment on the first question: > > > I'm really not sure what to do about this . . . Should the parent of > > an object determine which units to use? Or should the center of the > > reference frame? Either scheme is easy to implement. > > It seems to me that the FixedPosition statement should use the units > appropriate to block that the statement is in. > > For example > in > "Earth L4" "Sol" { ... FixedPosition [n n n] ... } > the units should be AU relative to Sol. > > while in > "Moon L4" "Sol/Earth" { ... FixedPosition [n n n] ... } > the units should be in km relative to the Earth. I agree. I'll ignore the reference frame center and just choose the units based on the parent object. The choice of units will apply to all sub-blocks: FixedPosition, EllipticalOrbit, UniformRotation, etc. > The following comments assume that I'm understanding > how the OrbitFrame and BodyFrame statements are intended > to be used. I'm not at all sure that I am. > > Tt seems to me that when using OrbitFrame (or BodyFrame) > and their sub-options to define the object's coordinate system, > the FixedPosltion statement really should be inside the > Primary block using units appropriate to the Target. > That would seem to make it unambiguous, at least to me. I don't think I've explained reference frames well enough . . . OrbitFrame defines the coordinate system for the orbit. FixedPosition is just another orbit type, like EllipticalOrbit, CustomOrbit, and SampledOrbit. Thus, FixedPosition doesn't belong inside the orbit frame. I'll admit that the terminology is a little confusing--an object with a fixed position doesn't really have a proper orbit. In Celestia, 'orbit' actually means any function that converts time to a position; a FixedPosition is just a constant function. The BodyFrame defines the coordinate system for the orientation of an object. It can be he same as the coordinate system for the orbit, but it doesn't have to be. The example ssc definition that I posted to the forum with the space shuttle in a local attitude frame demonstrates one situation where you want a body frame that differs from the orbit frame. > I'm not at all sure what the equivalent construct should be > (if any) for the Secondary block. Would a FixedVector declaration > make any sense? I think that you've misunderstood what the secondary block does. A coordinate system has three orthogonal axes and a center point. Celestia only uses right-handed coordinate systems. The requirement that the coordinate system be right-handed means that the three axes can be determined by two non-collinear vectors, thus the TwoVector reference frame in Celestia. The primary axis will point exactly in the direction of the primary vector. The secondary axis will not necessarily be parallel to the secondary vector, because the axes of the coordinate system need to be orthogonal to each other. The third axis is just the cross product of the primary and secondary axes. I'll try to make a diagram that shows the relationship between the primary and secondary vectors and the axes of the coordinate system that they define. The SPICE frames required reading document has an ASCII diagram of a two-vector coordinate system that might be helpful. It's clear to me that reference frames are going to require some detailed documentation. --Chris |