Created attachment 6693 [details]
Celestia screen-shot, in orbit around Saturn

Those radial streaks on the rings are where the shadow should be. Note that the
streaks aren't static, either: they flicker like black lightning.

Created attachment 6694 [details]
A second shot of Celestia's ring shadows.

More radial lines where the ring shadow should be.

Here is the output from glxinfo:

$ glxinfo
name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name:                   Intel(R) Xeon(TM) CPU 2.66GHz
Mesa: MMX cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20060602 AGP 4x x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 6.5.1
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture,
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
    GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos,
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
    GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture,
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram,
    GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
    GL_EXT_secondary_color, GL_EXT_separate_specular_color,
    GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
    GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
    GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
    GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip,
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
    GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle,
    GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format,
    GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap,
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
    GL_SGIS_texture_lod

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x24 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x25 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x26 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x27 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x28 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x29 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x2a 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2b 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x2c 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x2d 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x2e 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2f 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x30 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x31 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x32 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x4b 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 Ncon

Do you have a celestia url for the broken ring shadow? I cannot reproduce this
with the example from the tutorial, the saturn ring shadow looks ok there for
me. Unless I switch off tcl, in that case I don't get any shadow at all just
some "grain" on the planet itself, so something seems to be wrong there.

I don't understand what you're asking. I've added the URL for downloading
celestia to this bug. (Although surely you must have this package already?)

I don't need to do anything special to reproduce this bug - I just go to Saturn
and look at the rings. Which video card are you using?

I have just tried to run any "demo" programs that come with MESA and support
GL_ARB_vertex_program. However, the only candidate seems to be arbfplight, which
also requires GL_ARB_fragment_program. And apparently, despite what the
r200_vertprog.c file says, the R200 doesn't support GL_ARB_fragment_program.

Hmm, could this be related? Some of the MESA demos are telling me to report bugs:

$ ./pointblast
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name:                   Intel(R) Xeon(TM) CPU 2.66GHz
Mesa: MMX cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
Mesa 6.5.1 implementation error: User called no-op dispatch function (an
unsupported extension function?)
Please report at bugzilla.freedesktop.org

$ ./spriteblast
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name:                   Intel(R) Xeon(TM) CPU 2.66GHz
Mesa: MMX cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
Mesa 6.5.1 implementation error: User called no-op dispatch function (an
unsupported extension function?)
Please report at bugzilla.freedesktop.org
Sorry, this demo requires GL_ARB_point_sprite.

gearbox is also behaving strangely (I think) in the top left corner - is that
corner meant to be transparent?

Created attachment 6706 [details]
Screenshot of the gearbox MESA demo

Notice how my web browser is visible through the top left corner of the
window??!

(In reply to comment #8)
> Created an attachment (id=6706) [edit]
> Screenshot of the gearbox MESA demo
> 
> Notice how my web browser is visible through the top left corner of the
> window??!

That is normal because gearbox never clears that area.

One ring-shadow demo URL for people:

cel://Follow/Saturn/2006-08-26T22:42:15.02225?x=ChtazHUPKI1WDA&y=gZrSQ8RMk14C&z=ZCyfD/SMJ4ua/////////w&ow=0.147406&ox=0.882195&oy=-0.302936&oz=-0.328988&select=Saturn&fov=20.361984&ts=1.000000&ltd=0&rf=317335&lm=0

Created attachment 6710 [details]
Screenshot from the given URL.

cel://Follow/Saturn/2006-08-26T22:42:15.02225?x=ChtazHUPKI1WDA&y=gZrSQ8RMk14C&z=ZCyfD/SMJ4ua/////////w&ow=0.147406&ox=0.882195&oy=-0.302936&oz=-0.328988&select=Saturn&fov=20.361984&ts=1.000000&ltd=0&rf=317335&lm=0

(In reply to comment #5)
> I don't understand what you're asking. I've added the URL for downloading
> celestia to this bug. (Although surely you must have this package already?)
I meant the URL which will produce the image you're seeing. Apparently you can
easily create such celestia urls, I'm asking because not only will these include
position data but it seems also the settings you're using (not that I really
know what exactly they include, I've never used celestia for anything else than
verifying dri bugs).

> I don't need to do anything special to reproduce this bug - I just go to
> Saturn and look at the rings. Which video card are you using?
That's what I did too, that's why I'm looking for differences in the settings.
I'm using a radeon 9000 (rv250), as far as I'm aware there are no differences
between rv250 and rv280 except the supported agp 8x mode of the latter (and some
bug fixes, like the broken yuv texture support in rv250 which is fixed in rv280).

(In reply to comment #7)
> Hmm, could this be related? Some of the MESA demos are telling me to report bugs:
> 
> $ ./pointblast
> Mesa 6.5.1 implementation error: User called no-op dispatch function (an
> unsupported extension function?)
> Please report at bugzilla.freedesktop.org

> $ ./spriteblast
> Mesa 6.5.1 implementation error: User called no-op dispatch function (an
> unsupported extension function?)
> Please report at bugzilla.freedesktop.org
> Sorry, this demo requires GL_ARB_point_sprite.

No this is not related. Basically this is an app bug, those progs should test if
an extension is available before calling the functions associated with it.
pointblast fails to do this at all, whereas spriteblast checks it but after
having called the extension function. If noone beats me to it and I don't forget
it, I'll check in a fix next week.
That said, the error given is probably a bit confusing, it is not actually an
"implementation error" in this case (well it hints it might be an unsupported
extension). 

(In reply to comment #6)
> I have just tried to run any "demo" programs that come with MESA and support
> GL_ARB_vertex_program. However, the only candidate seems to be arbfplight,
> which also requires GL_ARB_fragment_program. And apparently, despite what the
> r200_vertprog.c file says, the R200 doesn't support GL_ARB_fragment_program.
Where does it say that? There is some (ifdefed out) code which relates to
fragment program, this is a straight copy from the r300 driver (which supports
arb_fp), I'm going to delete it one day. The other hint of fragment program is
just for creating the shader objects, it may or may not be necessary for
avoiding problems with the creation of mesa's default shader objects. The r200
driver does not and never will support ARB_fp, simply because the hardware can't
handle it.
If you want more vertex program tests, you can get them from mesa cvs, in the
progs/tests directory - I believe this is not included in tarballs.

(In reply to comment #10)
One ring-shadow demo URL for people:
Ok that's what I wanted. I can only try that next week though.

Created attachment 6724 [details]
Celestia eclipse shadow problem

cel://PhaseLock/Earth/Sol/2006-09-22T11:43:36.97862?x=WM/TdJlOK4fNDA&y=GyWkcwyfAg&z=7bgjg08BjTU&ow=0.681918&ox=0.170121&oy=0.701732&oz=-0.116701&select=Sol:Earth:Hubble&fov=20.361984&ts=1.000000&ltd=0&rf=22419&lm=342


And the first time I tried to take this screenshot, it locked up my computer.

More testing:

I have discovered that running celestia 1.4.1 with XOrg 7.1 (FC6
release-candidate packages), exiting celestia and then running other OpenGL
games can cause my computer's GPU to lock up immediately. The other OpenGL game
in question is World of Warcraft, running under Wine 0.9.20/CVS in full-screen
mode. Running Warcraft in Direct3D mode seems to be OK, as far as the login
screen anyway. (I don't have a Warcraft account yet, so can't test any further.)
However, Wine implement Direct3D support in terms of libGL and libGLU, so
there's obviously something specific in OpenGL support which is killing my machine.

I have also discovered that celestia will *not* cause any trouble, provided only
the following rendering options are selected:
- antialiasing
- smooth lines
- stars
- galaxies
- automag

Rendering planets(!) *does* cause OpenGL problems later.

(In reply to comment #15)
> I have also discovered that celestia will *not* cause any trouble, provided only
> the following rendering options are selected:
> - antialiasing
> - smooth lines
> - stars
> - galaxies
> - automag
do problems also happen if you only select the multitexture render path? It
could be some weird initialization problem when the last app had vertex programs
enabled when exiting.

How would I test that? I don't remember any "multi-texture render path" option
in celestia. Do you mean stopping celestia using GL_ARB_vertex_program?

(In reply to comment #17)
> How would I test that? I don't remember any "multi-texture render path" option
> in celestia. Do you mean stopping celestia using GL_ARB_vertex_program?
? Options->OpenGL render path (or similar, it's in german here)

(In reply to comment #18)
> (In reply to comment #17)
> > How would I test that? I don't remember any "multi-texture render path" option
> > in celestia. Do you mean stopping celestia using GL_ARB_vertex_program?
> ? Options->OpenGL render path (or similar, it's in german here)
Ah wait or do you have some weird glut version or something? I've no idea about
how you'd configure that.

(In reply to comment #11)
> Created an attachment (id=6710) [edit]
> Screenshot from the given URL.
> 
cel://Follow/Saturn/2006-08-26T22:42:15.02225?x=ChtazHUPKI1WDA&y=gZrSQ8RMk14C&z=ZCyfD/SMJ4ua/////////w&ow=0.147406&ox=0.882195&oy=-0.302936&oz=-0.328988&select=Saturn&fov=20.361984&ts=1.000000&ltd=0&rf=317335&lm=0
This (and the other URL) works for me just fine. Hmm...

a) If I disable GL_ARB_vertex_program in the configuration file, then celestia
is forced to use GL_NV_vertex_program instead. This means that the
"multi-texture render path" is the best rendering option that I can get. I can
then enable planets, ring shadows and eclipse shadows et al, and everything is
happy. (I see eclipse shadows, but not ring shadows. My machine doesn't crash
later.)

b) If I enable GL_ARB_vertex_program then celestia jumps to using the Open GL
render path before I can tell it to use the multi-texture one instead, after
which the damage is done.

c) I am using FC RPM package freeglut-2.4.0-4, which provides libglut.so.3.8.0.

(In reply to comment #21)
> a) If I disable GL_ARB_vertex_program in the configuration file, then celestia
> is forced to use GL_NV_vertex_program instead.
This is impossible. This option is gone for good, if it is still there an old
r200_dri.so is picked up somewhere. (In fact it would explain at least some of
the misrendering, as it indeed partly looks like z-fighting which can be caused
by tcl fallbacks, which is exactly what would happen with an old driver (or
somewhat newer driver but old drm) and this option).

> This means that the
> "multi-texture render path" is the best rendering option that I can get. I can
> then enable planets, ring shadows and eclipse shadows et al, and everything is
> happy. (I see eclipse shadows, but not ring shadows. My machine doesn't crash
> later.)
> 
> b) If I enable GL_ARB_vertex_program then celestia jumps to using the Open GL
> render path before I can tell it to use the multi-texture one instead, after
> which the damage is done.
> 
> c) I am using FC RPM package freeglut-2.4.0-4, which provides libglut.so.3.8.0.
No, I meant celestia version. Apparently you can compile it for glut only, gtk
or kde. And the kde version has the option to select other render paths, I don't
know about the other versions.

I configured celestia 1.4.1 with gnome and cairo support, because I don't have a
KDE desktop.

Hmm, GL_NV_vertex_program is an option in driconf, under "Features that are not
hardware accelerated". GL_ARB_vertex_program used to be here too, until it was
implemented in hardware in XOrg 7.1.

I used to enable both... Should I turn GL_NV_vertex_program off and let celestia
use GL_ARB_vertex_program, then? I don't know where GL_NV_vertex_program is
coming from, but *someone* is putting it in my glxinfo. (See comment #3).

OK, good news and bad news:

The good news is that disabling GL_NV_vertex_program and enabling
GL_ARB_vertex_program fixes the rendering artifacts in celestia. I now see
correct ring shadows and eclipse shadows.

The bad news is that afterwards, my OpenGL Warcraft session still crashes.

(In reply to comment #25)
> OK, good news and bad news:
> 
> The good news is that disabling GL_NV_vertex_program and enabling
> GL_ARB_vertex_program fixes the rendering artifacts in celestia. I now see
> correct ring shadows and eclipse shadows.
Ok, so the bad rendering was somehow caused by the software vertex shader (maybe
because of the fallback itself). I'm not sure why celestia would prefer NV_vp if
ARB_vp is available, seems kinda backwards to me. I don't think you actually
ever want to enable (software) NV_vp.

> The bad news is that afterwards, my OpenGL Warcraft session still crashes.
Unfortunately I don't have WoW, but I'll try to reproduce it with other apps.

(In reply to comment #26)
> Unfortunately I don't have WoW, but I'll try to reproduce it with other apps.

Actually, I don't have WoW either. I downloaded a 3 GB trial client installation
and am running it under Wine 0.9.20:

http://www.worldofwarcraft.com/downloads/wowclient-download.html

(Blizzard makes its money from online monthly subscriptions.) 

Also see: https://bugs.freedesktop.org/show_bug.cgi?id=8027

(In reply to comment #27)
> Actually, I don't have WoW either. I downloaded a 3 GB trial client installation
> and am running it under Wine 0.9.20:
A 3GB download is a bit too much right now for me...
Anyway, I'll close this bug as it has changed into something much else than
initially reported. Marking as fixed since the arb_vp path seems to run ok
(though problems with fallbacks probably remain). See bug #8060 for the lockup
problem.

Could you have a quick look at this "ring shadow" URL, please?

cel://Follow/Saturn/2006-08-29T14:27:49.95173?x=+oB8o9BGDW1WDA&y=AeXMilHfBEkC&z=ODP9RkQgVMea/////////w&ow=0.730223&ox=-0.551377&oy=-0.322312&oz=0.242638&select=Saturn&fov=29.107899&ts=1.000000&ltd=0&rf=317335&lm=0

I have just tried this URL with celestia 1.4.1 on my Matrox G400 / XOrg 6.8.2,
both with and without the GL_ARB_vertex_program. (Both GL_ARB_vertex program and
GL_NV_vertex_program are software-enabled via driconf on the G400, and I have
disabled GL_NV_vertex_program here in all cases.)

Happily for celestia, I get equivalent (if dark) pictures of Saturn, with
Saturn's shadow falling across its rings, regardless of the
GL_ARB_vertex_program setting. Note also that celestia is using multi-texture
rendering in both cases: it seems that the OpenGL rendering path needs something
more than GL_ARB_vertex_program before it can be used.

However, with my Radeon 9250 / XOrg 7.1, disabling both GL_ARB_vertex_program
and GL_NV_vertex_program means that Saturn's shadow across its rings disappears!
I had originally thought that the shadow wasn't being rendered at all, until I
saw this URL:

cel://Follow/Saturn/2006-08-29T09:35:30.41946?x=+0NycYGJxGNWDA&y=m2Y3cow4O1oC&z=kQLl9SiJ7Lma/////////w&ow=-0.442510&ox=-0.299259&oy=-0.843421&oz=0.057180&select=Saturn&fov=20.361984&ts=1.000000&ltd=0&rf=22423&lm=0

You'll need ambient light for that one, I think. Basically, Saturn's shadow
looks upside down on my Radeon. I had this even better experience when flying
over Saturn, and seeing Saturn's shadow cross the rings from the completely
wrong direction, almost as if the shadow was coming from an invisible twin
planet. But I forgot to save that URL...

Neither of these URLs triggers bug #8060 later.

So in summary, disable GL_ARB_vertex_program via the celestia.cfg file, and I
think you'll see Saturn's shadow across its rings disappear, although it works
OK on a Matrox G400.

Created attachment 6737 [details]
Ring shadow reference shot, using Matrox G400

Linux 2.6.17.11, XOrg 6.8.2, Celestia 1.4.1, multi-texture rendering path,
GL_NV_vertex_program disabled, GL_ARB_vertex_program enabled.

Created attachment 6738 [details]
Ring shadow reference shot, using Matrox G400

Linux 2.6.17.11, XOrg 6.8.2, celestia 1.4.1, multi-texture rendering path, both
GL_ARB_vertex_program and GL_NV_vertex_program disabled.

(In reply to comment #29)
> Could you have a quick look at this "ring shadow" URL, please?
> 
>
cel://Follow/Saturn/2006-08-29T14:27:49.95173?x=+oB8o9BGDW1WDA&y=AeXMilHfBEkC&z=ODP9RkQgVMea/////////w&ow=0.730223&ox=-0.551377&oy=-0.322312&oz=0.242638&select=Saturn&fov=29.107899&ts=1.000000&ltd=0&rf=317335&lm=0
> 
> I have just tried this URL with celestia 1.4.1 on my Matrox G400 / XOrg 6.8.2,
> both with and without the GL_ARB_vertex_program. (Both GL_ARB_vertex program and
> GL_NV_vertex_program are software-enabled via driconf on the G400, and I have
> disabled GL_NV_vertex_program here in all cases.)
> 
> Happily for celestia, I get equivalent (if dark) pictures of Saturn, with
> Saturn's shadow falling across its rings, regardless of the
> GL_ARB_vertex_program setting. Note also that celestia is using multi-texture
> rendering in both cases: it seems that the OpenGL rendering path needs something
> more than GL_ARB_vertex_program before it can be used.
Yes, it needs GL_ARB_texture_env_dot3, which the g400 doesn't support it seems.
So it is expected that you'd see the same regardless all those vertex progs
settings.

> However, with my Radeon 9250 / XOrg 7.1, disabling both GL_ARB_vertex_program
> and GL_NV_vertex_program means that Saturn's shadow across its rings disappears!
> I had originally thought that the shadow wasn't being rendered at all, until I
> saw this URL:
>
cel://Follow/Saturn/2006-08-29T09:35:30.41946?x=+0NycYGJxGNWDA&y=m2Y3cow4O1oC&z=kQLl9SiJ7Lma/////////w&ow=-0.442510&ox=-0.299259&oy=-0.843421&oz=0.057180&select=Saturn&fov=20.361984&ts=1.000000&ltd=0&rf=22423&lm=0
> 
> You'll need ambient light for that one, I think. Basically, Saturn's shadow
> looks upside down on my Radeon. I had this even better experience when flying
> over Saturn, and seeing Saturn's shadow cross the rings from the completely
> wrong direction, almost as if the shadow was coming from an invisible twin
> planet. But I forgot to save that URL...
Ah I see. I thought it was normal that there is no shadow at all without arb_vp.
Apparently not, I tried with indirect rendering (which resulted in a Xserver
crash..., but then my server is not up-to-date) and with software mesa, and
software mesa indeed shows a ring shadow (though fails to draw it when using
ARB_vp, and crashes with the GLSL path - those are certainly different bugs).
This is some driver bug with texture coordinates being wrong, basically celestia
uses texgen for s and t coordinate and doesn't specify r and q coordinates - so
those should be 0 and 1 respectively according to spec, but they are
uninitialized somehow in the r200 driver, which doesn't matter for r but does
for q. This is btw the same problem which causes doom3 to look very very wrong
with the standard arb path, you can either disable tcl, or use some hack:
Index: r200_texstate.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c,v
retrieving revision 1.23
diff -u -r1.23 r200_texstate.c
--- r200_texstate.c	2 Nov 2005 01:15:08 -0000	1.23
+++ r200_texstate.c	29 Aug 2006 17:37:57 -0000
@@ -1338,6 +1359,9 @@
    rmesa->TexGenEnabled |= R200_TEXGEN_TEXMAT_0_ENABLE << unit;
    rmesa->TexGenCompSel |= R200_OUTPUT_TEX_0 << unit;
 
+   /* really ugly hack to fix doom3 arb path and celestia ring shadows */
+   tgcm = 0;
+
    if (tgi != rmesa->hw.tcg.cmd[TCG_TEX_PROC_CTL_1] || 
        tgcm != rmesa->hw.tcg.cmd[TCG_TEX_PROC_CTL_2])
    {

Someday, this should be fixed correctly...

Well, I opted for the "some hack" solution, and am happy to say that I see ring
shadows this time. So I guess we can close this bug for real now :-).

Thanks.
Chris

Mass version move, cvs -> git