Here is a fun idea that I have been playing around with. One of the future versions of Celestia (2.0) should include great cosmic events, such as a Mars size planet colliding with Earth Mk I to from Earth Mk II (the planet as we now know it) other events such as the asteroid that wiped out the dinosaurs, and the Shoemaker-Levy 9 impacts, Tunguska Blast, Stars going super nova etc… would be considered great events. We know more or less what stars are going to blowup as super nova, and collapse as black holes.
I don’t know how to implement it, but the data is there.
Someone would have to write a special subroutine(s) (Physics engine) but it is possible, and with the increased graphics and processing capabilities it would add a lot to the Celestia universe.
As a note Everything I listed is a real cosmic event, even the Earth Mk II (this is a relatively un-discussed event, but the only way to explain the formation of the moon, and the accepted way it was formed 4 billion years ago). And for a quick visual the collision between Earth Mk I and the rouge planet would look like it was happening in slow motion over a period of several hours and possible days.
Fun with time (Collisions, Explosions, Collapses)
One possible way to do this might be to delete and add objects (orbits, models, & textures) according to a schedule specified in a script. Alternttively, this might be done by just changing the visibility of preloaded objects.. Celestia really isn't designed to model physics, execpt for a limited form of motion.
Selden
You could probably hack together support for something like that by adding a few features:
Animated textures (watch as Earth's crust is smashed and turned to magma)
Realtime resizing of mesh files (I think the Earth grew in size during 1st impact)
Lifespan parameter for objects (would also be useful for satellite data.)
Support for decaying/changing orbits (debris from 1st impact needs to fall into the Earth or the newly forming moon)
Animated sprites (you'd need something like this for impact effects. code an animation of thousands of sparks being thrown out and fading away and you can use it for lots of collision events)
With the exception of the lifespan parameter, I think all of this will be a lot of work and is something for v2.0, not the minor releases.
Animated textures (watch as Earth's crust is smashed and turned to magma)
Realtime resizing of mesh files (I think the Earth grew in size during 1st impact)
Lifespan parameter for objects (would also be useful for satellite data.)
Support for decaying/changing orbits (debris from 1st impact needs to fall into the Earth or the newly forming moon)
Animated sprites (you'd need something like this for impact effects. code an animation of thousands of sparks being thrown out and fading away and you can use it for lots of collision events)
With the exception of the lifespan parameter, I think all of this will be a lot of work and is something for v2.0, not the minor releases.
I am putting together a list off all the things that can happen for small object collisions. This one is the simplest for a number of reasons
Things to discuss
1. Atmospheric streak (object entering the atmosphere)
2. Impact effect (how large for a given size, need simple formula ejected matter, etc…)
3. Post Effects (how to go about implementing cloud generation, and then fading to revel the aftermath)
4. Aftermath (changed bump mapping, textures)
The easiest event that I can think of to implement with relative ease is the Shoemaker-Levy 9 impacts, mainly because you only need the first two parts of the list.
Things to discuss
1. Atmospheric streak (object entering the atmosphere)
2. Impact effect (how large for a given size, need simple formula ejected matter, etc…)
3. Post Effects (how to go about implementing cloud generation, and then fading to revel the aftermath)
4. Aftermath (changed bump mapping, textures)
The easiest event that I can think of to implement with relative ease is the Shoemaker-Levy 9 impacts, mainly because you only need the first two parts of the list.
I love all these ideas and would love to see them implemented at some point. However, I think it would be prudant to concentrate on the most profound, yet basic changes required to make all these ideas work. They are:
1) Multiple orbit definitions per body
2) Start/End times per orbit
3) Reparenting a body
In an .ssc file's body definition, we could specify multiple orbits which include start and finish dates/times:
Obviously, the code above is for demonstrative purposes only. It is not realistic to expect Mercury to instantly jump from one orbit to another. We could specify more orbits between these two which explicitly describe it's movement from one to the other, but I believe there is a more elegant solution: Leave a time gap in the OrbitEnd of the first and the OrbitBegin of the second. Celestia could then attempt to guestimate the body's position:
vc = ( v2 - v1 ) * ( ( 1.0 / ( t2 - t1 ) ) * ( tc - t1 ) )
Where:
v1 = body vector at end of last orbit
v2 = body vector at begining of next orbit
t1 = time at end of last orbit
t2 = time at begining of next orbit
tc = current time
This paticular calculation is linear, but it could effectivly be softened to provide a more realistic curved transition.
Bodys which have a finite lifespan ( Apollo missions, Schumaker-Levy 9 ) would particularly benifit from specific begining and ending times associated with thier orbits. Schumaker-Levy 9 would only need one orbit, no begining time, but an ending time. I won't mind the missing 'dark spots' which resulted from the collision, so long as I can watch the jovian giant swallow the pieces.
Apollo missions are more complex. Not only do we need multiple orbits w/ start/stop times, but Celestia will need to dynamicaly reparent the body during runtime. ( Begin with an Earth orbit, shift to a lunar orbit, then back to an Earth orbit ) Implementing this should be straightforward, as I'm sure the Celestia developers created a flexable, object oriented data structure to store the universe in.
1) Multiple orbit definitions per body
2) Start/End times per orbit
3) Reparenting a body
In an .ssc file's body definition, we could specify multiple orbits which include start and finish dates/times:
Code: Select all
...
EllipticalOrbit {
Period 0.2408
SemiMajorAxis 0.3871
Eccentricity 0.2056
Inclination 7.0049
AscendingNode 48.33167
LongOfPericenter 77.456
MeanLongitude 252.251
OrbitBegin ~
OrbitEnd 2006/7/4/8/58/43
}
EllipticalOrbit {
Period 0.3631
SemiMajorAxis 1.6871
Eccentricity 0.4056
Inclination 17.0049
AscendingNode 48.33167
LongOfPericenter 97.456
MeanLongitude 252.251
OrbitBegin 2006/7/4/8/58/44
OrbitEnd ~
}
Obviously, the code above is for demonstrative purposes only. It is not realistic to expect Mercury to instantly jump from one orbit to another. We could specify more orbits between these two which explicitly describe it's movement from one to the other, but I believe there is a more elegant solution: Leave a time gap in the OrbitEnd of the first and the OrbitBegin of the second. Celestia could then attempt to guestimate the body's position:
vc = ( v2 - v1 ) * ( ( 1.0 / ( t2 - t1 ) ) * ( tc - t1 ) )
Where:
v1 = body vector at end of last orbit
v2 = body vector at begining of next orbit
t1 = time at end of last orbit
t2 = time at begining of next orbit
tc = current time
This paticular calculation is linear, but it could effectivly be softened to provide a more realistic curved transition.
Bodys which have a finite lifespan ( Apollo missions, Schumaker-Levy 9 ) would particularly benifit from specific begining and ending times associated with thier orbits. Schumaker-Levy 9 would only need one orbit, no begining time, but an ending time. I won't mind the missing 'dark spots' which resulted from the collision, so long as I can watch the jovian giant swallow the pieces.
Apollo missions are more complex. Not only do we need multiple orbits w/ start/stop times, but Celestia will need to dynamicaly reparent the body during runtime. ( Begin with an Earth orbit, shift to a lunar orbit, then back to an Earth orbit ) Implementing this should be straightforward, as I'm sure the Celestia developers created a flexable, object oriented data structure to store the universe in.
To come up with good looking scriptable orbits, you only need three orbital elements
Location the Tangent Point Algorithm
(This is for entrance and exit variable)
3d Spiral Algorithm
An orbit that is either increasing or decreasing or changing its angle in the orbit.
3d Spline Curve Algorithm
http://www.geocities.com/SiliconValley/ ... ndex2.html
Splines are by far the most confusing, but here is how it works. A spline works by taking an entrance and exit vector and then using a third point to come up with the curvature. The entrance and exit points are not the problem; the real question is where to put the third point. For orbits the third point would be the center of mass for the both object. The angle at which the spline goes through that point is can be determined by the average of two factor; the direct tangent line of the first orbit to the second orbit at the time of exiting the first orbit, and the direct tangent line of the first orbit to the second orbit at the time of entering the second orbit. This should produce a nice looking spline that is fairly accurate.
The good news and bad news,
Bad news is that this requires some processing upfront.
Good news you only have to do it once per segment of the object.
Location the Tangent Point Algorithm
(This is for entrance and exit variable)
3d Spiral Algorithm
An orbit that is either increasing or decreasing or changing its angle in the orbit.
3d Spline Curve Algorithm
http://www.geocities.com/SiliconValley/ ... ndex2.html
Splines are by far the most confusing, but here is how it works. A spline works by taking an entrance and exit vector and then using a third point to come up with the curvature. The entrance and exit points are not the problem; the real question is where to put the third point. For orbits the third point would be the center of mass for the both object. The angle at which the spline goes through that point is can be determined by the average of two factor; the direct tangent line of the first orbit to the second orbit at the time of exiting the first orbit, and the direct tangent line of the first orbit to the second orbit at the time of entering the second orbit. This should produce a nice looking spline that is fairly accurate.
The good news and bad news,
Bad news is that this requires some processing upfront.
Good news you only have to do it once per segment of the object.
-
chris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 5 months
- Location: Seattle, Washington, USA
My plan is to support complex orbits through scripting . . . It's my opinion that a purely data driven approach just won't be flexible enough to handle all possible scenarios. A scripting system with built in support for elliptical orbits and a selection of interpolation functions is a better solution. I also want to improve support for trajectories specified as a list of points--like the current .xyz files, except with better interpolation and the ability to encode orientation. Start/end time is a simple addition that I think is worth adding the .ssc file, if only to stop all the mail I get complaining that Mir is still in orbit
--Chris
--Chris
I need to make a correction to the statement above. You don’t have to know the angle at which the object would go through center of mass point. You only have to know where it is. The spline will determine at what angle based upon what the entrance and exit vectors are.
I will get some visuals for you ASAP
I will get some visuals for you ASAP
-
chris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 5 months
- Location: Seattle, Washington, USA
MKruer wrote:I need to make a correction to the statement above. You don’t have to know the angle at which the object would go through center of mass point. You only have to know where it is. The spline will determine at what angle based upon what the entrance and exit vectors are.
I will get some visuals for you ASAP
Two positions and two velocity vectors are all that you need for a Bezier curve . . .
Celestia already performs a sort of orbit blending . . . Orbits of the planets are normally computed using a series of periodic terms, but these are only usable within a certain range. Far into the future or the past, elliptical orbits are used instead. Celestia computes the parameters of these orbits automatically from a position and velocity generated by the series.
--Chris
MKruer wrote:
I need to make a correction to the statement above. You don’t have to know the angle at which the object would go through center of mass point. You only have to know where it is. The spline will determine at what angle based upon what the entrance and exit vectors are.
I will get some visuals for you ASAP
Two positions and two velocity vectors are all that you need for a Bezier curve . . .
Celestia already performs a sort of orbit blending . . . Orbits of the planets are normally computed using a series of periodic terms, but these are only usable within a certain range. Far into the future or the past, elliptical orbits are used instead. Celestia computes the parameters of these orbits automatically from a position and velocity generated by the series.
--Chris
The reason why I placed the mid point at the center of mass between the two objects is due to gravitational effects. This produces an accurate orbit. This would only apply for Bezier S curves where the orbit reverses direction.
Also I found this page that you might find informative on spirals.
[url]http://jwilson.coe.uga.edu/EMT668/EMAT6680.F99/Erbas/KURSATgeometrypro/golden%20spiral/logspiral-history.html
[/url]
-
auscreely
start and end dates
If you could set up the start and end dates corectly it would be posibole.
first start with earth mkI and the ather planit set the orbits together aond normoly thay would go throu eachother but if you set there end dates to the same time then thay would disiper and start the time for earth mk2 and there you have it, it wont look so great yet but it is a start.
first start with earth mkI and the ather planit set the orbits together aond normoly thay would go throu eachother but if you set there end dates to the same time then thay would disiper and start the time for earth mk2 and there you have it, it wont look so great yet but it is a start.