Improved Panoramas for Celestia

[selden]

Some 3DS models have been created which make it possible to display cubical and cylindrical panoramic pictures within Celestia.

Panoramas are pictures which surround you, giving you the impression that you are there. Since they're only pictures, they are much easier to make than full 3D models of a location.

Here are two examples: one on Mars and one (maybe) on the Earth.





A zip archive containing these models and examples can be downloaded from http://www.lns.cornell.edu/~seb/celestia/panoramas-v2.zip (500KB, 29Jan04)

For more information, please read the Web page http://www.lns.cornell.edu/~seb/celestia/panoramas.html

Many thanks to Grant Hutchison for help with the cubical model and to Andrew Tribick for permission to use one of his Terragen panoramas. And of course to NASA for the Spirit panorama.

[added 29Jan04]"panoramas-v2.zip" is now available.
The 6-cube model has been modified so that the seams at the edges of the cube's faces are no longer visible. See the Web page for details.

[Brendan]

Wow those are cool. I have been making planet maps in POV-Ray by making a texture on a sphere and putting a spherical camera at the sphere's center. Now I can make any scene and put it on the sphere 3ds model. It would be a good idea to make a program that can write ssc files to put those panoramas and other objects on the surfaces of planets and moons.
I know that it is possible to have an all sky texture, but those panoramas could be put on spheres that are floating in deep space so that you could look at the texture without having to use an all sky one.
It would be nice to use two views with one inside the sphere and the other one some distance away from it to compare the sky map that is on the sphere to the sky that Celestia shows.
It would also be nice if movement and rotation commands could affect both views at the same time to make it easy to compare the two views of the skies.
Maybe multiple panoramas in such spheres could be used with multiple views to look at the ultraviolet, infrared and radio skies at the same time. It would be even easier if different views could be grouped together so that if one is selected, all of the members in the group are selected. Then we could just group together the views from the different spheres so that our rotation commands would apply to them at the same time. We would be able to look at the same parts of the sky in different wavelengths at the same time.

Brendan

[selden]

Brendan,

I'm having a little trouble sorting out your comments: they seem to run together somewhat

However, I did just realize that it's "trivial" to set up some all-sky comparisons: define a set of panoramas that are centered within one another. Each should be ~100x larger than the next smaller one.

This much of a difference is just to minimize the distortions that are caused by viewing an inner surface from off-center: each panorama would be viewed from a viewpoint that's just outside the next smaller panorama. Smaller differences would doubtless work, too, but I suspect 10x wouldn't be quite good enough.

When you're viewing a panorama from near its center, the scale of what you're seeing is not at all obvious. A panorama looks the same whether you're inside a 1 mm sphere or a 13.5 GLY sphere.

A small problem is getting from one viewpoint to another quickly enough. But I think there are several ways to do that. Either Cel:// URLs or bookmarks could be used to provide instant changes of viewpoint.

[Brendan]

Sorry about that. It's what happens when I think of something new.
I see what you mean by having different sized concentral spheres. We could track a faraway object of interest while moving between the spheres so the view won't change much from one panorama to the next.
But what if you don't need to look at one object in particular and just want to look at the panoramas? It could still be done with Cel:// urls or scripts, can it?

Brendan

[selden]

Yup: Cel:// URLs work fine for deep space objects, whether they're OpenClusters, Nebulas, or Galaxies.

Actually, I was only visualizing how AllSky panoramas (defined as Nebulas) might look. I wasn't even thinking about what foreground objects might be in view.

[maxim]

I made some guesses for what you intended to use that 'inside' cube mesh your where talking about. Now it turnes out.

Taking a look into the future, I have to ask you for something:
I'm seeing hundreds of panorama addons with hundreds of textures mixed up with all the other planetary and moon textures. PLEASE make a proposal of a minimal tree structure for panoramas to stay into.

Something like

Code: Select all

 ... - <planet> - panoramas - models
                           - textures - lowres
                                      - medres
                                      - hires


I know what you will say - everybody can do as he like - but a proposal from the initiator himself will cause a strong synergetic effect, and probably lead to a common agreement BEFORE everybody has an own idea of how he would like it.

thanx and greets,

maxim

[selden]

Maxim,

I can imagine three different types of directory arrangements, each of which has its own advantages. (I'm showing only the directory names here.)

1. organized by astronomical body:

Code: Select all

Addons
  <planetname>
     Panoramas
          <name of panorama>
                 textures
      VTs
          <name of VT family>

2. organized by type of addon

Code: Select all

Addons
   Panoramas
       <planetname>
           <name of panorama>
                 models
                 textures
    VTs
       <planetname>
           <name of VT family>
                 textures

3. in individual folders (aka disorganized )

Code: Select all

Addons
       <name of panorama>
            models
            textures
       <name of VT family>
             textures

My system is slow enough that I can't afford to have many Addons active at the same time.
As a result, I use organization #3 for Addons while they're being used with Celestia.

I tend to use organization #1 for Addons that are inactive, but I also use organization #2 when I'm working on designing a "support structure" -- like this one. I think the choice between them has to depend on the type of project you're working on: one that's oriented toward an astronomical goal or one that's oriented on a "programming" goal.

Also, I usually don't have an explicit directory named "Panoramas" or "VTs". Sometimes I do try to keep things organized by having that extra level of directories, but I find it hard to keep doing that.

Sorry: I'm not going to be a lot of help here

[maxim]

Organization #1 seems a quite good one to me.

My system is slow enough that I can't afford to have many Addons active at the same time. As a result, I use organization #3 for Addons while they're being used with Celestia.

Ah, as I took some effort in organizing my extras directory, I find it quite complicated copying things around. So I tend to offcomment (with a .NO extension) what I don't need:

Code: Select all

C:\Programme\Celestia\extras\real\solarsystems\sunsystem\moons:

<dir> earthmoon
<dir> models
<dir> textures
minormoons.ssc
numberedmoons.ssc.no
tiny_moons.ssc.no


This easily leads to a lean runtime system, althought it still covers a lot of space in the systems volume (which could become problematic).

Sometimes I do try to keep things organized by having that extra level of directories, but I find it hard to keep doing that.

Yes, I think that's a common problem for everyone, not only on computer desktops. I helped myself with a trick that seems to work until now: I have two more main-level directories inside my extras folder. One called 'workspace' for things I'm actually working on, and one called 'new ones'.

I put everything I get into 'new ones' until I feel that I have to clean up again. Clean up means I move things just over into my well organized multilevel structure. Having a lot of things inside 'new ones', it gives the impression of cleaning up will be a valuable effort - as opposite to only on or two addons to deal with. Simultanouesly I sometimes detect several addons that 'naturally' seem to group together - thus a new level of subdirectories is born.

All in all the effort for keeping organized stays considerably low this way.

maxim

[selden]

I've improved the 6-cube model, which accepts 6 separate images: one for each side of the cube, so that the seams along the edges are no longer visible.

For the URLs, see the posting at the beginning of this thread.

[Rassilon]

I think this would be a far better implimentation if it were invisible from the outside....and also would cut out all outside objects from visibility...For smaller panos it is nice but for nebs it would be visible from the earth and disrupt the visual reality of the actual nebula...like the last addon I did for Celestia...Inside nebs you see a black sphere...

[selden]

Ras',

I think I mostly agree.

I've left them as surfaces facing inward so that the correct alignment is evident. It'd be easy enough to make the bounding object accept a texture so that the user can make that choice. With its normals pointing outward, it'd be invisible from the inside, where that's appropriate.

Unfortunately, the only way I know to make the inside surfaces "invisible" is to block the observer's view of them with an opaque surface, whether with a texture or with a predefined opaque material. I don't know of any way to make the entire body invisibly transparent.

A nebula's exterior is essentially invisible if it's black. of course, but that's not necessarily the case for an SSC object.

An alternative is to make it invisibly tiny, I suppose, but you'll still see the object when you GoTo it. Once you're at its center, the "actual" size is irrelevant.

Another improvement would be to make transparent the upper regions of SSC objects on the surfaces of planets so Celestia's sky can be seen. That's easy to do with an alpha channel for Nebula objects but I dunno how to persuade an SSC object to treat the alpha channel as opacity instead of specularity. When I've tried this in Anim8or, the characteristic didn't get exported to the 3DS model.

That was before I realized that AN8 files are just plain text. Maybe something can be done by editing one of them appropriately.

[Rassilon]

Giving in to some special coding, Celestia can do this by assigning these objects a class and a bounding radius. The object would remain invisible or in coding terms, unrendered until the bounding radius is crossed...

transparent areas of a mesh can be done by using the gimp with true alpha 0 capabilities. Apply the texture on the diffuse and opaque channels. Make sure opaque is set to 99% instead of 100%. The areas that are transparent will be invisible enough to see the sky. In my experience with panoramas it is usually best to use a cube map versus a sphere...cube maps when properly mapped can produce higher resolution images without the cost of loading one super large image...The Doctor Who Universe program I recently released makes use of this 6 1024 squared textures for the skybox and loads 6 times faster than one say 4096 x 2048 size sphere map which would be the best available comparible resolution...Besides skyboxes when properly textured will not leave seams or pole pinching effects...