Continental-drift animations?

[lpetrich]

I wonder if it might be possible to implement something to display this in Celestia. This could be done by loading paleo-continent map textures and stepping through them.

Chris Scotese's site has several such maps, even if not in the most Celestia-friendly form (the larger ones use the Mollweide projection).

But such a display would likely require some way of getting user input for stepping through those textures.

[scaddenp]

Well being a geologist, I am interested, but many problems. I wonder whether celestia really is best platform for this or whether you want purpose built. A good one would need to be able to update against recognised plate databases (eg PLATES).
Celestia would have to do this a texture-swapping exercise. So do you
take snapshot textures from some reconstructions and morph them to
produce to your moving sequence? We have done this but you end up with
motions that are obviously wrong to experience eye unless you have a lot
of snapshots. There are very good programs for moving the plates continuously in time from database data. However, these show you the
plate boundaries and current coastlines, but hardly a texture of the planet
as it would like at a past time. What is missing is a texture-creator added
into the motion program that interpolates a texture from a database of
known constraints. Now that sounds a fun project but not one I have time
for. Building a the database of constraint data would be a major international
projec too.

[lpetrich]

I will concede that a plates-database approach would be inappropriate for Celestia; it would be off on a tangent relative to what Celestia is typically used for.

And even a texture-animation approach seems like it might not get much interest here.

Perhaps Xplanet might be a more suitable project to work from.

But I myself have done work on a globe viewer for continental-drift duty, one that works by texture swapping; I had not known about the PLATES database when I wrote it.

I had written it in Java, using Java 3D, hough perhaps I can write a version using the Simple DirectMedia Layer.

[chris]

I will concede that a plates-database approach would be inappropriate for Celestia; it would be off on a tangent relative to what Celestia is typically used for.

And even a texture-animation approach seems like it might not get much interest here.

Celestia does permit you to define alternate surfaces for a planet. The user can select which one to display via the right-click context menu on Windows (I think it's ctrl+click on a Mac with a one button mouse.) You can see examples of the alternate surfaces in the default solarsys.ssc that comes with Celestia--they're used to implement the 'limit of knowledge' feature.

There has been interest in texture animation in Celestia. Don Edwards has created a set of twelve seasonal textures for the Earth, one for each month; it would be great if Celestia could be configured to automatically pick the appropriate texture based on the time. It wouldn't be that hard add this to Celestia, but we'd have to come up with a good way to specify it via ssc files.

--Chris

[scaddenp]

The 3D viewing really is the easy bit - many many systems out there to
build on. I've done them in opengl before.
The hard bit is the texture creation. If you have app that creates the texture
for some time t then you are 99% there. Hell, I'd put the texture on the globe
for you! hacking it into celetra wouldnt be too bad. Worldwind does
scenarios.

[buggs_moran]

A simple search turned up these...

http://www.celestiaproject.net/forum/viewtopic.php?p=34864
http://www.nefkom.net/z-bau/celestia/

[Chuft-Captain]

...it would be great if Celestia could be configured to automatically pick the appropriate texture based on the time. It wouldn't be that hard add this to Celestia, but we'd have to come up with a good way to specify it via ssc files.

Chris,
I assume, from what you're saying above, that Begin/End dates cannot be applied to textures? Is that the case?
I have found a way to animate models by changing it's position in an SSC using Beginning and Ending dates. See my Orion docking at Space Station V download.

I'm wondering why the same technique could not be applied to textures. (Of course, even if it could, I guess there'd still be performance issues related to loading all the multiple textures into memory.

What I'm proposing is using the same technique to create multiple versions of Earth, for example, with each successive version beginning at the Ending date of the previous one, but with a different texture for each one.

(I'm not saying it's an elegant or good solution, but it does work for Orion).
Clear as mud??? If not, have a look at the Orion download. As far as I can see, there's no reason that I could not have used a new texture on each iteration of the Orion model (although I didn't).

Of course, if a sequence of frames could be generated within the C++ code, instead of the SSC, this would be far more elegant.
Also worth consideration, if you're thinking about generic solutions for animation of models and/or textures, is how the creation of cyclic or repeating events would be implemented. I think there's been a few requests in the past for this sort of capability. (I think from buggs_moran in particular)

Regards
CC

[bdm]

There has been interest in texture animation in Celestia. Don Edwards has created a set of twelve seasonal textures for the Earth, one for each month; it would be great if Celestia could be configured to automatically pick the appropriate texture based on the time. It wouldn't be that hard add this to Celestia, but we'd have to come up with a good way to specify it via ssc files.

--Chris

What needs to be specified in the SSC file, and what limitations of the SSC file format will impede the addition of this? I've made a quick stab at a likely format, but this will probably need more work.

Code: Select all

TextureLoop
{
    Repeat true/false # whether textures repeat in sequence or not
    Epoch 999999 # Julian date of start of cycle
    CycleLength 999999 or one of the keywords "day"or "year"
    TextureElement
    {
        Length 999999 # fraction of cycle
        Texture   "filename"
    }
    TextureElement
    {
        Length 999999 # fraction of cycle
        Texture   "filename"
    }
    # Additional definitions for texture elements repeat
    # as needed. When textures run out, they cycle again
    # from the beginning if repeat is enabled.
    # Length of time to display each texture (in days)
    # equals the length divided by the sum of all lengths,
    # multiplied by the cycle length.
    # The keywords for cycle length are "day" (mean
    # *solar* day) or "year" (period as defined by Period
    # in orbital elements, which may be the VSOP year.)
    # Other keywords may be needed. Providing
    # keywords allows access to the VSOP parameters
    # which otherwise cannot be accessed easily in an
    # SSC definition.
    # If repeat is turned off, Celestia displays the first
    # texture in the sequence if the current time is less
    # than the start Epoch; if the current time is after
    # the Epoch plus the cycle length then Celestia
    # displays the last texture in the sequence.
}

[buggs_moran]

...Also worth consideration, if you're thinking about generic solutions for animation of models and/or textures, is how the creation of cyclic or repeating events would be implemented. I think there's been a few requests in the past for this sort of capability. (I think from buggs_moran in particular)

Yup, but I don't want to sound too much like a broken record. What I have in mind would change the whole object, not just the texture. Changing just the texture would be nice for the paleo drift animations and maybe solar prominences, but I thing you need the ability to have the models change too, hence integration into the ssc.

It would have to be similar to Beginning and Ending, but would have some cyclical definition. For instance a daily occurance on Earth for one year every day at GMT mignight.

Code: Select all

Beginning "2006 01 01 12:00:00"
Cycle 86400 # in seconds, so every 24 hours (I know that's not exact)
Ending "2006 12 31 12:00:00" # perhaps the ability to set no ending?


Obviously the designer would have to do multiple definitions to get an animation together, but then it's an animation...

For instance with my cataclysmic binary work, I would have to design a series of events as if I were going to do 1 loop of animation (which I am doing right now). By just adding in the cycle command, it could loop indefinitely...

Oh yeah, while I am thinking of it Chris, how about the same Beginning and Ending (and cycling, thinking mass importation of variable stars) for STC files.

[Chuft-Captain]

What I have in mind would change the whole object, not just the texture. Changing just the texture would be nice for the paleo drift animations and maybe solar prominences, but I thing you need the ability to have the models change too, hence integration into the ssc.

It would have to be similar to Beginning and Ending, but would have some cyclical definition. For instance a daily occurance on Earth for one year every day at GMT mignight.

Don't get me wrong, I'm also all for a general solution for repeatable behaviour, models, textures, pulsars or whatever. (Not just textures)
Hence use of the word "generic" in previous post.

I'm thinking along the lines of allowing "variablity" to be specified on any appropriate SSC or STC attribute.

In terms of how this would be exposed in an SSC for example, I'm thinking that the values of object attributes for which this is enabled could perhaps be specified as variables, formulae, or even as a pseudo C++ style looping syntax.
If done properly, this could allow great creative freedom, by allowing animation or other time-dependent variability to be "programmed" separately for multiple attributes of the object within the SSC.
The key to it is allowing SSC attributes to be specified as variables rather than constants.
Of course, TNSTAAFL -- this would complicate the parsing of the SSC/STC files.

eg.
An object could perhaps increase it's SemiMajorAxis (or even derive it from a formula), while simultaneously slowly decreasing it's RotationRate, and morphing some of it's textures.

I'm thinking this could be used for anything from simulated spacecraft flight, to texture animations of continental drift as suggested in this post.
(The limits would be your imagination and programming ability)

lpetrich, this type of enhancement (even if possible) is unlikely to happen overnight, so I suggest you investigate adapting my TRAVELLING ORION technique to your purposes. (-- Instead of modifying SemiMajorAxis as I have, you would change the name of the texture file, for each iteration. The smoother the animation required, the more iterations you will need.
It's maybe worth a try IMO.

CC

[DonAVP]

The other question would be on what time scale you would display this movement of the landmasses? If you speed up Celestia as fast as it can go I think the land would move very slowly. Am I correct about the millions or hundreds of millions of years these things take? That would be a lot of images if you were doing it that way.

I own Ligthwave and have the latest version. They have made it possible to create a camera that will generate a spherical or cylindrical image. I can then create the landmasses and move them over a sphere and record images that could be mapped onto the sphere as has been discussed.

I would need info and data on what moves were mind you. Imaging the seasonal changes would be easy as well because most surfacing effects can be enveloped to change with time (like snow appearing and melting on mountains) etc.


Don

[selden]

Once you've got enough surface textures, a script can be used to cause Celestia display them at an appropriate speed.

[Chuft-Captain]

See my Continental Drift DEMO here: http://celestiaproject.net/forum/viewtopic.php?p=75057#75057

enjoy!
CC

[scaddenp]

[quote="DonAVP"]
I own Ligthwave and have the latest version. They have made it possible to create a camera that will generate a spherical or cylindrical image. I can then create the landmasses and move them over a sphere and record images that could be mapped onto the sphere as has been discussed.
Don[/quote]

Doing this properly is quite difficult. plate motion is described in terms of rates of rotations about poles of rotation. The poles of rotation move with time as well. You also have to deal with new plates, merging and vanishing
plates.

I guess it comes down to what you are trying to do. An educational view of main features is straight forward enough - examples out there as people have pointed out. If wanting to do microplates and use the most accurate data available, then the motions can be done by various pieces of dedicated software. The trick then is what to actually display as texture. A geologist is usually interested in present day coastline (for orientation) and geological maps. Hardly the "view from space". A user of celestia I suspect would want to know what the planet would look like from space in past time and thus needs the data for starters on where was land and where was sea for starters. This is a massive database issue and what exists at the moment is very coarse grained in both time and space. What I have seen of where and when mountains might exist is even worse.

While you could do morphing for intermediate steps, data-derived frames for timestep of 1my would be tough and very tough beyond 100my or so.

[Chuft-Captain]

A simple search turned up these...


http://www.celestiaproject.net/forum/viewtopic.php?p=34864
http://www.nefkom.net/z-bau/celestia/

I downloaded the Paleo Earth addon and Speculars from Maxim's site ( http://www.nefkom.net/z-bau/celestia/ ) above, with no problems.

However, when I tried to download the Normals file "Paleo Earth Normals.zip" it was corrupted. (It's stated as being ~4mb but only downloaded as 1.2mb. I suspect last upload of it was interrupted leaving a partial file. (Same problem at his mirror site: http://celestia.ziegelstein.net/ )

Maxim, would you pls investigate ... or if someone else has a complete version of this ZIP, perhaps you could post it here.

Thanks
CC

[maxim]

It has been fixed.

[Chuft-Captain]

Thanks Maxim. Will try again.