You are currently browsing the monthly archive for December 2008.
There is a little discussion about the “select a planet to orbit” feature in the docs, specifically about how the calculation assumes and may not give good results otherwise. After all, you can’t have a massive star orbit a tiny planet.
One thing not mentioned is that this function takes into consideration the current velocity of the parent object (the one that will be orbited). Depending on the system you are trying to create, this may be important.
Here is an example. Say you want to make a sun-earth-moon-like system, that you have finished entering in the starting positions, and are now at the point that you want to use this function to set the velocities of the planet and moon. The order affects the outcome, and you’ll first want to use the function on the planet, then secondly on the moon. This way the moon orbit will be calculated relative to the motion of the planet, which is itself in orbit. If you first set the moon to orbit the planet, and afterward set the planet to orbit the sun, the moon orbit will be calculated relative to a stationary planet, and the final result won’t have a stable orbit.
For those that are interested, the formula for calculating the circular orbit velocity for an object assuming is:
where d is the distance between the two objects. The velocity direction is perpendicular to the line connecting the two objects, and the particular perpendicular chosen determines the orbital plane. G3D picks an orbital plane that is parallel to the xy plane.
There is no limit to the number of planets except your computing power. However, orbital simulations are notoriously expensive for systems with many objects due to the fact that the n-body problem does not scale linearly with the number of objects (in simple implementations such as G3D, the cost scales with the square of the number of objects). In my experience, G3D does pretty well with up to about 500 objects, and my computer is not special.
One of the optimizations of G3D is how it handles planets with zero mass. Since these objects do not contribute to the gravitational field, their effect on other objects doesn’t need to be calculated, so G3D pulls them into a separate list and handles them specially. One can get a few thousand zero mass objects running pretty smoothly, depending on your graphics card (drawing limitations can become a bottleneck, workarounds to be discussed more later). I used zero mass planets some time ago to do a neat simulation of Lagrange points. Sure enough, many of the objects ended up coalescing in the stable L4 and L5 points, just like asteroids do in the Lagrange points of the Sun and Jupiter!
Wow, it sure would be tedious to enter all those object in, and hence a request I received to allow copying planets. G3D does not support this at the moment but in the mean time, if you are comfortable opening the .g3d files with a text editor, you can cut-and-paste planets in the definition file and edit their values there if you want. This can be a much faster form of entry and an easier way to get, say a 100 planets into the list quickly. If you’re comfortable writing scripts to generate text, many more options open up.
This was possible in the past in a roundabout way. Since the screen saver automatically downloads these files, you could set the number of frames to draw for each system to a very small value, and let the screen saver run to quickly pull the collection down. On my computer (XP), the screen saver puts these files at ‘C:\Documents and Settings\roice\Application Data\Gravitation 3D\’. Your mileage may vary.
In the spirit of this recent article, I thought it would be good for me to start a Gravitation3D blog to answer questions and share information about G3D in a publicly accessible way. This is a bit of an experiment, but I have positive hopes that it can become a useful resource over time. Let the simulation begin!