Stars actually move. Very, very slowly. So slow as to be mostly immaterial when presenting things. Planets, however, move much faster than stars. Consequently when we are displaying planets it is useful to be able to show them moving around their primary. There are three parameters, Date, DateIncr, and DateUpdate that control this. We used this to show how Orbital Period works, but we didn't say how we did it. Now we say how.
This is a single value that represents the date when the applet is initialized. The units are arbitrary but normally are in days. If no date parameter is specified, or a negative value is specified, the value of the current system clock is used. This is handy for setting "random positions" to planets when you start up.
This goes hand in hand with DateUpdate. It is the value that Date is incremented by for each period. This should be in the same units as Date. With no DateIncr set, Date will remain fixed to whatever value is given originally.
This is how often to add DateIncr to Date and redisplay. It is measured in seconds. Depending on the complexity of your display, and the speed of your machine, it is possible to set this higher than is displayable on your machine. Values down to .25 work well for most configurations.
The applet below is the one we used to show how Orbital Period works. We want to show the planets orbiting in sync, so we choose an arbitrary scale with 1 being the orbital period of the innermost planet. We then set the second planet to 2, the third to 4 and the fourth to 8. This way each of them rotate in sync, like the moons of Jupiter.
To make them move, then, we need to set up our date paremeters, as above. First we choose the DateUpdate parameter. Since we want a reasonable refresh, but aren't sure what sort of machine the stuff will be run on, we choose an update of .25 seconds. We then decide we want the innermost planet to orbit around the star in four seconds. So we want to increment Date from 0 to 1 over the course of 4 seconds. In 4 seconds, with a DateUpdate parameter of .25, 16 updates will occur. So setting a DateIncr value of 1/16 or .0625 will give us the desired result.
<applet code=chview.ChViewer archive=chview.jar width=640 height=320> <param name="Date" value="0"> <param name="DateIncr" value=".0625"> <param name="DateUpdate" value=".25"> <param name="body001" value="B!!!!Star!!yellow ! 0!0!0!4!0"> <param name="body002" value="B!!!One !!Star!darkgrey! 1!1!0!4!0"> <param name="body003" value="B!!!Two !!Star!green ! 2!2!0!4!0"> <param name="body004" value="B!!!Three!!Star!blue ! 3!4!0!4!0"> <param name="body005" value="B!!!Four !!Star!red ! 4!8!0!4!0"> </applet>
You may have noticed that the orbital trails in these examples aren't solid. They fade out over the course of the orbits. Sometimes this is desirable, sometimes not. The amount by which they fade is controlled by by the TrailFade parameter.
The higher the value, the less the fade. The default value is .90, which gives a gradual fade around the course of the orbit. A value of 1.0 means that there is no fade at all. There isn't much point in making it higher than 1.0.
<applet code=chview.ChViewer archive=chview.jar width=640 height=320> <param name="TrailFade" value="1"> <param name="Date" value="0"> <param name="DateIncr" value=".0625"> <param name="DateUpdate" value=".25"> <param name="body001" value="B!!!!Star!!yellow ! 0!0!0!4!0"> <param name="body002" value="B!!!One !!Star!darkgrey! 1!1!0!4!0"> <param name="body003" value="B!!!Two !!Star!green ! 2!2!0!4!0"> <param name="body004" value="B!!!Three!!Star!blue ! 3!4!0!4!0"> <param name="body005" value="B!!!Four !!Star!red ! 4!8!0!4!0"> </applet>
© 1998-2001 Sol Company. All Rights Reserved.