Celestia Forums

I may have found a new serious bug, in the latest CVS version, but I need confirmation.

I made a spherical grid in CMOD format, to place around Earth. It works, but ONLY if I set Emissive true in the SSC file ! If I remove that option, Celestia freeze when it tries to go to Earth ! What the h... !

Here's a link to the addon (92 KB zip file) :

http://nho.ohn.free.fr/celestia/Cham/SphericalGrid.zip

It's a simple addon with two files : an SSC and a CMOD file in ASCII format. Lilke I said, the CMOD model works nicely if Emissive is set to true, but when you put an # in front of that option, Celestia freeze for no apparent reason.

Oh, I tested the same thing with Celestia 1.4.1 and it works without trouble, Emissive set to true or none. So I strongly feel the CMOD file is okay.

Of course, it works fine on my system.
I just rebuilt Celestia just now, and tested it both with and without Spice support, not that that should have made any difference.

etlkjadfglokj
*head bashing against keyboard*

System:
1GB 3.4GHz P4-550, WinXP Pro Sp2
128MB GF6600GT, Forceware v91.47
Celestia from cvs

Selden,

I don't understand. Did you tried without the Emissive ? It works ?

Then why it don't on my system, without the emissive, while it works with Emissive true, and it still works on 1.4.1 with/without Emissive ?

It works for me both with and without Emissive true. (I put a # at the beginning of the line.)

Maybe there's something else interfering.

What other Addons to you have in your extras folder?

I have none.

I didn't have a problem either. I notiiced a macos folder. Were you using mac when this happened?

I encountered some bugs using this grid model.

It occurs when emissive is disabled and using OpenGL 2.0 renderpath.
Using other renderpath or enabling emissive, there is no problem.

Not only the grid itself is not shown, but some Celestia renderings(markers, info text...) is not, either.


And at certain distance:

The Earth is shown as a hemisphere


Turning on the celestial grid, the Earth disappears.


Clouds is not shown partially.



with iBook G4, 1.33GHz PPC, Mobility Radeon 9550, Mac OS X 10.4.7
(This problem is not occured with Windows XP, P4 3.2GHz, Radeon 9600 Pro system.)

My machine crashes on the grid model when I comment out the Emissive directive (# Emissive true).

The crash is in RenderContext::drawGroup(), in glDrawElements().
Render path is OGL2. Latest CVS. Always reproducible.

Config: Mobility Radeon 9700, 64MB vram.

I confirm it's an OGL2 problem because all is fine using the other paths and I cannot use OGL2!

There must be something else contributing to the crash also. I can't reproduce this with ogl2 on. I remember another bug that caused a crash when star style was equal to points and render mode was basic. Everyone thought it was ogl2.

Yep, but seems to be also osX related...

This is what I've discovered so far:

1. This bug is 100% OGL2 related.
2. If the shaderProps.nlights (number of lights) is set to 0 in GLSL_RenderContext, no crash.
3. Difference between nlights = 0 and nlights > 0:
If nlights = 0, a minimal GLSL vertex shader is generated:


nlights > 0 generates a shader that uses gl_Normal.
This is the case when Emissive is not true in the ssc:


4. Cham's model does not contain normals.
On a hunch, I hacked the shader so that it uses a hard-coded normal:


No more crashes.
Solution: change the generated shader(s) to not refer to gl_Normal if the model does not contain normals. Or generate dummy normals. Or glEnableClientState(GL_NORMAL_ARRAY) (in setStandardVertexArrays()) regardless of whether there are normals or not.

So is there a solution to this bug ? Is this Apple's fault ?

I'm not sure if it's a driver bug, but I understand how the lack of normals could leave normal data uninitialized that if referred to, could conceivably lead to this kind of crash. Chris would know for sure, but I think this could be fixed in Celestia.

Celestia shouldn't be generating shaders that use the normal when no normals are provided. Yet it seems wrong that Celestia would just crash . . .

I think the best solution is to eliminate references to gl_Normal in shaders when no normals are provided. I need to think more about the right way to do this. We could just treat all meshes without normals as 'unlit'.

--Chris