Phoenix lander on Mars

[Marco Klunder]

I read the http://www.shatters.net/forum/viewtopic.php?f=6&t=12505&p=104651&hilit=phoenix+lander#p104651 post about Phoenix on Mars, where the SSC code is worked out, but a model is missing.

Unortunately, I'm not familiar with 3D modelling yet, but I found a pretty good Phoenix Google 3D model (free download) at http://sketchup.google.com/3dwarehouse/details?mid=181b88faf230a1a133eb1cd2434e26fc&prevstart=0. Using Google Scetchup 7, it's possible to export this model as a COLLADA 1.4 (.dae) file, which can be imported in Blender. So far so good, but here is where it ends for me (yet) ...

In Blender, I tried to export the model as a .3DS model, but that results (on my system with my actual knowledge about 3D modelling ), in an incomplete model in celestia, missing texture files etc.. I also do not now how to split up textures and the model in Blender, according the ..\models and ..\textures directory structure in Celestia.

I also tried to use the blender-cmod-exporter-2 script of Cartrite at http://www.shatters.net/forum/viewtopic.php?f=6&t=14297&p=117887&hilit=CMOD+Blender#p117887. That however results in a Python script error, check console message .

I'm not especially asking here for help on my lack of knowledge about 3D modelling. That's something I have to work on. But knowing there are lot's of gents active on the forum with expert knowledge about 3D modelling, we prabably have an opportunity now to add a model of the Phoenix lander as an add-on to Celestia.

So who can help me to to get the Phoenix lander out of Blender as a CMOD or 3DS textured model with the appropriate SSC code so we have a Phoenix model available in Celestia (although the real lander has finished its work on the red planet now, but of course still stands there)

[bh]

Can you import into Anim8or?

[Marco Klunder]

The picture below shows the Phoenix screenshot in Blender after the .dae import.

Phoenix_blender.jpg

In Blender I selected Draw type: Textured, then pressed the [Ctrl+I] keys, to select inverse, followed by the .3ds export.

After the export, only a .3ds file is available and there are NO texture files exported.
This results in lots of messages, when importing the .3ds file in Anim8or like: Can't open texture file: texture10.jpg
The result is an import of Phoenix in Anim8or as shown below.

Phoenix_anim8or.jpg

On the other hand, I have all texture files available from the .dae export in Sketchup (texture0.jpg - texture16.png), but I do'nt now where to place them for a correct import, nor I don't now where to place them as an add-on in Celestia. Again that's my current lack of knowledge with this 3D rendering software.

Marco

[bh]

It's been so long since I did anything with Anim8or, it's not for mac unfortunately. You can assign textures to various meshes and even parts of meshes quite intuitively I remember.

I think Celestia (still) only recognises image files for textures at a certain ratio... ie.. 1:2, 2:4 ect... there are others here who are a lot more knowledgeable than me on these matters!

If you open one of my shuttle models with Anim8or you will see how the textures have been assigned.

Good luck. Looking forwards to the finished model.

[selden]

Marco,

Anim8or needs the texture files to be in the same directory with the model file.

When the model is used with Celestia, though, the files have to be the Addon's \textures\medres\ directory. I.e., you'll have to have two copies of all of them while you're working on the Addon. (3DS files don't have room for any directory information, only for the texture's name.)

Also, make sure that the file names on disk are spelled with the same case as are used in Anim8or's materials entries. Anim8or won't complain, but different case usage will make the textures unusable when the final Addon is used with Celestia under Linux.

As BH says, you'll need to resize any texture images which aren't a power-of-two on a side. (256x512, 512x512, 512x1024, etc) This is a limitation in most graphics cards. Resizing won't make any difference in how they map onto the model, though. Anim8or doesn't care what the sizes are since its surface texture mapping is done in software, not realtime 3D.

[Fenerit]

After the export, only a .3ds file is available and there are NO texture files exported.
This results in lots of messages, when importing the .3ds file in Anim8or like: Can't open texture file: texture10.jpg

Supposed here you don't have such message for the texture0.jpg, I wonder whether it could be caused by the textures names beyond the 8+3 format, that some 3DS importers doesn't recognize (texture10.jpg is 9+3 and so on). I don't know Blender very well, but would have be a tool like the colour picker that get texture/colors informations when picked upon the relevant mesh. Once accomplished such a operation for seeing what is the name of the texture mapped, you must rename the texture with a 8+3 name and then assign it newly to the mesh. Make this operation is for all the texture and then save as 3DS. At this point the Anim8tor 3DS importer "might be" recognize them.

EDIT LATER:

Ops! Cross-posting.

[Marco Klunder]

Anim8or needs the texture files to be in the same directory with the model file.

Understood, and implemented.
That reduced the import messages of phoenix_lander.3ds in Anim8or a lot, but NOT ALL were gone.

Supposed here you don't have such message for the texture0.jpg, I wonder whether it could be caused by the textures names beyond the 8+3 format, that some 3DS importers doesn't recognize (texture10.jpg is 9+3 and so on).

Messages are still produced now for:
texture11.jp
texture7.png
texture13.jp
texture16pn
texture12.jp
texture14.jp
texture15.jp
texture10.jp

1) except texture7.png , these are all the texture files numbered with 2 digits (9+3 format and texture7 is a .png file-format),
2) except texture7.png the last letter "g" is not present in the message,
3) renaming the *.jpg to *.jp does not solve anything.

On the other hand, we we are one step further now, see the result below in Anim8or:

Phoenix_anim8or.jpg

Also, make sure that the file names on disk are spelled with the same case as are used in Anim8or's materials entries. Anim8or won't complain, but different case usage will make the textures unusable when the final Addon is used with Celestia under Linux.

As BH says, you'll need to resize any texture images which aren't a power-of-two on a side. (256x512, 512x512, 512x1024, etc) This is a limitation in most graphics cards. Resizing won't make any difference in how they map onto the model, though. Anim8or doesn't care what the sizes are since its surface texture mapping is done in software, not realtime 3D.

Once accomplished such a operation for seeing what is the name of the texture mapped, you must rename the texture with a 8+3 name and then assign it newly to the mesh. Make this operation is for all the texture and then save as 3DS. At this point the Anim8tor 3DS importer "might be" recognize them.

OOPS ... And I thought we probably could implement an existing model of phoenix quite easy as an add-on for Celestia

[selden]

The files named .jp probably need to be renamed to be .jpg for Anim8or to be able to recognize them.

Anim8or does not support .png format, although Celestia does.
I usually convert .png to jpg for use only with Anim8or and use the equivalent .png images with Celestia.

I'm assuming "texture16pn" is a typo. It should be "texture16.png"

[Fenerit]

Supposed true also by me what Selden has said, you must convert the png to jpg and rename such a unrecognized texture in 8.3 format (e.a text10.jpg, text11.jpg...) That the problem can be such is seen by the truncation of the entire file name as 8 + 3.
8 + 3 = 11 as well as 9 + 2 (texture13.jp, texture15.jp...) For doing this in Blender, either follow the "colour picker" way, if any, or do change the texture name within some textboxes activables by selecting the relevant mesh. For example, by selecting one of the two "platform" and so on for the nexts meshes. BY CAUTION: probably the model is hierarchyzed, so DO NOT SPLIT the hierarchy, just navigate into it toward the meshes you need to change the texture name; otherwise the exporter will export just the selected mesh, not the entire model, and you must "select all" again.

[Marco Klunder]

I'm assuming "texture16pn" is a typo. It should be "texture16.png"

Yes this was a typo. texture16.png is correct.

As BH says, you'll need to resize any texture images which aren't a power-of-two on a side. (256x512, 512x512, 512x1024, etc).

How do you do such a thing without deformation of the texture itself ?

tex14_small_copy.jpg

Resizing the above texture14.jpg will normally result in a 790 * 1024 dimension. But 790 is not a power of 2, so the deformation of the texture can be unacceptable when you must bring 790 to 1024 pixels (e.g. the NASA logo), or is there another way ... ?

Supposed true also by me what Selden has said, you must convert the png to jpg and rename such a unrecognized texture in 8.3 format (e.a text10.jpg, text11.jpg...).

I will give it a try. First need to learn more about Blender to do so ...

Marco

[Fenerit]

.
.

How do you do such a thing without deformation of the texture itself ?

tex14_small_copy.jpg

Resizing the above texture14.jpg will normally result in a 790 * 1024 dimension. But 790 is not a power of 2, so the deformation of the texture can be unacceptable when you must bring 790 to 1024 pixels (e.g. the NASA logo), or is there another way ... ?

.
.

For the image above, which seem seam, is easy and is matter of photo-retouch. You resize to 1024 x 1024, make a copy of it as png and then - after a rendering - watch where the NASA logo falls along the mesh. Then cut off the NASA logo from the original and paste it over the new resized texture in the due position. It will be a new layer; then erase the redundant gold color that sorrounding it. This procedure work because the mesh is flat, so you don't have distortions.

[selden]

As BH says, you'll need to resize any texture images which aren't a power-of-two on a side. (256x512, 512x512, 512x1024, etc).

How do you do such a thing without deformation of the texture itself ?

The image does get deformed, but that distortion doesn't matter. Models map their textures by specifying proportionate locations, not by specifying specific pixel locations. By this I mean that when a model specifies that a particular x,y position within a texture is to be mapped to a particular vertex in the model it specifies the x and y locations within the texture using a value between 0 and 1 -- where 0 corresponds to the left or top edge of the image, 1 corresponds to the right or bottom edge and 0.5 is in the center. As a result, when you scale a texture image that's 100x180 to be 128x256, the reshaped texture image is still placed properly on the model.

[Chuft-Captain]

Marco,

As a picture usually is worth a thousand words, here is a simple example in pictures.

In my current re-working of The Rungworld, I decided that a groove was required where each giant rung rotates in the ladder structure:

ladder114.jpg

Needless to say, it must be perfect circle (as the consequences of it not being so would be rather dire for the inhabitants).
The problem is that the relative proportions of the ladder mesh are not a power of 2. This makes life a little difficult.
As it's easier to draw a perfect circle than to draw the perfect ellipse on a power of 2 texture, the texture instead starts it's life in the proportions of the target mesh:

inside.png

and then is re-scaled to have the power-of-2 proportions which Celestia requires:

inside.jpg

Celestia then re-stretches this texture back to the proportions of the mesh.
(...and because the texture started it's life in the correct proportions of the mesh, then the circle is perfectly formed when the ellipse is stretched out to the mesh in Celestia.)
There are a few other issues relating to UV mapping in your modeling tool, but that's the basic principle.
Hope this example makes it clear.

CC

[Marco Klunder]

I think I begin to learn more and more on this modelling and although I'm not there yet where I want to be, I'm enjoying it

Concerning the stretching and restretching of textures, a following question:

When Celestia restretches the images, is it also true that it stretches "undersized" textures to the real format?

What I mean here is the following:
One of the textures for Phoenix is 1813 x 1068 (1.94 MP).
Resizing it to a power of 2 size means 2048 * 2048 (4.19 MP). This way, models can become very large is size .
Resizing to 2048 x 1024 (2.1 MP) will be far more effective concerning the total size of the model, but formally, 1024 is a bit to small. Does Celestia have the ability in this case to stretch this "undersized" texture to the real size in the model?

Second question:

... it could be caused by the textures names beyond the 8+3 format, that some 3DS importers doesn't recognize (texture10.jpg is 9+3 and so on).

We discovered in the above posts that Anim8or is expecting this 8+3 texture name format, but is that also an issue for Celestia itself?
This because I started migrating the the model from Sketchup to Blender and because bh asked if the model could be imported in Anim8or, this Anim8or 3D program became involveled, having the texture name 8+3 restriction (and the .png restriction but Celestia itself accepts .png textures).
So are we talking on this point about a 8+3 restriction of Anim8or or does this 8+3 restriction also apply to Celestia ?

As I said, each time during this post I begin to learn more and more on modelling an me myself am als currious to see the first results of this all on Mars in Celestia

Marco

[selden]

The actual size of the texture image doesn't matter. The 3D graphics card stretches or shrinks it to fit. However, if you look closely at a surface which has a small texture, it will look blurry. Large textures look better when your viewpoint gets close to them. Some people prefer to use DDS surface textures because their files are small and load quickly, although they don't look quite as good as a PNG with the same image size.

Anim8or and Celestia both can use texture image files with long names. I have created many models in Anim8or which use textures with long names. (I usually use CMOD models, so I just now verified that Anim8or can export 3ds models which include long names.)

The 9.3 short names seem to be a limitation of the Blender export script. Once you have imported the model into Anim8or, you can specify a different texture file with a different name, as long as you want.

Suggestion: do not use spaces in file or image names. They cause problems for other programs. Use underscores (_) instad.

[Fenerit]

The 9.3 short names seem to be a limitation of the Blender export script. Once you have imported the model into Anim8or, you can specify a different texture file with a different name, as long as you want.

Suggestion: do not use spaces in file or image names. They cause problems for other programs. Use underscores (_) instad.

Marco, if the problem concern the Blender export script, try this method:
1) rename all the .dae model's textures with names not beyond 8 chars, that is, short the words (texture11.jpg > text11.jpg and so on);
2) import the .dae model in Blender and see whether a messagebox is showed asking for textures: whether an option, a button allow the search for the path. If this is allowed, set as texture the renamed ones; probably you might do this texture by texture until the message is showed. If all goes right, you will have the .dae model newly mapped, then you can export it in 3DS form without problem.
3) In the case such a "option" doesn't exist, load the .dae model, select the textured meshes and bookmark the names; import the 3DS model in Anim8tor and then apply one by one the bookmarked names of the texture upon the relevant meshes.

[Marco Klunder]

Marco, if the problem concern the Blender export script, try this method:
1) rename all the .dae model's textures with names not beyond 8 chars, that is, short the words (texture11.jpg > text11.jpg and so on);
2) import the .dae model in Blender and see whether a messagebox is showed asking for textures: whether an option, a button allow the search for the path. If this is allowed, set as texture the renamed ones; probably you might do this texture by texture until the message is showed. If all goes right, you will have the .dae model newly mapped, then you can export it in 3DS form without problem.
3) In the case such a "option" doesn't exist, load the .dae model, select the textured meshes and bookmark the names; import the 3DS model in Anim8tor and then apply one by one the bookmarked names of the texture upon the relevant meshes.

The problem indeed concern the Blender export script.
Renaming the textures files unfortunately do not result in a messagebox asking for textures

But this brought me to the idea to start editing the .3ds file with Notepad++ (lets give it a try, why not)
Looking for texture10.jp references and changing them into textur10.jpg (keeping the 8+3 format and NOT 5+3 or 6+3)
The same for 11, 12, 13, 14, 15 and 16 of course and I also (temporary) converted the .png into .jpg files including this reference change inthe .3ds file.

Including all texture file having a power of 2 size, the ,.3ds file is now imported in Anim8or without any error message.
In Anim8or I now get a fully colored phoenix model, but I don't know Anim8or well to get the textures also rendered.
To see if the model and textures work correct, I decided to import the .3ds model and textures in Blender again, and there I indeed see a fully textured phoenix model So the edit seems OK.

Next step, lets give it a try in Celestia:
phoenix.3ds model to the ..\extras\phoenix_lander\models direcory
All power of 2 texture files to the ..\extras\phoenix_lander\textures\medres directory
The following phoenix_lander.ssc file to the ..\extras\phoenix_lander directory

"Phoenix Lander" "Sol/Mars"
{
Class "spacecraft"
Mesh "phoenix.3ds"
Radius 0.002 # Approx
Beginning "2003 12 03"
LongLat [165.045 -76.556 0.001]
Orientation [ -76.556 1 0 0 ]
RotationOffset 211.05
Albedo 0.50
InfoURL "http://en.wikipedia.org/wiki/Mars_Polar_Lander"
}

Unfortunately, this is the result so far in Celestia

Phoenix_celestia.jpg

Marco

[selden]

Some 3D models have their surface normal vectors reversed. Celestia draws sufaces which have their normals pointing toward the viewpoint and does not draw surfaces which have their normals pointing away from the viewpoint.

A quick check of surface normals can be done in Anim8or by going into the "point editor" and selecting all of the surfaces. If the surfaces are drawn blue, their normals are pointing in the wrong direction. If they're yellow, they're OK.

Details:
start anim8or
load model
1 select "point editor"
2 select "display surfaces"
3 select "edit surfaces"
4 select "drag select"
5 drag the cursor across the surfaces you're interested in

in the picture below, all the surfaces are yellow: they're OK

If the surfaces are blue, you can invert them all by selecting the menu Edit, item Fix Normals

[Fenerit]

Marco, when you have changed the name of the textures, do you have changed also the path pointing to the ../phoenix_lander/textures/medres? If you had the texture in the main 3DS models' root, the 3D model cannot have set into it the path required from Celestia. The final saving of the 3DS models must be occour when you have both model and textures in the path Celestia allows, otherwise into the 3DS' instructions there not will be the path pointing to the ../medres folder.

[Marco Klunder]

These are the results of Seldens proposed actions:

Phoenix_a8_es_upper.jpg

Phoenix_a8_es_below.jpg

Pretty much yellow and it looks like most bleu parts have a meaning, being the back side of another texture.
Having done this, the suggested Edit/Fix Normals is marked grey and cannot be selected...

By the way, at least much more than just 1 component should have been drawn by Celestia, following this redenation
Even worse ... a bleu part seen from the upper side (see red arrow) is part of the only component that IS drawn by Celestia as seen in one of the above post.

...do you have changed also the path pointing to the ../phoenix_lander/textures/medres? If you had the texture in the main 3DS models' root, the 3D model cannot have set into it the path required from Celestia. The final saving of the 3DS models must be occour when you have both model and textures in the path Celestia allows, otherwise into the 3DS' instructions there not will be the path pointing to the ../medres folder.

I don't understand what you mean here (at all).
As Selden told in one of the previous post:

Anim8or needs the texture files to be in the same directory with the model file.
When the model is used with Celestia, though, the files have to be the Addon's \textures\medres\ directory. I.e., you'll have to have two copies of all of them while you're working on the Addon. (3DS files don't have room for any directory information, only for the texture's name.)

I did do nothing with path pointing. I only changed the texture names.

Marco