Sorry, we aren't looking for beautiful people to advertise Celestia. :-)
Celestia is a real-time 3D astronomical visualization program. You can learn more about it at http://www.shatters.net/celestia/. In addition to spherical planets and moons, Celestia can display models of objects that have been designed using 3D modelling programs: irregular asteroids, magnetic field lines, telescopes, spacecraft or even buildings and vegetation. It can't do smoke, though.
This is a description of some of the things that I've learned about creating 3D models for use with Celestia. This document is by no means complete.
Celestia can display 3D models that are in any of three different formats. They can be either 3DS or one of Celestia's two proprietary formats, CMS or CMOD.
3DS is a binary file format first used by the modelling program 3D Studio Max. The current version of that program uses a different file format called MAX. Celestia does not understand MAX format. 3DS models can be created by most of the available modelling programs if you select one of their Export options. Alternatively, there are utilities to convert other proprietary formats into 3DS.
CMS is a "deprecated" model format used to tell Celestia how to draw irregular blobs, usually asteroids.
CMOD is a versatile model format optimized for use with OpenGL, the 3D language used by Celestia. It has both ASCII (text) and binary versions. The CMOD format is relatively verbose: its files are significantly larger than their 3DS counterparts. In spite of this, Celestia can draw CMOD models about 1.5-2x as fast as it can draw 3DS models.
A more detailed description of the CMOD format is available at http://www.lepp.cornell.edu/~seb/celestia/cmod_format.html
Different versions of OpenGL are included with most
computer operating systems and are designed into
the hardware of all modern 3D graphics cards.
Although some of Celestia's eye-candy requires the most recent
version of OpenGL, v2.0 or later, 3D models can be shown on systems
with minimal OpenGL implementations, including v1.1.
CMOD conversion and export modules:
cmodfixare available at http://www.shatters.net/~claurel/celestia/cmodtools/
3dstocmodtranslates 3DS models into the ASCII CMOD format.
cmodfixtranslates ASCII CMODs into binary and does other optimizations.
export_cmod_plugin.a8s v023is available at http://www.lepp.cornell.edu/~seb/celestia/files/export_cmod_plugin.a8s
export_cmod_plugin.a8sexports 3D models from Anim8or
export_cmod_plugin.a8s v025is available in http://www.lepp.cornell.edu/~seb/celestia/files/export_cmod_plugin_v025.zip
export_cmod_plugin.a8supdated exporter of 3D models from Anim8or
Cartrite, a member of the Celestia Web Forum, has written a script to export CMOD models from Blender. That script is available on the Celestia Web Forum at http://www.shatters.net/forum/viewtopic.php?f=6&t=14297
Many 3D modelling programs are available. Some are commercial, some shareware and some can be downloaded for free. Many of the commercial vendors provide obsolete versions of their software packages at reduced prices or even for free.
The list below is incomplete.
The choice of modelling software is very much a personal one. Although Anim8or has relatively limited functionality compared to most of the other packages, I found that its user interface was the easiest for me to understand and learn.
Because of the format's simplicity, several people have written their own private utilities to generate CMOD models for Celestia, using Mathematica, Fortran and other programming languages.
When drawn by Celestia, 3DS models usually will not have the orientation that you expect. Instead of standing upright, they'll be lying on their sides: objects are rotated 90 degrees around their X axis. (See below for why this happens.)
There are several ways to work around this problem. None are particularly satisfactory.
Orientation [-90 0 0]
It is very unlikely that Celestia will be modified at this late date to change this behavior. Too many Addons have been designed with this rotation included.
The author of Anim8or had this to say about the situation:
When exporting from Anim8or to a .3ds file I transform the coordinates into .3ds coordinates as follows: x' = x; y' = -z; z' = y; This transformation is what is needed to make Anim8or exported to .3ds format models load correctly in 3D Studio Max.
As a result, you can expect to see a similar rotation in Celestia when using other modellers which try to be compatible with 3DS Max. The objects aren't lazy, it's just that Celestia does not try to emulate 3DS Max.
This is one of the reasons I decided to write my own CMOD export script for Anim8or. Scripts were a new cabability in in Anim8or v0.95, which was first available for beta testing in September, 2006.
Because of the format's simplicity, several people have written their own private utilities to generate CMOD models for Celestia, using Mathematica, Fortran and other programming languages. For a decription of the CMOD format, see cmod_format.html.
3dstocmod translates 3DS models into the ASCII CMOD format.
are available at
Some 3D modelling programs
allow plugins to be written
so they can export models to any format. Anim8or and Blender
provide this feature, for example.
[back to Contents]
name.cmod_mesh, which must be concatenated.
export_cmod_plugin_v025.zip( v0.25, 14KB, updated 29Oct15) exports 3D models from Anim8or
Changes in v025:
The very first time you use a script with Anim8or, you have to tell Anim8or where it should look to find them. From then on, Anim8or will remember that location. All scripts in that directrory will be automatically loaded when Anim8or starts.
SpecularColor [1 1 1]
Note: Anim8or development was on hiatus for a while, but new versions were released starting in late 2014. Build 1185 works well for me under Windows 7. (For reasons unrelated to Anim8or, one should avoid Windows 10 if at all possible. Its "telemetry" features are a serious invasion of personal privacy.)
[back to Contents]
Cartrite, a member of the Celestia Web Forum, has written a script to export CMOD models from Blender. That script originally was available on the Celestia Web Forum, but the Forum is no longer available. You should be able to find a copy of the script by doing a Web search. However, it has not been updated to be compatible with the current version of Blender.
This reduces the total number of materials and point lists needed.
Usually a separate set of materials is maintained for each mesh
or solid within a model. If the separate meshes use identical
materials, merging the meshes will eliminate those duplicates.
(Anim8or has a "Build/Join Solids" command which does this.
Chris is hoping to extend the functionality of
cmodfix to merge identical materials, but this has not
yet happened as of September, 2006.)
Note: If you merge meshes that have different types of materials, use cmodfix only to convert the merged result into binary format. Do not apply any of its other functions. They can handle only a single material per mesh. The results will not look like what you want.
Default bodies usually include many more divisions than necessary. For example, Anin8or's default cylinder has 8 Latitude divisions. Usually only 1 is needed.
There have been several discussions on the Celestia Web Forum about improving models for Celestia:
Celestia versions before v1.5 allowed a texture map image file only for diffuse materials. The other materlal types could have only color and intensity modifiers. V1.5 adds support for texture map image files for specular, emissive and normal materials.CMOD models do not support the following types of materials, which are supported by Anim8or:
Chris made postings to the Forum and the developer's list about how the CMOD material definitions have been enhanced for v1.5. I've quoted him on the Web page http://www.lepp.cornell.edu/~seb/celestia/cmod_format.html
None of the other SSC surface texture statements are applied to Mesh objects. The surface textures corresponding to them must be specified by defining materials in the model.
A confusion factor is that an SSC Atmosphere definition isn't a texture, and a Cloud definition uses its own spherical mesh. As a result, the SSC Atmosphere and Cloud declarations do work with models, although they still have some bugs that Chris is planning to fix.
The format of normalmaps seems to be finalized for v1.5 as of 22Oct06. Normalmaps in PNG, JPG and DDS format must be provided in "normalized" form (vector length of 1). Normalmaps that use the new DXT5_NM format must be provided in a file with its filetype set to .dxt5nm. They're automatically normalized.
There are utilities that can translate bumpmaps (heightmaps, actually) into RGB normalmaps and utilities to translate RGB maps into DXT5_nm maps.
Some translation utilities are available in Photoshop plugin format from Nvidia. That format is used by most Windows paint programs, not just Photoshop. I don't know if Mac paint programs can use the plugins. I've never used any of the plugins, myself.
An article by Nvidia about bump map compression is at http://download.nvidia.com/developer/Papers/2004/Bump_Map_Compression/Bump_Map_Compression.pdf The Nvidia utilities are at http://developer.nvidia.com/object/nv_texture_tools.html Their standalone utilities are for Windows.
ATI has some utilities at http://www.ati.com/developer/sdk/radeonSDK/html/Tools/ToolsPlugIns.html
Neither company's conversion utilities require a graphics card.
Celestia v1.4.1 and eariler require that surface texture images be a power of two on a side: 512x256, 1024x1024, 4096x2048, etc. This restriction is designed into most 3D graphics cards.
Anim8or and most other modelling and software-rendering programs can use any size of surface texture images since they don't need to do high quality real-time graphics. They generate high quality graphics using relatively slow software routines that don't have the limitations imposed by the 3D graphics hardware.
Celestia v1.5.0 and later will allow images that are non-power-of-two on a side. However, this will work best only on graphics cards which support those sizes. If the graphics card does not include support for non-power-of-two, Celestia will shrink the images so that they are a power of two on a side. The results of this scaling will not be as good as if the images were designed to be a power of two to begin with.
Celestia can only use PNG, JPG and DDS texture images. Celestia uses the Alpha channel of a PNG or DDS "diffuse" or "emissive" surface texture image as an opacity channel. JPG does not include an Alpha or opacity channel. (In some cases .BMP image files will work. However, Celestia implements only a very small subset of .BMP functionality, which is likely to cause problems.)
Anim8or can only use JPG, GIF and BMP texture images. Anim8or can use either an Alpha channel in a GIF image or a separate texture for opacity information.
Suggestion: Consider using JPG images for most model development with Anim8or. The files will be smaller and faster to load. Don't expect its objects to look quite like they will in Celestia. This means that you probably should consider using a conversion script to change a PNG with alpha channel into two separate image files: one for the coloration and the other for opacity.
Note: JPG and DDS image compression algorithms damage the images by reducing the resolution and reducing the number of colors that are in the images. Any painting of textures should either use a format with no compression (TIFF, TGA, BMP and some proprietary formats used by paint programs) or one with lossless compression (PNG and some proprietary formats used by paint programs). Only convert the surface texture to JPG or DDS for the final distribution.
I don't know what limitations other modelling programs have in the type of image formats that can be used for surface texture maps.
"UV Mapping" is the process of placing (mapping) images onto model surfaces. In addition to the X, Y and Z coordinates of the vertex itself, U and V coordinates usually are included as part of a model's vertex description. They specify what location in a surface texrure image is associated with each vertex of the mesh.
Most 3D modelling programs include UV Mapping commands, but separate programs also are available.
Explicitly define materials to have an opacity of 0.99 or less if they are going to have transparency effects applied to them by surface texture images with Alpha channels.
Celestia has always had problems properly depth sorting transparent materials. Too often transparent surfaces look like they're behind opaque surfaces when they should be in front of them.
Celestia only does a single pass through the list of objects when depth sorting them. To correctly depth sort transparent materials, a multipass algorithm would have to be used, using a lot more CPU time and slowing Celestia's frame rate. Chris is hoping to implement a multi-pass algorithm in a future major release of Celestia, but that hasn't happened as of Celestia v1.6.0.
Celestia has the most trouble depth sorting materials which are declared to be opaque within the model, but which use a diffuse surface texture image with an Alpha channel to implement transparency. If you set the material's opacity value to a value less than 1.0 (fully opaque) then Celestia can do a better job of depth sorting. Setting the opacity to be 0.99 helps a lot. It notifies Celestia that the material needs to have special consderation while depth sorting, but leaves the densest ares of the surface texture image effectively opaque.
Use "blend add" to avoid depth sorting problems in Nebulae.
Celestia does not depth sort DSC Nebula models at all. The models are drawn in the order that it encounters them in their DSC catalogs and it draws their surface triangles in the order that they're found within the model itself. This can cause strange visual effects when observing 3D Nebula models from different directions.
Celestia v1.5.0 (and later) implemented additive blending in the material
definitions of CMOD models.
You can specify either
When blend add is specified, the colors of all of the surfaces at a given point are added together to create each pixel. As a result, depth sorting is irrelevant. It's as if all of the surfaces of the model were translucent. This works fine for emissive nebulae. It doesn't work at all for opaque dust clouds.
If you don't tell me that something's missing, unclear or wrong, I can't improve it.