OK, this drives me crazy.
I use Blender. I made a sphere, I put a texture on it, I exported it as an obj. file, then I made a cmod file from it (or I make a 3ds file then a cmod file, doesn't matter).
I edited the cmod file, added specularmap and texture to the cmod file.
By the way, this is a Dyson-sphere.
So...it is not working. Celestia did not recognise the cmod file, or puts the texture file only on the outside of the sphere.
This Impossible Dyson add-on has a good model, but I cannot make a new - more detailed - sphere cmod file.
What can be the problem?
Which cmod properties are important regarding the inner texture of a sphere?
How to put textures on the inside of a sphere?
How to put textures on the inside of a sphere?
Last edited by john71 on 23.08.2017, 16:21, edited 1 time in total.
-
FarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 11 years 11 months
- Location: Germany
Hm I'm not sure about that. The addon you linked has the texture on the outside as well, but it's 3ds. So did you have any succes so far?
Usually when inside a mesh, it is not rendered (or only partially). So my idea would be to put another sphere on the inside of the model and apply the texture there, or create 2 hemispheres and put them together with a proper ssc file, or even a merged cmod files using at least 2 materials.
Usually when inside a mesh, it is not rendered (or only partially). So my idea would be to put another sphere on the inside of the model and apply the texture there, or create 2 hemispheres and put them together with a proper ssc file, or even a merged cmod files using at least 2 materials.
To expand on what FarGetaNik wrote:
Most 3D design programs, like Blender, don't always make it obvious which directions the surface normals are pointing in a model. Surface normals tell a viewing program which direction a surface is facing. 3D design programs usually are happy to draw any surface which isn't obstructed no matter what direction its surface normal points. In contrast, Celestia only draws a surface tile (patch) when that tile's surface normal points toward the viewpoint. Most spherical object meshes have their surface normals pointing only outward. When your viewpoint is on the inside of such a sphere, and if the only surface normals associated with the tiles of the sphere are pointing away from the viewpoint, Celestia won't draw those tiles. As a result, the sphere will be invisible when viewed from inside.
(FWIW, Anim8or, the 3D design program that I prefer, has an option "Flip Normals" which can be used to reverse all of an object's surface normal vectors. You can use it to make all of a sphere's surface normals point inward, for example. I'm sure Blender must have something comparable.)
If you inspect the .SSC for the "ImpossibleDyson", you'll see that it has two objects defined, both with the same name. The first object definition specifies a Mesh which is a 3DS model of a sphere. That model was designed so that all of its surface normals all point inward (toward the central star). That object declaration specifies a surface texture image (kiyoshi.jpg) which happens to be missing. The 3DS mesh itself contains a surface texture image name of mw-msx-2k.png, so that's the one Celestia should try to show you when you're looking at the sphere from the inside, if your viewpoint is close to the star 18 Sco, for example.
The second SSC object definition doesn't specify a Mesh, so Celestia draws its default spherical object, which has its surface normals pointing outward. That declaration specifies the picture "grid.jpg" as its surface texture image. As a result, when you're outside the sphere, you'll see the image "grid.jpg"
Most 3D design programs, like Blender, don't always make it obvious which directions the surface normals are pointing in a model. Surface normals tell a viewing program which direction a surface is facing. 3D design programs usually are happy to draw any surface which isn't obstructed no matter what direction its surface normal points. In contrast, Celestia only draws a surface tile (patch) when that tile's surface normal points toward the viewpoint. Most spherical object meshes have their surface normals pointing only outward. When your viewpoint is on the inside of such a sphere, and if the only surface normals associated with the tiles of the sphere are pointing away from the viewpoint, Celestia won't draw those tiles. As a result, the sphere will be invisible when viewed from inside.
(FWIW, Anim8or, the 3D design program that I prefer, has an option "Flip Normals" which can be used to reverse all of an object's surface normal vectors. You can use it to make all of a sphere's surface normals point inward, for example. I'm sure Blender must have something comparable.)
If you inspect the .SSC for the "ImpossibleDyson", you'll see that it has two objects defined, both with the same name. The first object definition specifies a Mesh which is a 3DS model of a sphere. That model was designed so that all of its surface normals all point inward (toward the central star). That object declaration specifies a surface texture image (kiyoshi.jpg) which happens to be missing. The 3DS mesh itself contains a surface texture image name of mw-msx-2k.png, so that's the one Celestia should try to show you when you're looking at the sphere from the inside, if your viewpoint is close to the star 18 Sco, for example.
The second SSC object definition doesn't specify a Mesh, so Celestia draws its default spherical object, which has its surface normals pointing outward. That declaration specifies the picture "grid.jpg" as its surface texture image. As a result, when you're outside the sphere, you'll see the image "grid.jpg"
Selden
Thanks for your help!
It is not Celestia's or the ssc file's fault in any way, because it works with a smaller sphere cmod file:
I was able to convert the original 3ds file to a cmod ascii file and after that I edited the ascii file to use new texture and specularmap dds files.
It works perfectly!
The problem is that I cannot find ANY clue in the cmod ascii file that why the small "original" sphere model works and the new larger sphere models don't.
Are there data in the cmod file which are inaccessible for the ascii editor?
It is not Celestia's or the ssc file's fault in any way, because it works with a smaller sphere cmod file:
I was able to convert the original 3ds file to a cmod ascii file and after that I edited the ascii file to use new texture and specularmap dds files.
It works perfectly!
The problem is that I cannot find ANY clue in the cmod ascii file that why the small "original" sphere model works and the new larger sphere models don't.
Are there data in the cmod file which are inaccessible for the ascii editor?
Everything that's in an ASCII CMOD file is visible to any text editor.
I assume by "larger" you mean a mesh that has more vertices. By itself the dimensions of a sphere are irrelevant since (unless you specify otherwise) Celestia automatically scales objects to the Radius specified in the catalog file.
Have you tried creating an object of your own which has very few vertices?
One possibility is that Blender is putting something in the object file that isn't being translated properly. With a short CMOD text file you'd have a better chance of noticing something that's inappropriate.
What text editor are you using?
Another possibility is that your text editor is somehow damaging the CMOD file. You do have to be careful to use a text editor, not a word processor. Word processors insert binary formatting codes which Celestia can't handle. FWIW, I usually use emacs when I edit CMODs manually.
I assume by "larger" you mean a mesh that has more vertices. By itself the dimensions of a sphere are irrelevant since (unless you specify otherwise) Celestia automatically scales objects to the Radius specified in the catalog file.
Have you tried creating an object of your own which has very few vertices?
One possibility is that Blender is putting something in the object file that isn't being translated properly. With a short CMOD text file you'd have a better chance of noticing something that's inappropriate.
What text editor are you using?
Another possibility is that your text editor is somehow damaging the CMOD file. You do have to be careful to use a text editor, not a word processor. Word processors insert binary formatting codes which Celestia can't handle. FWIW, I usually use emacs when I edit CMODs manually.
Selden
-
themartian
- Posts: 25
- Joined: 16.08.2017
- Age: 19
- With us: 6 years 9 months
The problem is that the Material being applied to the surface of the sphere's mesh is not the Material which specifies the surface textures. Something, perhaps Blender, has specified the wrong Material number to be applied to the mesh.
This is a case where Celestia's on-screen log file provides a hint as to the problem. (To see that log file, type a tilde (~) to Celestia. Use the Up- and Down-Arrow keys to navigate up and down in it.)
When a Mesh is loaded which specifies textures, Celestia's on-screen log file lists the mesh as it's being loaded and then it lists the names of the textures being applied to it.
In the case of the failing Blender mesh, no textures are listed in the log file. This means that the Material specified in the model file which is to be applied to the mesh does not specify any surface texture images.
If you inspect the CMOD file, you'll find the statement "trilist 1 238800". This means that Material #1 is to be applied to the surface defined by the list of 238800 vertices (238800/3 triangles) which follows that statement. However, Materials in a CMOD are "0 indexed". In other words, the first Material is number 0 and the second is number 1. The list of Materials at the beginning of the model defines only a single Material, so it is Material #0. Since there is no Material #1, no textures are applied to the surface of the sphere.
This is a case where Celestia's on-screen log file provides a hint as to the problem. (To see that log file, type a tilde (~) to Celestia. Use the Up- and Down-Arrow keys to navigate up and down in it.)
When a Mesh is loaded which specifies textures, Celestia's on-screen log file lists the mesh as it's being loaded and then it lists the names of the textures being applied to it.
In the case of the failing Blender mesh, no textures are listed in the log file. This means that the Material specified in the model file which is to be applied to the mesh does not specify any surface texture images.
If you inspect the CMOD file, you'll find the statement "trilist 1 238800". This means that Material #1 is to be applied to the surface defined by the list of 238800 vertices (238800/3 triangles) which follows that statement. However, Materials in a CMOD are "0 indexed". In other words, the first Material is number 0 and the second is number 1. The list of Materials at the beginning of the model defines only a single Material, so it is Material #0. Since there is no Material #1, no textures are applied to the surface of the sphere.
Selden
You need to include a second mesh (and associated trilist) with identical vertices but with their surface normals pointing in the opposite direction. This probably is done most easily by using Blender to create a second identical sphere with its normals flipped. It doesn't have to be in the same model file.
Selden
-
themartian
- Posts: 25
- Joined: 16.08.2017
- Age: 19
- With us: 6 years 9 months
Sorry, I was under the impression that reversing normals was relatively easy in Blender, otherwise I'd have recommended Anim8or, where it's "trivial": select object (e.g. type Ctrl-A), then select the Edit menu item "Flip Normals" or type Shift-N.
FWIW, a Web search found these instructions for Blender: https://blenderartists.org/forum/showthread.php?6298-My-mesh-is-black-Flip-Normals
FWIW, a Web search found these instructions for Blender: https://blenderartists.org/forum/showthread.php?6298-My-mesh-is-black-Flip-Normals
Selden
No, you really helped me, because without your reply I wouldn't have understood clearly what was causing the problem. I thought it was about putting a texture on the inner side of the sphere but it is a little bit more complicated. I didn't find the "flipping" solution in Blender, it is probably my fault. Anyway, it is a shame that Autodesk is quite expensive, because it seems to be a very good software.
Added after 9 hours 24 minutes:
By the way, Anim8or 1.0 is very good, why didn't I use it???
Added after 9 hours 24 minutes:
By the way, Anim8or 1.0 is very good, why didn't I use it???