Celestia 1.4.0 prerelease 3

[chris]

I built another 1.4.0 prerelease:

http://www.celestiaproject.net/~claurel/celest ... e3-exe.zip

The only change from 1.4.0pre2 is a small fix to shaders that should make the OpenGL 2.0 path work on ATI hardware (Radeon 9500 or later.)

Evil Dr. Ganymede: this build seems to render your planet Prometheus just fine in the OpenGL Vertex Shader paths. I see no abrupt change in lighting; the appearance of the planet matches what I see with the OpenGL 2.0 path.

--Chris

[Evil Dr Ganymede]

Cool. I'll check that out... though I still don't have a card that's spiffy enough to render the new paths. I'm waiting for the 6600s to come out.

[Evil Dr Ganymede]

Well, it doesn't seem to fix anything in the old render paths (is it supposed to?)... There's still an abrupt change in lighting with the new version when B gets beyond 21.68 AU from the planet (Basic and Multitexture don't show any illumination from B, I was looking at the OpenGL path and the OpenGL/NVidia path). I've got a 128MB ASUS Geforce4 Ti4200 card, and the 61.77 drivers.

I can't check to see whether it works under OpenGL 2.0 because I don't have a card that supports that yet.

[Commander David]

Hi Chris,

the new prerelease 3 doesn`t fix the OGL2 Renderpath for my ATI Radeon 9500 non Pro. The Planets are all red, only the cloudlayer are rendered okay. I`ve testet the original textures and hires textures in DDS format - all the same red planets.
I use the ATI Tray Tool and have set the Pixel and vertexshader version to 2.0 -> no effect.

[Cormoran]

Greetings all,

I too am experiencing a very odd problem of a similar nature to Commander David's. My worlds in the Alpha Centauri system exhibit secondary illumination from Alpha Centauri B (and the worlds around B vice versa), but the worlds around A only receive light to their cloud layer. Switch off the clouds and the secondary lighting vanishes. Also, with clouds on, only the clouds themselves get any lighting. The underlying surface seems to get very little or none.

This is more of an observation than a gripe. I only just had the opportunity to download 1.4, and the whole program just looks and feels so much prettier (which is a stretch, given how great it was before).

Didn't know my cruddy old FX 5200 could do this

Cheers,

Cormoran

[chris]

Hi Chris,

the new prerelease 3 doesn`t fix the OGL2 Renderpath for my ATI Radeon 9500 non Pro. The Planets are all red, only the cloudlayer are rendered okay. I`ve testet the original textures and hires textures in DDS format - all the same red planets.
I use the ATI Tray Tool and have set the Pixel and vertexshader version to 2.0 -> no effect.

There should be a file called shaders.log in the Celestia directory. Could you post its contents here so I can see what's causing the error?

--Chris

[chris]

I too am experiencing a very odd problem of a similar nature to Commander David's. My worlds in the Alpha Centauri system exhibit secondary illumination from Alpha Centauri B (and the worlds around B vice versa), but the worlds around A only receive light to their cloud layer. Switch off the clouds and the secondary lighting vanishes. Also, with clouds on, only the clouds themselves get any lighting. The underlying surface seems to get very little or none.

Which render path are you using? The default? Or the OpenGL 2.0 path?

--Chris

[Evil Dr Ganymede]

Hi Chris,
The Planets are all red, only the cloudlayer are rendered okay. I`ve testet the original textures and hires textures in DDS format - all the same red planets.

I'm not seeing red planets, but I am seeing just the cloudlayer illuminated by the companion star (this is with the old render paths). I'd post shaders.log, but there seems to be nothing in it - its' an empty 0 MB file.

[chris]

I'm not seeing red planets, but I am seeing just the cloudlayer illuminated by the companion star (this is with the old render paths). I'd post shaders.log, but there seems to be nothing in it - its' an empty 0 MB file.

Aha! I think I understand what's going on now . . . I've been testing with cloud layers turned off. If clouds are turned off, everything should look OK with the OpenGL Vertex Shaders path. I'm working now on fixing clouds.

--Chris

[Evil Dr Ganymede]

I'm not seeing red planets, but I am seeing just the cloudlayer illuminated by the companion star (this is with the old render paths). I'd post shaders.log, but there seems to be nothing in it - its' an empty 0 MB file.

Aha! I think I understand what's going on now . . . I've been testing with cloud layers turned off. If clouds are turned off, everything should look OK with the OpenGL Vertex Shaders path. I'm working now on fixing clouds.

--Chris

Oh! Well, I just turned off the clouds with my Prometheus link, and the surface itself isn't illuminated at all by B, even when it's at a separation of 11 AU. The surface is never illuminated by B, in fact - on any render path that I have.

[chris]

Oh! Well, I just turned off the clouds with my Prometheus link, and the surface itself isn't illuminated at all by B, even when it's at a separation of 11 AU. The surface is never illuminated by B, in fact - on any render path that I have.

Right. That's intentional. Your planet orbits A with a semimajor axis of 0.4, so when B is 11au, A is still 27.5 closer. The 1/R^2 attenuation of the electromagnetic force means that B will be a dimmer by a factor of about 1/750. Also, A is intrinsically over 3.5 times brighter than B, so A is going to appear over 2500 times brighter than B. Celestia adjusts the apparent light source brightnesses with a power function; with the exponent I've chosen, light from B should be just barely visible. I could adjust the exponent to bring out the light from B more, but I'm not sure that this would be more realistic.

--Chris

[Evil Dr Ganymede]

Right. That's intentional. Your planet orbits A with a semimajor axis of 0.4, so when B is 11au, A is still 27.5 closer. The 1/R^2 attenuation of the electromagnetic force means that B will be a dimmer by a factor of about 1/750. Also, A is intrinsically over 3.5 times brighter than B, so A is going to appear over 2500 times brighter than B. Celestia adjusts the apparent light source brightnesses with a power function; with the exponent I've chosen, light from B should be just barely visible. I could adjust the exponent to bring out the light from B more, but I'm not sure that this would be more realistic.

OK, just for ease of reference, here's the Prometheus CEL URL I'm referring to all the time. You'll need the code from the thread on the Bugs board too.
cel://PhaseLock/Rigel%20Kentaurus%20A:Prometheus/Rigel%20Kentaurus%20B/2366-02-26T19:54:24.16683?x=AI5ZmJkqPKaB7+b//////w&y=oEJZ4FCPrA8sndL//////w&z=qtRYzZxDdzTDiCo&ow=-0.367940&ox=-0.121596&oy=0.674201&oz=-0.628719&select=Rigel%20Kentaurus%20B&fov=20.765589&ts=1.000000<d=0&rf=38711&lm=71

Now, the apparent magnitude of B over the range of 11 to 30 AU (or whatever the extremes are) is from -18 to -20. The full moon has a magnitude of only about -13. So it's what, at least 100 times bright than the full moon, even when it's furthest from the planet... and yet it provides no visible illumination? As it is the full moon casts noticeable, visible shadows when it's up. In this case B should certainly do the same if you were standing on the surface.

Because B isn't illuminating the planet at all though, I presume that B wouldn't cast ring shadows if Prometheus had a ring either. I could believe that it'd be hard to see the shadow while A was above the horizon, but you would surely see a shadow cast by B if it was the sole illuminator given what I just said.

Look at the crescent moon in the sky, and you can clearly see earthshine. Wouldn't B's illumination look similar to that? I wonder what the apparent magnitude of the full Earth is as seen from the moon?

Though the thing with earthshine is that you can see it when the moon is new/crescent, because the Earth is full as viewed from that hemisphere on the moon. Do we not see earthshine when the moon is "half full" because the illuminated side is too bright for us to see the dark side? Or is it because the Earth would also be "half full" as seen from the moon at that time, and that lowers the apparent magnitude of Earth enough that it doesn't illuminate the moon's surface enough to make it visible anymore? I suspect it's more the latter than the former...

[Commander David]

Hi Chris,

Planets with athmosphere are red, planets and moons without Athmosphere are black.

The Shader.log from my system are:

Vertex shader source:
1: uniform struct {
2: vec3 direction;
3: vec3 diffuse;
4: vec3 specular;
5: vec3 halfVector;
6: } lights[1];
7: uniform float shininess;
8: uniform vec3 ambientColor;
9: varying vec4 diff;
10: varying vec4 spec;
11: varying vec2 diffTexCoord;
12: varying vec2 nightTexCoord;
13: varying float totalLight;
14:
15: void main(void)
16: {
17: float nDotVP;
18: float nDotHV;
19: diff = vec4(ambientColor, 1);
20: nDotVP = max(0.0, dot(gl_Normal, lights[0].direction));
21: nDotHV = max(0.0, dot(gl_Normal, lights[0].halfVector));
22: diff += vec4(lights[0].diffuse * nDotVP, 1);
23: spec += vec4(lights[0].specular * (pow(nDotHV, shininess) * nDotVP), 0.0);
24: totalLight += nDotVP;
25: totalLight = 1 - totalLight;
26: totalLight = totalLight * totalLight * totalLight * totalLight;
27: diffTexCoord = gl_MultiTexCoord0.st;
28: nightTexCoord = gl_MultiTexCoord1.st;
29: gl_Position = ftransform();
30: }

Error compiling vertex shader:
ERROR: 0:25: '-' : wrong operand types no operation '-' exists that takes a left-hand operand of type 'const int' and a right operand of type 'varying float' (or there is no acceptable conversion)
ERROR: 0:25: 'assign' : cannot convert from 'const int' to 'varying float'
ERROR: 2 compilation errors. No code generated.

Fragment shader source:
1: varying vec4 diff;
2: varying vec4 spec;
3: varying vec2 diffTexCoord;
4: uniform sampler2D diffTex;
5: varying vec2 nightTexCoord;
6: uniform sampler2D nightTex;
7: varying float totalLight;
8:
9: void main(void)
10: {
11: vec4 color;
12: color = texture2D(diffTex, diffTexCoord.st);
13: gl_FragColor = color * diff + color.a * spec;
14: gl_FragColor += texture2D(nightTex, nightTexCoord.st) * totalLight;
15: }

Vertex shader source:
1: uniform struct {
2: vec3 direction;
3: vec3 diffuse;
4: vec3 specular;
5: vec3 halfVector;
6: } lights[1];
7: varying vec2 diffTexCoord;
8: varying vec2 normTexCoord;
9: varying vec3 lightDir0;
10: attribute vec3 tangent;
11:
12: void main(void)
13: {
14: float nDotVP;
15: nDotVP = max(0.0, dot(gl_Normal, lights[0].direction));
16: vec3 bitangent = cross(gl_Normal, tangent);
17: lightDir0.x = dot(tangent, lights[0].direction);
18: lightDir0.y = dot(-bitangent, lights[0].direction);
19: lightDir0.z = dot(gl_Normal, lights[0].direction);
20: diffTexCoord = gl_MultiTexCoord0.st;
21: normTexCoord = gl_MultiTexCoord1.st;
22: gl_Position = ftransform();
23: }

Fragment shader source:
1: uniform vec3 ambientColor;
2: vec4 diff = vec4(ambientColor, 1);
3: uniform vec3 lightcolor0;
4: varying vec2 diffTexCoord;
5: uniform sampler2D diffTex;
6: varying vec2 normTexCoord;
7: varying vec3 lightDir0;
8: uniform sampler2D normTex;
9:
10: void main(void)
11: {
12: vec4 color;
13: vec3 n = texture2D(normTex, normTexCoord.st).xyz * 2.0 - vec3(1.0, 1.0, 1.0);
14: float l;
15: l = max(0.0, dot(lightDir0, n)) * clamp(lightDir0.z * 8.0, 0.0, 1.0);
16: diff += vec4(l * lightcolor0, 0.0);
17: color = texture2D(diffTex, diffTexCoord.st);
18: gl_FragColor = color * diff;
19: }

[fsgregs]

Chris:

Hi. Will 1.4.0 fix that big problem with comet tails that was documented for 1.3.2? If you recall, you concurred that it needed fixing and mentioned something about redesigning the way the tails would be drawn. As a refresher, here is a screenshot documenting the comet tail problem.



Thanks

Frank