Celestia Forums

Hi Chris,
I would like to convert some old models from 3ds to cmod. I read through the readme that comes with the cmod tools, but I am unsure of which options are the most appropriate. Can you give some general guidelines about which options should be used to make the models come out best? The models are older and less complicated than some we have seen recently, so I probably want to err on the side of detail rather than rendering speed.

Thanks in advance.
Joe

The options that you should use are:
--uniquify
--normals
--weld
--optimize

You should also specify a smoothing angle, but the angle you pick depends on the model. 45 degrees is reasonable for a spacecraft; 180 degrees (i.e. smooth all edges) is better for asteroids, which shouldn't have any sharp edges. You can choose to use the --binary flag to generate a binary cmod--it's substantially smaller than the ASCII version.

Here's the complete command line:



Or, using the short versions of the flags:



--Chris

I would like to use Blender to generate some spacecraft for my Celestia Add-on.
Is it possible to convert the blender file in cmod?
Thank you

Guest-
You should output the file in 3ds (3D Studio Max) and then use the cmod GUi utility at http://celestiamotherlode.net/catalog/utilities.html to convert it into cmod using the guideline that Chris just gave.

Cheers,
Joe

Hi,

Thanks for the plug on the GUI Joe! To the guest above who would use it: when i was testing it and all of the variants of the cmodfix command parameters it seemed to me that the -b or -a (--binary or --ascii) params did not work with the others so i coded the gui to make them mutually exclusive with the rest. Hence, the GUI equivalent of the aforementioned command by Chris, cmodfix -u -n -s 45 -w -o -b input.cmod output.cmod, will not be generated. You will have to run 2 commands - one with all the other params first and then one with the conversion to binary like so:

cmodfix -u -n -s 45 -w -o input.cmod output.cmod

and then

cmodfix -b input.cmod output.cmod

Well, the GUI equivalent, anyway.

I have since tried the very command from above and it does indeed work. This means I will be changing the utility to reflect this and will make it work accordingly. I am sorry for the inconvenience and i must have just issued the commands incorrectly as i kept getting the -usage message.

In the meantime, it should work the way i mentioned above and still be easier than typing it all in in DOS.

Also, there is no capability in the GUI for renaming the output file. It will replace the original file with the fixed one.

These aforementioned shortcomings, the ability to process a list of files rather than just one, and tool tips to highlight the meanings of the different fix parameters are high on the list of corrections and upgrades i am working on...I will make them so as soon as possible. Until then, I hope the tool as it stands is of some use.

Apologies and Thanks,
Sean

Hi!

I have a new version of the GUI tool for converting models. It allows for the selection of a new file name and for using the -b or -a options with other options for the fix command. It is available from me at the moment - email me at smbika@aol.com and i will send you a new zip file. Soon i will upload it to the motherlode. No tool tips or multiple files yet - sorry .

Thanks,
Sean

It might be on the utilities page in the next couple of days but you can get it here - http://www.celestiamotherlode.net/creat ... odv3-1.zip now if you like.

Thanks,
Sean

smbika wrote:It might be on the utilities page in the next couple of days but you can get it here - http://www.celestiamotherlode.net/creat ... odv3-1.zip now if you like.

Thanks,
Sean

Cheers, I'll give this a try.

Just had a go at converting the Helios UAV 3ds model using;

Convert 3ds to cmod,
Weld vertices,
Generate normals,
Uniquify,
Optimize,
Smooth Angle 45 deg.

Result, seems to be OK.

Model looks fine and the frame rate has definately improved.

Only 'prob' is that the file size has increased from 3.5MB for the old .3ds model to 22.5MB for my .cmod version

regards,
TERRIER

For now I am going to claim the same incredulity as you. Seems like it should have been a TAD smaller as the cmod format is supposed to be more efficient for Celestia. This does not logically mean, however, that the size would be smaller - rather the format itself might lend itself to more efficient processing. Just for grins, try doing the same thing with the actual DOS tools and see how big the files are. I will do the same.

Thanks,
Sean

PS - glad it works otherwise!

Also, try using the convert to binary option - i am sure it will reduce the size some - but it still might be bigger than the 3ds.

----------------
Just added:

Yup. I tried it the hard way - command line - and they indeed are humongified when you convert - Kleopatra.3ds went from 91,633 bytes to 981,534 bytes when converted to ascii cmod format. When I converted to binary it went down to 441,992 bytes.

TERRIER wrote:Only 'prob' is that the file size has increased from 3.5MB for the old .3ds model to 22.5MB for my .cmod version

The file will be a lot smaller if you convert it to a binary cmod. However, it's still likely to be slightly larger than an equivalent 3ds file, the cmod contains surface normals, whereas normals must be generated at load time for 3ds files.

--Chris

Yep, I've tried converting to binary output and I've got the Helios file size down to 4.2MB....and it still looks fine.

Might experiment with the smoothing angle tomorrow.

cheers,
TERRIER

Hi,
Sorry to pick this thread back up after it has lain dormant, but I am actually starting on this project now. I just noticed that no one mentioned the "Generate Tangents" option, so I wondered what this is for. Any help?

Thanks,
Joe

alphap1us,

No apologies necessary...as far as I know, which is this blurb in the readme.txt that comes with the command line utilities on Chris' download page ( http://www.celestiaproject.net/~claurel/celestia/cmodtools/ ) or the LicenseInfo.txt on the motherlode download page
( http://www.celestiamotherlode.net/creat ... odv3-1.zip ),
Generate tangents refers to:
Tangents are required in order to apply bump maps or other per-pixel lighting
effects to a cmod. The tangent vectors are generated from the vertex
normals and texture coordinates--both must be present in order to create
tangents.

I have not tried the option myself as regards looking for practical results, but I am sure in the context mentioned above it is useful.

Hope that helps,
Sean

alphap1us wrote:Hi,
Sorry to pick this thread back up after it has lain dormant, but I am actually starting on this project now. I just noticed that no one mentioned the "Generate Tangents" option, so I wondered what this is for. Any help?

Tangent vectors are used for bump mapping. The 'generate tangents' option derives a surface tangent for each vertex based on the geometry and texture coordinates stored in the mesh. Since Celestia can't yet apply bump maps to meshes, the option isn't very useful at the moment. It won't be long, though . . . I have a 10 day break from work that starts on Friday.

--Chris

So while I am at it, should I use this option, so that when this feature is implemented, the bumpmaps will automatically become available? Are there any downsides to this approach, like a large size increase?

Cheers,
Joe

alphap1us wrote:So while I am at it, should I use this option, so that when this feature is implemented, the bumpmaps will automatically become available? Are there any downsides to this approach, like a large size increase?

Extra information is added to the file, so yes, it will increase the size. Like a normal, a tangent is stored as three single-precision float values, so it will make the file larger by 12 bytes per unique vertex. Thus, tangents should only be generated for meshes that will have bump maps applied.

--Chris

Let me also add that the cmod format will at some point be enhanced to allow separate bitangent vectors to be specified per vertex. Right now, the bitangent is assumed to be the cross product of the tangent and the normal, thus assuring an orthonormal surface space basis. But, for certain lighting effects, it's desirable to have non-orthogonal tangent and bitangents. First however, I need to get basic bump mapping working . . .

--Chris