Weird behavior of CMODs

[ajtribick]

I've done these tests with the latest SVN version. Not sure if these are bugs or "features"

Using the following .cmod:

Code: Select all

#celmodel__ascii

material
emissive 0 1 1
end_material

mesh

vertexdesc
position f3
end_vertexdesc

vertices 6
-1 -1 0
-1 1 0
1 1 0
1 -1 0
0 0 1
0 0 -1

linestrip 0 13
0 1 2 3 0 4 2 5 3 4 1 5 0

end_mesh

When the model is used in a .ssc file, weird colour oscillations happen - from certain viewpoints the model occasionally turns white as it rotates, e.g.

Code: Select all

"Mesh" "Sol"
{
   Radius 1000
   Mesh "octahedron.cmod"
   EllipticalOrbit { Period 0.5 SemiMajorAxis 0.1 }
   UniformRotation { Period 1 }
}

cel://Follow/Sol:Mesh/2009-01-18T05:00: ... rc=0&ver=3

When I use the model in a .stc file, e.g.

Code: Select all

"Test"
{
   RA 0
   Dec 0
   Distance 1000
   AbsMag 4.83
   SpectralType "G2V"
   Mesh "octahedron.cmod"
}

the model is not shown as emissive, in fact it only seems to be visible against the background of the Milky Way.

What's going on here?

[selden]

Are you using a CRT or an LCD display? If an LCD, is it being fed an analog signal or digital?

Your description is consistent with viewing it on a CRT that needs to be converged. That is, its color guns are misaligned and need to be adjusted. Out of sync RGB signals might do something similar on an LCD being fed an analog signal. OpenGL lines are only a single pixel wide, so slight color misalignments would be easy to see.

The only SSC color shifts I'm seeing on my digitally driven LCD display are related to anti-aliasing. Some parts of the lines are slightly brighter, causing a slight color shift due to their angles on the screen and how much of a scan-line is illuminated.

I see the same problem as you see with the STC model. From some viewpoints I also can see dark line-segments against the glow of the star's "atmosphere".

[ajtribick]

I'm using an LCD - I very much doubt it is the display hardware. Here's some screenshots - in each the camera has not been moved, only time has advanced to allow the object to rotate.

On further investigation, everything is fine provided that the sun glare is visible: the model only turns white when it is in certain positions and the Sun glare isn't drawn. As soon as the Sun glare is shown, the colour returns to cyan. Is something not being initialised properly?

[selden]

After some persistence, I finally managed to see the lines go white. Here's a URL which shows it on my system:

cel://Follow/Sol:Mesh/2009-01-18T07:18: ... rc=0&ver=3

[edit]
Except that it acts differently on the same computer's secondary display (also digital LCD).

That URL always draws the lines white when Celestia's window is on the primary display. When I bring the sun into the field of view (e.g. by typing HC) they are drawn cyan. When I select the URL again, they are drawn white again.

However, when I drag Celestia's window to my secondary display, the object initially is drawn white. When I bring the sun into the field of view, it is drawn cyan. When I select the URL again, it is still drawn cyan.

The Celestia image capture below is with the window overlapping between primary (where lines are white) and secondary (where lines are cyan) screens.

Strange.

This obviously requires someone skilled in OpenGL to debug...

[ajtribick]

On further investigation, the colour problems do not occur on OpenGL 2.0 render path. Selden's URL gives a white octahedron on all the other paths I have available (Basic, Multitexture, OpenGL vertex program, OpenGL vertex program/NVIDIA combiners)

The star problem still occurs in the OpenGL 2.0 path however.

These effects also occur with the solid octahedron

Code: Select all

#celmodel__ascii

material
emissive 0 1 1
end_material

material
emissive 1 0 0
end_material

mesh

vertexdesc
position f3
end_vertexdesc

vertices 6
-1 -1 0
-1 1 0
1 1 0
1 -1 0
0 0 1
0 0 -1

trifan 0 6
4 0 3 2 1 0

trifan 1 6
5 0 1 2 3 0

end_mesh

[ajtribick]

More investigation - turns out the star model works if normals are explicitly defined on the vertices. Celestia does not appear to use computed normals for faces without vertex normals (despite being able to use such a computation to determine whether a face is visible) - this is also noticeable if you specify the materials as diffuse rather than emissive: the shadowing is not calculated for faces without normals.

Code: Select all

#celmodel__ascii

material
diffuse 0 1 1
end_material

material
diffuse 1 0 0
end_material

mesh

vertexdesc
position f3
normal f3
end_vertexdesc

vertices 6
-1 -1 0 -0.707106781 -0.707106781 0
-1 1 0 -0.707106781 0.707106781 0
1 1 0 0.707106781 0.707106781 0
1 -1 0 0.707106781 -0.707106781 0
0 0 1 0 0 1
0 0 -1 0 0 -1

trifan 0 6
4 0 3 2 1 0

trifan 1 6
5 0 1 2 3 0

end_mesh

However the color specified in the materials definition is ignored, which seems odd.

[chris]

More investigation - turns out the star model works if normals are explicitly defined on the vertices. Celestia does not appear to use computed normals for faces without vertex normals (despite being able to use such a computation to determine whether a face is visible) - this is also noticeable if you specify the materials as diffuse rather than emissive: the shadowing is not calculated for faces without normals.

It sounds like there's a bug involving OpenGL state not getting properly initialized before model rendering. My guess is that a texture is left enabled and this is the source of the white color. Vertex normals are not available unless specified, nor are the normals used for visibility determination. The vertices of a face are transformed to screen space; if they transformed vertices are in clockwise order, the face is culled.

When no normals are specified, a vertex is lit as if its normal was parallel to the light direction. That is, the vertex is fully lit by all light sources that aren't occluded by some other object.

I'll get to work on a fix for this bug as soon as I'm back from my vacation on Saturday.

--Chris

[chris]

The attached patch fixes some problems with mesh rendering. It should fix the color changing problem, but I'm not certain, as I wasn't able to reproduce it in the first place.

The black model in an stc file is fixed, but the model's appearance still probably isn't what you expect it to be. When a star is drawn, whatever materials were defined in the mesh are overridden with the star texture and color. I think a case could be made that this shouldn't happen: the star texture should be used only for the default ellipsoidal geometry, not for meshes. What would be your preference? Your 47 UMa add-on is exactly the sort of thing that I was envisioning when I enabled custom geometry for stars: is the texture override useful or an obstacle?

--Chris

[selden]

My personal preference would be for a Mesh's textures to override the default Star texture.
This would make it easier to produce a model of a star's interior, for example, similar to the models of planetary interiors.

However, specifying a Texture in the STC file does override the default texture, so it could be used as a temporary workaround. It doesn't give one the control available with the material definitions of a model, though.

[ajtribick]

I confirm the patch solves the colour-changing problem and the invisible star mesh problem.