I'd like to draw your attention to a fact concerning the use of model files (3ds) in Celestia.
Please pay attention and be very careful when you modify "3ds" files with Hexadecimal editors or other similar tools, whenever you want to change the name of texture files: as far as I can see, it happens that these tools don't correct all the relevant records in the file.
The worst thing happens when you "add" bytes to the file (for example when you want to "correct" a shorter name with a longer one): in such a case the file becomes thoroughly corrupted.
I have started examining 3ds files with a hexadecimal reader and a good knowledge of the files: "3ds" files are record based files, each record made of these fields:
- a marker (a specific 16 bit pattern that describes the record)
- the length of the record itself (a long value, 32 bits) (marker+length+data)
- the record data
I found that many Celestia "3ds" files cannot be opened with Anim8or
: so I started reading them with a Visual Basic parser (found in internet) and I always found that the culprit is one of the fields that is corrupted. 
Perhaps Celestia doesn't complain about these strange records : I do wonder how it can show a model correctly, when neither anim8or nor the VB parser succeed in this task
As an example I read the file "graticule-blue.3ds" from Selden add-on (I have not yet tried it in Celestia...) : the parser bails out after reading the name of the texture ("graticule-blue.*") at the offset 0x170 of the file.
This file can't be read because its length (0x1722 bytes) is wrong as compared with the length in the first record : at offset 0x2 you can read 0x171E, perhaps the original length of the file. (in this case we have : marker=0x4d4d, len=0x171e, data= the file itself!)
The worst thing is now that the string ("graticule-blue.*") is inside a record (starting at offset 0x16A, with the marker=0xA300), whose length is 0x13.
In such a record the string is practically truncated to a otherwise useless "graticule-blu" without any extension at all!
With this in mind, I can suppose that Celestia simply "searches" all the wanted records (a lot of them!), without worrying about "previous" or "following" records or record lengths, without parsing the file... and without bailing out!
This behavior is obviously correct: the important is that you can see the object in Celestia.
BTW I don't know if 3DStudio (or other 3D program) can import those files...
I will further investigate
other situations in which also Celestia has a strange behavior showing objects: I'll be clearer if you are interested in this matter. 
Good bye
Pierluigi
8.3 convention. 
program I have ever used and I find it VERY useful in my hobby !!