Couple of questions on various topics/feature requests

[JackHiggins]

(1) It's 5pm in the evening where I am at the moment. From the ground in celestia, it shows the sky fairly accurately- it's a bit dark, and the sky is a bit bluer then it should be, but that's probably due to cloud.

However, if I go into space & look down on on Europe from above, it's pitch black. I'm guessing that at the very least, this is a *tad* bit unrealistic. Am I right? This same thing happens with the day/night terminator on the moon, where it's much more gradual than in reality. Chris mentioned a long time ago that he was going to implement a more realistic lighting model. "Lambertian", or is that the current one..? I'd like to know has there been any progress on this..?

(2) According to celestia, I should (right now) be able to see Mercury and Venus in the sky, with Mag set to 0.83.
I can't.
Another 45mins or so I should start to see Venus i'd say, Mercury is right next to the sun and so nearly impossible to see.
Any chance this could be improved on a bit?

(3) Will the new CMOD format be able to cast shadows properly, unlike 3ds, which currently can't? Will it ever be possible for 3ds to cast shadows?

(4) Relative and angular velocity display. Seriously, it can't be THAT hard, can it? I've mentioned this a good few times but never got much of a response. What does everyone else think of this as a feature?

(5) App. Magnitude display for non-stellar objects. Good idea?

(6) Some way of better representing orientations for Spacecraft, and some way of changing the orientations via a script-like file, but a file that would act like an addon to an ssc. This is ESA's biggest feature request in celestia also, it's not just me banging on about it all the time. And if celestia is to get big, ESA are a great way of promoting it.

I have an idea for what kinds of commands etc the script file would have, and i'll post it if anyone's interested.

I'd like to get some feedback on all these- any comments welcome! (PLEASE give some response at least, I wasn't too successful in the last couple of threads...)

[chris]

(1) It's 5pm in the evening where I am at the moment. From the ground in celestia, it shows the sky fairly accurately- it's a bit dark, and the sky is a bit bluer then it should be, but that's probably due to cloud.

However, if I go into space & look down on on Europe from above, it's pitch black. I'm guessing that at the very least, this is a *tad* bit unrealistic. Am I right? This same thing happens with the day/night terminator on the moon, where it's much more gradual than in reality. Chris mentioned a long time ago that he was going to implement a more realistic lighting model. "Lambertian", or is that the current one..? I'd like to know has there been any progress on this..?

If you discount Celestia's very simple specular lighting parameters, then all planets have Lambertian surfaces now--this just means that the lighting is independent of viewer position. Recently, I've been doing quite a bit of work with shaders that will be the foundation for experiments with better lighting models.

(2) According to celestia, I should (right now) be able to see Mercury and Venus in the sky, with Mag set to 0.83.
I can't.
Another 45mins or so I should start to see Venus i'd say, Mercury is right next to the sun and so nearly impossible to see.
Any chance this could be improved on a bit?

Eventually, yes . . . I'll be revisiting atmosphere rendering again. One of the things I'm going to do is add sky brightening near the Sun, which should nicely obscure planets in the morning and evening sky. It's not a general solution though . . .

(3) Will the new CMOD format be able to cast shadows properly, unlike 3ds, which currently can't? Will it ever be possible for 3ds to cast shadows?

Both cmod and 3ds files are converted into the same internal format, so if I get shadows working, they'll work for cmod and 3ds files. I'll probably use stencil shadow volumes for meshes . . . This technique has it's disadvantages, but it's the only real-time method I know that doesn't totally screw up shadows for fine geometry that spacecraft models are full of.

(4) Relative and angular velocity display. Seriously, it can't be THAT hard, can it? I've mentioned this a good few times but never got much of a response. What does everyone else think of this as a feature?

Velocity relative to the currently reference object is probably a lot more useful than the absolute velocity (which in Celestia means 'relative to the stars', since the stars are fixed). As for angular velocity, well, what would you like to see?

(5) App. Magnitude display for non-stellar objects. Good idea?

The reason I don't show this now is that my simple calculations for magnitude produces results that are only approximately correct. I don't know of a general formula for computing the magnitude of a planet. Most planetarium programs use empirical formulae specific to individual planets, and these wouldn't suffice for Celestia.

(6) Some way of better representing orientations for Spacecraft, and some way of changing the orientations via a script-like file, but a file that would act like an addon to an ssc. This is ESA's biggest feature request in celestia also, it's not just me banging on about it all the time. And if celestia is to get big, ESA are a great way of promoting it.

There are two things I want to do: add animation support to cmod files, and create a variant of .xyz files that contain orientations. The first would be used for animating individual parts of a spacecraft, the second could be used to rotate the entire object.

I have an idea for what kinds of commands etc the script file would have, and i'll post it if anyone's interested.

I'm very interested in seeing what these script files look like!

--Chris

[Evil Dr Ganymede]

If you discount Celestia's very simple specular lighting parameters, then all planets have Lambertian surfaces now--this just means that the lighting is independent of viewer position. Recently, I've been doing quite a bit of work with shaders that will be the foundation for experiments with better lighting models.

The Lommel-seeliger function is the way to go for planetary photometric functions - it's what the Moon has, which is why it's about the same brightness from terminator to limb, rather than dimming towards the limb as you'd get with Lambertian.

IIRC from my days of shape-from-shading photoclinometry, Lambertian isn't particularly realistic for planetary surfaces.

[Toti]

I have an idea for what kinds of commands etc the script file would have, and i'll post it if anyone's interested.

Yes, please post it, and be very descriptive. This is an interesting discussion.

There are two things I want to do: add animation support to cmod files, and create a variant of .xyz files that contain orientations. The first would be used for animating individual parts of a spacecraft, the second could be used to rotate the entire object.

Perhaps adding very basic armature support to the CMOD file will make the first feature possible. I was thinking of a (bone origin, bone direction, bone distance, bone parent) set for each mesh.
In order to add animation to these bones, I can write some keyframing-curve conversion utilities.

Bye

[JackHiggins]

Thanks for the responses- will post full response tomorrow... Must go sleep- phys/astro lecture tomorrow in school from this guy (UCC's rather informal astrophysics site at http://astro.ucc.ie/ )

[JackHiggins]

Recently, I've been doing quite a bit of work with shaders that will be the foundation for experiments with better lighting models.

Nice! Time for Jack to get himself a new graphics card soon then...

The Lommel-seeliger function is the way to go for planetary photometric functions

I'll take your word for it...

Eventually, yes . . . I'll be revisiting atmosphere rendering again. One of the things I'm going to do is add sky brightening near the Sun, which should nicely obscure planets in the morning and evening sky. It's not a general solution though . . .

Is there any possibility of seeing something like there was in the old OpenUniverse program (back in the day... ) where, when you turned towards the sun, the screen brightened dramatically and obscured your view of everything else?
It's a realistic simulation of what you would really see, except in reality it would dim back to say 50% of the max "flare" (I'd like to emphasise that this is NOT a "lens flare" just a brightening) as your eyes adjust to the brightness.

Another idea- for objects inside an atmosphere (on the surface like), would it be possible to give them ambient light, or would it be too difficult to work out which objects need it & not, all the time?

Both cmod and 3ds files are converted into the same internal format, so if I get shadows working, they'll work for cmod and 3ds files.

Great! Don't know if you've seen my post about Phobos transits on mars, and how they don't show up, but that might be something to look at as well. (even when phobos is set as a sphere no shadow is cast, and in reality there is a penumbra visible)

Velocity relative to the currently reference object is probably a lot more useful than the absolute velocity (which in Celestia means 'relative to the stars', since the stars are fixed). As for angular velocity, well, what would you like to see?

I did think that relative would be the more useful... I suppose this/these could be listed in the two blank lines above the "speed" display on the bottom left?

Anyway, relative velocity definitely, especially useful when trying to manually rendezvous with something, you know by how much to raise/lower your own velocity!

Angular velocity... Readout varying between km/sec, ly/sec etc like the other ones (not rads/sec in case anyone thought i meant that! ) I was thinking it might be interesting from an educational point of view, for example when following along a spacecraft on a gravity assist trajectory (or any close-approach xyz for that matter) you could see how the planet's gravity well pulls in the object, and how it keeps some of the velocity it's gained after the flyby. Same for comets, other really eccentric orbits etc, to see the big variations in speed at the different points along their orbits.

The reason I don't show this now is that my simple calculations for magnitude produces results that are only approximately correct. I don't know of a general formula for computing the magnitude of a planet. Most planetarium programs use empirical formulae specific to individual planets, and these wouldn't suffice for Celestia.

Ah- ok. But... How does celestia work out how bright to display objects normally? I thought it was some kind of albedo:observer distance:distance to light source ratio? Surely if celestia can figure this out, it's not such a big leap to read these out in magnitudes...? Or am I missing some major logical step here?!

There are two things I want to do: add animation support to cmod files, and create a variant of .xyz files that contain orientations. The first would be used for animating individual parts of a spacecraft, the second could be used to rotate the entire object.

Fantastic! Any ideas how long it might be before we see the beginnings of animation support?

I'm very interested in seeing what these script files look like!

Yes, please post it, and be very descriptive. This is an interesting discussion.

Will do; next post below... (Could take some time to write out, given this is the first time i'm putting all these ideas in a single post!)

[JackHiggins]

Here's my list of commands/features that I reckon must be included in the orientation "script" files, and a short description of each:

Code: Select all

1. pointingaxis
   -spin axis of the spacecraft
   -"track" axis of the spacecraft, for example when the HGA is set to point at earth to transmit data
   -would be listed as something like +x for positive x axis as being the part you want to point, -y, +z etc. Most models are oriented along an axis, so there's no need to involve angles here.

2. track
   -points the previously set pointingaxis of the spacecraft to turn towards a specified point, object, coordinate etc.
   -has a random generator, so that for objects like hubble etc, you can set it to look at point X for 15 hours, then turn to point Y for same length of time (or random time between A and B) and it would take length of time C to turn the distance between coords X and Y. (C could also be something like degrees/rads per sec or similar)

3. rotate
   -rotates the craft around an axis (duh) but the rotation can be set to be a certain number of degrees, or rotate to point AT an object, but not track it.
   -rotate could be used on multiple axes simultaneously, so if x turns at 4 degrees/sec, y is also turning at 15 degrees/sec and Y is turning at 9 degrees/sec or whatever. (could be handy to model "chaotic" rotations like hyperion etc)

4. xyz orientations
   -set spacecraft to point at position A at time A, pos B at time B, etc. I suppose it'd be better for this to be relative to the spacecraft...
   -an option to do the same, but using degrees around x axis, y axis, z axis could be useful too

5. orienting individual parts of spacecraft
   -with the coming of animation... The option to keep the solar panels of a craft permanently pointed at Sol, for example. This would restrict some types of other movements, but I suppose solar panel etc orienting could be made to override other commands. Speaking of which...

6. overrides
   -where one command (say, one to keep a thermally protected side of a spacecraft pointed toward Sol) will always stay in action, no matter what else you tell the spacecraft to do. Would act on everything that comes after it in the script.

7. coordinate systems
   -the option to set a spacecraft to point at objects (lat/long ground locations would be nice too), Ra and Dec, xyz points relative to spacecraft, and degrees around axes.

8. layout of script file
   -preferably something simple and in order of time, like cel scripts... (Something everybody could understand & easily edit if need be)
   -the possibility to call from other files, like say putting xyz orientations in another, seperate file to reduce clutter in the main command file.


Okay I have no idea at the moment how the actual script would be laid out, and I'm feeling really miserable with a bad cold , so i'll let someone else take a crack at that while I recover...

Maybe these ideas are really stupid, or really obvious etc but it's worth making a start on this anyway... Add in your own ideas below anyway!

[Toti]

Add in your own ideas below anyway!

I will, but first I need some very specific knowledge basement.
Let me explain myself:

There are two things I want to do: add animation support to cmod files, and create a variant of .xyz files that contain orientations.

Then I can assume that there is detailed info about probe orientations over time available to the general public.

But:
Is there any organized info regarding other spacecraft functions like thruster ignitions (time, duration, thrust intensity), camera/sensor-instruments movement, solar panels deployment, etc. for past missions like Voyager?
I am thinking of full and accurate support for probe behavior, which needs this kind of data to be available on the net.

[JackHiggins]

Then I can assume that there is detailed info about probe orientations over time available to the general public.

But:
Is there any organized info regarding other spacecraft functions like thruster ignitions (time, duration, thrust intensity), camera/sensor-instruments movement, solar panels deployment, etc. for past missions like Voyager?

I would assume so, and it shouldn't be too hard to get for current missions... ESA want to use Celestia more and more as a mission visualisation tool, and I believe they have some sort of xyz file describing the orientation of at least two spacecraft (Mars Express & Rosetta) which they'd like to input into celestia.

Emailing the relevant people at ESA/NASA etc should be sufficient to get the orientation data that's needed, in whatever form.

For things like solar panel deployements, usually this is listed online, and thruster firings are probably gotten the same way as the orientation data.

[chris]

I would assume so, and it shouldn't be too hard to get for current missions... ESA want to use Celestia more and more as a mission visualisation tool, and I believe they have some sort of xyz file describing the orientation of at least two spacecraft (Mars Express & Rosetta) which they'd like to input into celestia.

Getting the ESA's orientation information for these spacecraft would be immensely helpful. I'd like to better understand the sort of data they're working with . . . Is it just a sequence of keyframes? And if so, what's the frame of reference?

--Chris

[maxim]

Here's my list of commands/features that I reckon must be included in the orientation "script" files, and a short description of each:

I can't get the overall picture from these explanations.
I understand (most) of the single points, but I can't get the relations to each other or the global framework. How - for example - would the function interfaces be defined? Can you give more (detailed) information about the model thats in your head about this?

maxim

[Toti]

I would assume so, and it shouldn't be too hard to get for current missions...
For things like solar panel deployements, usually this is listed online, and thruster firings are probably gotten the same way as the orientation data.

Well, let's suppose that this data is indeed available, and that it can be ordered systematically, coordinate-converted, etc. Then we have a file with:

Code: Select all

[time] [x] [y] [w] [a] [b] [c]

where x,y,w are he usual position coordinates and a,b,c are three axis rotation angles.
And another file with:

Code: Select all

[time] [command (parameters)]

The first file is more suitable to be created using perl scripts. I suspect that the second will have a more creative/heuristic origin.
With the first file we get a very good approximation of the probe general behaviour. But gives no info on certain "flight operations" that are really interesting, like -as I said- multi stage deployment, etc.
The second file overrides the first one and has great potential in simulation expanding. Two kind of animations support is needed:

Scripted animations: these will allow the spacecraft to do simple movements that are easy to describe using a few parameters, like sensorial-arm rotations, object tracking, etc.

Keyframed animations: this is for very complex movements that can't be descripted with a few commands, and need to be animated using software like Max, Lightwave, etc. Example: solar panel unfolding, intrincate robotic arm movements, etc.
The resulting keyframe curves could be exported to a file, indexed by a name, and should be called from the script using a proper command:



Code: Select all

2450736.937500000    play_key_anim (Pathfinder, Unfold4)


Here, the keyframe curves for Unfold4 animation is applied to Pathfinder.

Imagine a probe model that is composed of several 3d meshes (body, high gain antenna, solar panels, etc.) joined together by a logical skeleton or armature.
Thus, each mesh is associated with a bone. The script commands operates on this bone.
Some of this commands could be like:

Code: Select all

mesh_align (Cassini, camera1, Saturn, 45)

Aligns camera1 of object Cassini pointing its "bone" vector to Saturn taking 45 seconds to do the maneuver

Code: Select all

object_split (Cassini, HuygensProbe)

Separates the component HuygensProbe from the rest of Cassini; from now on HuygensProbe is treated as an entire independent object: it should have its own trajectory.

Code: Select all

object_change_trajectory (HuygensProbe, Huygens.xyz)

From now on HuygensProbe must follow the trajectory included in Huygens.xyz. Useful to model unplanned orbit changes/trajectory remodelling that make the oldfile obsolete. Also could be used with the above explained 'object_split' to assign trajectories to the splitted objects

Code: Select all

object_delete (HuygensProbe)

Useful to erase a object that can now be considered useless (fuel tanks, parachutes, abandoned/destroyed probes, etc.

Code: Select all

do_particle_effect (Voyager1, thrustermesh1, burst, 5, 112)

Displays a burst effect of size 5 from a probe?s maneuvering rocket ('thrustermesh1') along it?s associated "bone" vector. The effect last 112 seconds


With this approach the user will be able to closely follow, for example, the final steps of a probe?s atmospheric insertion/parachute/landing, all done in real time. I see a lot of educative/media possibilities for this.

What do you think?

[t00fri]

Toti,

personally, I really have trouble seeing what such animation sequences might be good for?

Whom do you want to "educate" with this? For me, education is something entirely different, at least

It smells much more of what toy shops offer in form of primitive robot toys, trucks, cranes, and the like...I do realize though that even some grown-up representants of the male species continue to enjoy this sort of "animation".

Bye Fridger

[selden]

Fridger,

Well, it would tend to be more realistic to be able to keep spacecrafts' high gain antennas pointed toward the Earth or whatever relay satellite is being used while maintaining the appropriate cameras' viewpoints.

Actually seeing a rover spin its wheels would be interesting, too, I think.

And don't poo-poo our toys like that! Where would you be without that high voltage toy your coworkers play with?

[t00fri]

Fridger,

Well, it would tend to be more realistic to be able to keep spacecrafts' high gain antennas pointed toward the Earth or whatever relay satellite is being used while maintaining the appropriate cameras' viewpoints.

Actually seeing a rover spin its wheels would be interesting, too, I think.

OK, Selden,

I agree there might be a few cute i.e. semi-serious applications that I overlooked. But I think, really not too many...So one may reformulate my previous post in form of the question: is it worth the effort?

And don't poo-poo our toys like that! Where would you be without that high voltage toy your coworkers play with?

Yeah
Slightly more seriously: usually the basic importance of our "high-voltage toys" for gaining unique pioneering knowledge is acknowledged by governments and funding agencies to such an extent that they are ready to spend hundreds of millions of dollars for their realization...
(at least so far...)

Bye Fridger

[don]

personally, I really have trouble seeing what such animation sequences might be good for? ... I do realize though that even some grown-up representants of the male species continue to enjoy this sort of "animation".

Careful Fridger ... "grown-up representants" of NASA spend a LOT of money on these "primitive robot toys" spacecraft flight animations, every single year!

Goodness sakes alive, why in the world would they do such a terrible, horrible thing?!

-Don G.

[don]

Slightly more seriously: usually the basic importance of our "high-voltage toys" for gaining unique pioneering knowledge is acknowledged by governments and funding agencies to such an extent that they are ready to spend hundreds of millions of dollars for their realization... (at least so far...)

Hmmm, I think the governments of the world are spending just a tad more (multi-BILLIONS) on space exploration, no? And all for the same purpose you mention: "for gaining unique pioneering knowledge".

So, what's wrong with educating a kid in grade school, high school, or an idiot adult like me, as to what it LOOKS LIKE to see a spacecraft perform one of it's attitude adjustment maneuvers? Or to see a volcano erupting on Io.

On second thought, nahhh, that would be too realistic.

-Don G.

[t00fri]

personally, I really have trouble seeing what such animation sequences might be good for? ... I do realize though that even some grown-up representants of the male species continue to enjoy this sort of "animation".

Careful Fridger ... "grown-up representants" of NASA spend a LOT of money on these "primitive robot toys" spacecraft flight animations, every single year!

Goodness sakes alive, why in the world would they do such a terrible, horrible thing?!

-Don G.

Sure enough, Don,

that's a pure PR issue. NASA needs this urgently. Does Celestia need it, too?

Bye Fridger

[don]

that's a pure PR issue.

I thought most of their animations were for educational purposes. For example, the descent of Spirit was completely animated from the data obtained during the descent. This allowed everyone in the world to SEE what a REAL descent looked like, via TV of course, without ever having to physically be there.

You may call this PR, but I call it education.

-Don G.

[t00fri]

Slightly more seriously: usually the basic importance of our "high-voltage toys" for gaining unique pioneering knowledge is acknowledged by governments and funding agencies to such an extent that they are ready to spend hundreds of millions of dollars for their realization... (at least so far...)

Hmmm, I think the governments of the world are spending just a tad more (multi-BILLIONS) on space exploration, no? And all for the same purpose you mention: "for gaining unique pioneering knowledge".

So, what's wrong with educating a kid in grade school, high school, or an idiot adult like me, as to what it LOOKS LIKE to see a spacecraft perform one of it's attitude adjustment maneuvers? Or to see a volcano erupting on Io.

On second thought, nahhh, that would be too realistic.

-Don G.

Don,

the costs for particle physics experiments are at least at the level of space exploration. As an example, the estimated cost of the Large Hadron Collider (LHC) that will start operating after 2007 and is being built right now in Geneva/Switzerland is about 3 BILLION $. All other plans for future collider facilities are in the multi BILLION range.

These are all international ventures of course.

Bye Fridger