Major bug found ?

Report bugs, bug fixes and workarounds here.
Avatar
Topic author
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 10 months
Location: Montreal

Major bug found ?

Post #1by Cham » 21.09.2006, 07:06

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.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

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

Post #2by selden » 21.09.2006, 07:56

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

Avatar
Topic author
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 10 months
Location: Montreal

Post #3by Cham » 21.09.2006, 08:05

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 ?
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

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

Post #4by selden » 21.09.2006, 08:26

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.
Selden

Avatar
cartrite
Posts: 1978
Joined: 15.09.2005
With us: 19 years 2 months
Location: Pocono Mountains, Pennsylvania, USA Greate Grandfother from Irshava, Zakarpattia Oblast Ukraine

Post #5by cartrite » 21.09.2006, 12:28

I didn't have a problem either. I notiiced a macos folder. Were you using mac when this happened?
VivoBook_ASUSLaptop X712JA_S712JA Intel(R) UHD Graphics 8gb ram. Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz, 1190 Mhz, 4 Core(s), 8 Logical Processor(s) 8 GB ram. Running on Windows 11 and OpenSuse 15.4

Sui Ota
Posts: 75
Joined: 05.10.2005
With us: 19 years 1 month
Location: Saitama, Japan

Post #6by Sui Ota » 21.09.2006, 13:10

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 8O
Image

Turning on the celestial grid, the Earth disappears.
Image

Clouds is not shown partially.
Image


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.)
-Suι

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #7by dirkpitt » 21.09.2006, 14:38

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.

ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 19 years 9 months

Post #8by ElChristou » 22.09.2006, 01:52

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

Avatar
cartrite
Posts: 1978
Joined: 15.09.2005
With us: 19 years 2 months
Location: Pocono Mountains, Pennsylvania, USA Greate Grandfother from Irshava, Zakarpattia Oblast Ukraine

Post #9by cartrite » 22.09.2006, 02:02

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.
VivoBook_ASUSLaptop X712JA_S712JA Intel(R) UHD Graphics 8gb ram. Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz, 1190 Mhz, 4 Core(s), 8 Logical Processor(s) 8 GB ram. Running on Windows 11 and OpenSuse 15.4

ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 19 years 9 months

Post #10by ElChristou » 22.09.2006, 11:06

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

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #11by dirkpitt » 23.09.2006, 04:51

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:

Code: Select all

void main(void)
{
  float NL;
  diff = vec4(ambientColor, opacity);
  gl_Position = ftransform();
}


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

Code: Select all

void main(void)
{
  float NL;
  diff = vec4(ambientColor, opacity);
  NL = max(0.0, dot(gl_Normal, light0_direction));
  diff.rgb += light0_diffuse * NL;
  gl_Position = ftransform();
}


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

Code: Select all

  NL = max(0.0, dot(vec3(0.0,1.0,0.0), light0_direction));


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.
Last edited by dirkpitt on 23.09.2006, 05:10, edited 4 times in total.

Avatar
Topic author
Cham M
Posts: 4324
Joined: 14.01.2004
Age: 60
With us: 20 years 10 months
Location: Montreal

Post #12by Cham » 23.09.2006, 04:54

So is there a solution to this bug ? Is this Apple's fault ?
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #13by dirkpitt » 23.09.2006, 05:00

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.

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

Post #14by chris » 23.09.2006, 07:00

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


Return to “Bugs”