Celestia Forums

Does anyone have any info on the CMS format?

This is the roughsphere CMS data:

SphereDisplacementMesh
{
Size [ 0.9 1.0 0.95 ]
NoiseOffset [ 17 42 45 ]
FeatureHeight 0.2
Octaves 2
}

... Is there any documentation on the various properties, and are there other variables not used here?

It strikes me that this format must be more effective than 3ds or CMOD when one does not need the accuracy possible with those formats...

- rthorvald

The only documentation is the source code in Celestia.

selden wrote:The only documentation is the source code in Celestia.

Ok, thanks. But can anybody clarify this a little?

- rthorvald

Warning: the online cvs documentation says that CMS format is deprecated. Chris has no plans to use it any more, although its code won't actually be deleted.

The input parameters are defined in src/celengine/meshmanager.cpp:



The code that creates a "sphere" from the CMS definition is SphereMesh in src/celengine/spheremesh.cpp.

Why is chris no longer going to use CMS? I thought the format was quite impressive! I was thinking of using it for my own projects....

My guess is that it's just too limited. Essentially it uses "noise" to distort the surface of a sphere. It's easier to create various shapes with a more general purpose model format.

Mostly what I found impressive about it was the fact that when compressed it was almost as small as a 3ds file and without artifacts... Hopefully chris will still create a better format instead of going back to using 3ds...

Rassilon wrote:Hopefully chris will still create a better format instead of going back to using 3ds...

Ras, I think perhaps you are confusing CMS and CMOD.

CMS is about as old as Celestia is. It's a very simple format for defining distorted spheres. CMS is the format that's deprecated.

CMOD was introduced in February of 2004, in Celestia v1.3.2. It's a general purpose model description language, optimized for use with OpenGL (although it is missing point-sprite features). CMOD is the preferred format for Celestia Mesh objects, with about 1.5x the performace of 3DS models.

Yep I am... Disregard...

I have been experimenting a bit with the CMS format and I feel it does have its uses. The most useful feature of CMS is its ability to generate prototype models very easily. With only a few lines of code, a CMS-format file can generate a model that can be used as-is, or serve as a base for further work. This is not possible with CMOD.

I think the CMS format should be retained and expanded a little.

One enhancement I would like to see would be a detail level, which can be used to control the size of the individual triangles in the model. This would be an integer with 1 being the same level of detail as present, and each increment increases the number of triangles by 4. (1 = triangles * 1, 2 = triangles * 4, 3 = triangles * 16, 4 = triangles * 64, 5 = triangles * 256). This would be limited to a narrow range, perhaps 0 to 6.

The CMS format is not a computationally efficient method of representing a model, especially a detailed model. A useful tool (if it doesn't already exist) would allow someone to export a CMS model as a CMOD file, or perhaps another format like 3DS that is suitable for importing into a graphics application. Do such tools exist?

bdm wrote:One enhancement I would like to see would be a detail level, which can be used to control the size of the individual triangles in the model. This would be an integer with 1 being the same level of detail as present, and each increment increases the number of triangles by 4. (1 = triangles * 1, 2 = triangles * 4, 3 = triangles * 16, 4 = triangles * 64, 5 = triangles * 256). This would be limited to a narrow range, perhaps 0 to 6.

I have found that the Slices and Rings parameters do this. Large numbers slow Celestia down a lot and are not recommended.

Size
This is a vector, in [x y z] format. When a model is placed in a circular orbit around a parent body without rotation settings (so it is tidelocked) and with a mean longitude of 0, the coords have the following effect:

• x controls the size of the axis running through the parent body
• y controls the size of the axis running through the north-south poles
• z controls the size of the other axis (the one running parallel to the orbit - east/west)

NoiseOffset
I haven't worked this one out yet.

FeatureHeight
This controls the height of the bumps. Small numbers like 0.2 define a body that is roughly spherical with low hills, while larger numbers like 1 define a body with large hills.

Octaves
This defines the bumpiness of the model. Small values like 1 define a body with a fairly regular distortion, whereas large values like 9 define a very bumpy body. This appears to be an integer; values smaller than 1 give a spherical body.

Slices and Rings
Together these define how much detail there is in the mesh. The default value of 20 defines a blocky mesh, while 200 defines a much smoother mesh that can take several seconds to render when displayed for the first time.

Setting Slices to a low value and Rings to a high value gives a mesh that is shaped like a peeled orange. (The Slices parameter controls the number of longitude lines)

Setting Slices to a high value and Rings to a low value gives a mesh that is shaped like a pile of donuts of varying thicknesses stacked on each other. (The Rings parameters controls the number of latitude lines)

Would this be an quick and easy method for asteroid generation?

I guess this is some kind of implementation of Perlin noise then? If so, I guess NoiseOffset moves the origin of the noise.

bdm wrote:I have been experimenting a bit with the CMS format and I feel it does have its uses

Thank you for these explanations!
What i am wondering now is how memory-effective it is in comparison to CMOD. If i need a thousand asteroids, would it not be more economical to produce 10 - 20 - 30 different bodies with this than designing them in a 3d app and converting to cmod? What would run smoothest in Celestia?

- rthorvald

rthorvald wrote:

bdm wrote:I have been experimenting a bit with the CMS format and I feel it does have its uses

Thank you for these explanations!
What i am wondering now is how memory-effective it is in comparison to CMOD. If i need a thousand asteroids, would it not be more economical to produce 10 - 20 - 30 different bodies with this than designing them in a 3d app and converting to cmod? What would run smoothest in Celestia?

- rthorvald

Was also wondering...

rthorvald wrote:

bdm wrote:I have been experimenting a bit with the CMS format and I feel it does have its uses

Thank you for these explanations!
What i am wondering now is how memory-effective it is in comparison to CMOD. If i need a thousand asteroids, would it not be more economical to produce 10 - 20 - 30 different bodies with this than designing them in a 3d app and converting to cmod? What would run smoothest in Celestia?

- rthorvald

I have no firm statistics, but I believe the performance metrics are as follows:
CMS
Creation time: fast (six lines of code creates a decent model)
Rendering time: slow (Celestia must generate models on the fly)
Memory usage: similar

CMOD
Creation time: slow (can take a while to create a model)
Rendering time: fast (vertices are coded directly)
Memory usage: similar

I have no firm idea on the memory usage but I have noticed that once the CMS models are rendered, the display of those models is fast when they are displayed for the second time. This indicates that the model is stored in memory and is not regenerated each time. Therefore the memory requirements for the models would be similar.

EDIT: As for the question about smooth rendering, CMOD definitely renders more smoothly. When the CMS model has 200 rings and slices, Celestia pauses for a couple of seconds while it creates the model. 2000 rings and slices can take 20 seconds or more to render and is not recommended.

This is why I would like to see some way to convert CMS to CMOD, perhaps with a cross-platform cms2cmod conversion tool.