Celestia Forums

Despite the few example in the wiki, seems I'm too brain-dead! A ssc using a body fixed def seems to be broken with the latest version. SO as we do need some example, what about this one? (Once clear, we could add it to the wiki)

3 objects, A, B and C.
A will have the main orbital definition and receive (via modify ?) a body frame with two vectors for orientation.
B and C must be locked and positioned in reference to A.
A, B and C form a single object.

What would be the correct optimized ssc?

ElChristou wrote:Despite the few example in the wiki, seems I'm too brain-dead! A ssc using a body fixed def seems to be broken with the latest version. SO as we do need some example, what about this one? (Once clear, we could add it to the wiki)

3 objects, A, B and C.
A will have the main orbital definition and receive (via modify ?) a body frame with two vectors for orientation.
B and C must be locked and positioned in reference to A.
A, B and C form a single object. What would be the correct optimized ssc?

It depends on exactly what you're trying to accomplish.

I find that frames are easier to understand if I do not try to optimize them. For example, I often use frame definitions which are separate from the model definitions. I place the models at a fixed position and orientation relative to the desired frames.

For an example, you might take a look at my SiderealClock Addon. The clock's body is oriented relative to its position on the Earth. The hands are oriented relative to the clock.
viewtopic.php?f=6&t=12471

The example here would be in the optic to tweak only A (changing orbits or reference) and B and C would "follow" without more editing in their own def, preserving their initial position in relation to A...

Edit: Just tested your clock and it's pretty cool! It deserve some kind of nice scenery; if you agree I could think in something!

That's exactly what is done in my SiderealClock Addon if you replace the ScriptedRotation declarations by FixedRotation.

Ok, here is a ssc that place correctly 3 bodies with one as ref (this is the case of Apollo CSM + LEM; the CSM model is in two part to avoid some seams):



Now, the idea for example is to rotate the whole construction editing only the def of the CSM... How to do that?

First, delete
RotationPeriod 1e9
It interferes with the UniformRotation definition.

Then, edit
UniformRotation
{
Period 20
}
to do the rotation you want,
or replace it with an appropriate
ScriptedRotation {...}

or

Introduce an intermediate object with its coordinate system referenced to that of the CSM and referenced by the other objects. Edit the intermediate object's rotation as desired.

Hmm... yep, but I was thinking in a rotation of the whole construction of a few degrees in relation to the ref (in this case the moon). In the present ssc the construction is perpendicular to the moon diameter. With a single model, one could use the orientation def, but with the present case the childrens won't follow the parent...

(BTW, have you seen my edit a few post above? )

The "children" follow whatever objects are specified in their own two OrbitFrame and BodyFrame definItions. Those two reference objects do not have to be the "parent" specified in the names of the "children" and the reference objects do not have to be the same object.

I know this works because my Hale Telescope Addon has many moving parts which rotate and move relative to the telescope's coordinate systems.

It sounds to me like it would be clearer to you if you were to introduce an intermediate coordinate system (reference object) which rotates relative to your CSM coordinate system.

Don't forget that the axis that your reference system rotates around has some arbitrary orientation relative to the model. Its exact orientation depends on how you oriented the model in your 3D graphics program and how the 3D graphics program's coordinate system translates into Celestia's coordinate system. You have to adjust the axis names in the Modify BodyFrame statement to match what you want to see.

selden wrote:The "children" follow whatever objects are specified in their own two OrbitFrame and BodyFrame definItions. Those two reference objects do not have to be the "parent" specified in the names of the "children" and the reference objects do not have to be the same object...

I must do something wrong, because adding for example an orientation tag to the CSM def just change correctly the orientation of the CSM, but the two childrens don't follow... (beside the CSM being define in their bodyframe and orbitframe...)

For now I want to avoid adding any other elements because to me the logic is simple, the CSM got the moon as reference, the 2 others model got the CSM as ref so the situation must be crystal clear. Unfortunately there is something I'm unable to spot here...

I have to go to a meeting now, so I can't help for several hours.

I'm wondering if there might be a bug related to complicated names. Try changing the name of the CSM to be only the three letters CSM.

Indeed there is some bugs related to the name. Changing it change the configuration of the elements!
How could we debug such thing??

ElChristou wrote:

selden wrote:The "children" follow whatever objects are specified in their own two OrbitFrame and BodyFrame definItions. Those two reference objects do not have to be the "parent" specified in the names of the "children" and the reference objects do not have to be the same object...

I must do something wrong, because adding for example an orientation tag to the CSM def just change correctly the orientation of the CSM, but the two childrens don't follow... (beside the CSM being define in their bodyframe and orbitframe...)

For now I want to avoid adding any other elements because to me the logic is simple, the CSM got the moon as reference, the 2 others model got the CSM as ref so the situation must be crystal clear. Unfortunately there is something I'm unable to spot here...

The orientation property is ignored when computing the body-fixed frame of an object. This is intentional: the reason that the orientation property exists is to allow you to modify the attitude of an object within its own coordinate system. When you change the orientation of a cmod object in an ssc file, it's very much like you loaded the cmod in a modeling program, rotated it, and saved the file. Unfortunately, the documentation is not clear enough about how the orientation property works.

What you probably want to do is to change the parameters of the UniformRotation: http://en.wikibooks.org/wiki/Celestia/Rotation_Models
Change the Inclination, AscendingNode, and MeridianAngle to orient the model correctly. These parameters will probably be confusing unless you're well acquainted with celestial mechanics, and again I have to apologize for the unhelpfulness of the documentation. Some diagrams would greatly clarify how these parameters work to orient a model in space (can anyone suggest software for creating such diagrams?) An interactive editor would be helpful as well. In lieu of that, let me try and explain:

- Inclination is the easiest to explain--it is the angle between the axis of rotation and the z-axis of the object's body frame. To be more specific, the angle is measured from the object's north pole, with north defined as the direction from which the object appears to rotate counterclockwise. By default it is zero, so the axis of rotation is exactly aligned with the frame's z-axis. If you wanted to flip the object upside-down, you could set the inclination to 180; to roll it on its side, set the inclination to 90.

- MeridianAngle can be thought of as the angle of rotation around the axis. It changes at a constant rate with in a UniformRotation. The MeridianAngle property lets you set what the value of this angle is time zero (the epoch, which is 12:00 Jan 1, 2000 by default.)

- AscendingNode and Inclination together specify the axis of rotation. It is not enough just to give the inclination; you need to know the direction of the rotation axis in its frame's xy-plane.

I hope that this is helpful--ask more questions if you have them.

--Chris

Tx Chris but... then how I solve this problem if I need some bodyfixed def to fix B and C in relation to A?
In a few words, how to fix stuff on a parent then modify the parent to see all the stuff following?

BTW, I could do such graph; tomorrow If I have a minute I do one...

ElChristou wrote:Tx Chris but... then how I solve this problem if I need some bodyfixed def to fix B and C in relation to A?
In a few words, how to fix stuff on a parent then modify the parent to see all the stuff following?

Instead of modifying the Orientation of the parent, change the UniformRotation parameters: then all child objects will move along with the parent.

--Chris

ElChristou wrote:BTW, I could do such graph; tomorrow If I have a minute I do one...

Nope, talked to fast! Despite reading 10 times your definitions above and testing within Celestia, I still have NO idea on how this stuff work! It's simply INCREDIBLE how brain dead I can be sometimes (and this despite doing 3D for more than a decade now!!). Don't know if it's because of English or if I'm too tired but really I cannot believe it! I stop for today and try again tomorow...

Chris wrote:(can anyone suggest software for creating such diagrams?)

Umm.... Celestia?

(I've been thinking about making an Addon which would illustrate the various orbital parameters, but simply haven't taken the time to do so.)

p.s. it looks like I'll be busy with other things for the rest of the afternoon. Hopefully I'll be able to spend some time on these two issues this evening, after 6pm EDT.

El Christou,

I just threw together a trivial Addon which uses your ssc with only minor modifications: I made the components glow in the dark, decreased the period and added a cm.

It works perfectly for me: all of the components rotate as if they were a single rigid body.

Below is the Addon and a picture of my 4 objects
Obviously my components don't look at all like yours (e.g. they have racing stripes so I could see their orientations) but this demonstrates that all 4 objects rotate as if they were one.

Here's the ssc file that I used

Tx a lot Selden to spend some time on my little problem! But... (damned, there is a but!)

The rotation you made evident on your test addon is already (if I'm not wrong) in my original ssc via the UniformRotation period.
Now from my last test yesterday, Chris must be right, the solution must be in the UniformRotation; here is what I'd like to see:


In yellow my 3 elements. The Apollo 11 CSM+LM is the parent, thruster and LM the childrens.
Actually I have a UniformRotation on Z (quite slow, period 20 -> blue).
What I still cannot understand is how to rotate a few degrees the whole stack as shown in red. In another words, the stack should point a little to the ground. Now, to do well all the axis shown by Celestia should not change,only the model should get this small inclination... Do you see what I mean?

Specify
UniformRotation { ... Inclination 10 ...}
or whatever inclination is appropriate.