Cel. 1.3.2pre7 broke panorama textures

Report bugs, bug fixes and workarounds here.
Avatar
Topic author
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Cel. 1.3.2pre7 broke panorama textures

Post #1by selden » 25.03.2004, 10:47

It seems that surface textures are no longer being projected onto the surfaces of 3DS models in the same way that they were projected in previous versions of Celestia

In particular, cubical panoramas no longer work.

Grant and I spent some time getting cubical panoramas to work with Celestia v1.3.1, projecting textures onto the interior surfaces of a cube. The object is a cube with 6 facets. All of their surface normals are reversed, pointing toward toward the center of the cube.

The "4x2" cubical panorama is designed to project a single surface texture onto the cube, with different parts on the cube's different faces. It doesn't work with Celestia v1.3.2pre7: the entire texture is projected onto just one face.

For example, download http://www.lns.cornell.edu/~seb/celestia/panoramas-v2.zip
Drag the folder 4x2-cube into the v1.3.2pre7 extras directory.
Start Celestia v1.3.2pre7 and wait to get to Mars
GoTo 4x2-Cube
Here is what you see:
Image
Unfortunately, this is not what we wanted.

Here's how to duplicate what we intended:
Drag the folder 4x2-cube into the v1.3.1 final extras directory.
Start Celestia v1.3.1 final and wait to get to Io.
GoTo Mars
GoTo 4x2-Cube
Here is what you see:
Image

This was first noticed when trying to duplicate a bug reported in the "map plane" thread.
I've also managed to get 1.3.2pre7 to crash when changing my viewpoint around the map-plane, but I can't duplicate it.

I suspect this is a bug, not an intentional change. :)

(Added later)

Celestia pre7 seems not to be respecting the "opacity" characteristic of materials. The panorama models include a transparent (opacity=0) cube surrounding the cube that carries the panorama texture. The two cubes are defined as separate objects. The definition of the external transparent cube object also contains no surface texture declaration at all. For some reason Pre7 is drawing the inner cube's texture on the outer cube.

(The transparent cube is there as a workaround for a clipping volume bug. Without it, corners of the panorama cube aren't always drawn when seen from the inside.)
Selden

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #2by chris » 25.03.2004, 17:07

It appears that the texture address mode is being set to clamp to the edge instead of wrapping. This should be almost trivial to fix. I'm not yet sure what the problem with opacity is.

--Chris

Avatar
Topic author
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #3by selden » 25.03.2004, 18:27

Chris,

As best I can tell, the only problem is related to how the outer transparent cube is being handled. When one inside the inner (panorama) cube (goto "inside 4x2-Cube") the panoramic image looks fine. It's just that the view into the panorama cube from outside is blocked by the texture that has been applied to the outer (supposedly transparent) cube.
Selden

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #4by chris » 26.03.2004, 16:46

I figured out what's going on . . .
When an ssc entry contains a texture, it overrides any materials in the mesh file. This is a change from earlier versions, and it's deliberate. To get the behavior you want, you should set the texture in the mesh, not in the ssc file.

--Chris

Avatar
Topic author
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #5by selden » 26.03.2004, 17:11

Chris,

Thanks for tracking down the culprit.

If at all possible, it would really help if you could enhance the code so a SSC texture specification only replaces a Mesh's texture declaration, not all of its materials. Ideally, it would replace only the first texture declaration in the mesh. This would make possible a large class of prototype Addons which would be easy to use by a novice.

By expecting them to edit model files, I fear you really are expecting too much of people who are unfamiliar with 3D design. It's far too easy to damage even textual model files in ways that can't be repaired.

If this can't be done, then it becomes much more urgent that the viewpoint clipping bug get fixed.

Thanks.
Selden


Return to “Bugs”