Celestia Forums

Hi,

I am using celestia 1.4.1 under Linux 2.6 with XOrg 7.1, and I have disabled GL_ARB_vertex_program in celestia.cfg. This means that I am using the multi-texture render path.

Having said all that, I think that Saturn's shadow is the wrong way round on its rings:
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

I think this URL does work OK when using the OpenGL render path.

Do you have ambient light turned on, by any chance?

That produces non-physical illumination. In particular, the ring shadows are cast through to the other side of the planet. My understanding is that there are no plans to fix this "bug".

On a Windows system, your URL takes me to a viewpoint where everything is black in all render modes because it's on the night side of the planet and rings. (I'm surprised there isn't some forward scattering in the rings, though.)

Yes, I have ambient light turned on "low" because otherwise everything is pitch black

I'd like to be able to upload a screenshot to show you what I mean, but basically Saturn's shadow on the rings is upside down in that the circular "dome" from the top of Saturn is pointing towards the planetary body rather than away from it.

But I don't think that this is just an "ambient light" thing, because the following URL has a nice ring shadow when I enable GL_ARB_vertex_program, but none at all when I disable it from the configuration file. At least, I thought that it had none. Now I suspect that GL_NV_vertex_program is simply rendering the shadow in the wrong place.

Hmm, I said GL_NV_vertex_program, but I guess I mean "however celestia renders ring-shadows in the multi-texture render path" .

As I mentioned, my understanding is that Chris has no plans to fix any bugs in how ring shadows are drawn when ambient light is enabled. He's concentrating his work on the OGL2 path (where they are drawn "correctly").

Fine. Then here's a URL for a ring shadow bug with ambient light turned OFF.

Enable GL_ARB_vertex_program, see ring shadow. Disable GL_ARB_vertex_program, don't see ring shadow.

Unfortunately, I see no bugs in the Windows version of Celestia at that viewpoint. I'm afraid you'll have to get an account on one of the free Web sites ( http://imageshack.us/ for example) so you can display a screengrab of what you see that's wrong.

If you mean that you can't see the shadow of the rings on the planet in multitexture mode, well, yes, that's the way it is. The functionality provided by vertex shading is required in order for Celestia to be able to display the shadow of the rings on the planet.

You might take a look at the Web page http://www.lepp.cornell.edu/~seb/celestia/textures.html
On that page I've tried to describe the various uses and limitations in how Celestia currently handles textures and shading. Section 3.5 discusses ring shadows.

(FWIW, it looks like some of the limitations with regard to SSC Texture usage with Meshes may be removed in the next major release of Celestia.)

I

f you mean that you can't see the shadow of the rings on the planet in multitexture mode, well, yes, that's the way it is. The functionality provided by vertex shading is required in order for Celestia to be able to display the shadow of the rings on the planet.

That can't be right. I'm currently running celestia 1.4.1 on a Matrox G400 (XOrg 6.8.2)which doesn't even support OpenGL rendering, and I can get ring shadows. They're almost impossible to see without ambient light, but they are there. (Much easier to see with ambient light, of course...)

Hmm - you said

shadow of the rings on the planet

, whereas I'm talking about the shadow of the planet on the rings, which also seems to be controlled by the "ring shadow" option.

Even more strangely, that shadow is still there then I disable the software GL_ARB_vertex_program support, unlike on my Radeon 9250 / XOrg 7.1.

The low-res shadow of the planet on the rings requires only OpenGL Multitexture support. (If you look closely, you'll see stairsteps in the edges of the shadow; they're also visible in some eclipse shadows.)

High-res shadows (i.e. shadows with smooth borders) are what require the OpenGL v2 render path.

Drawing the shadow of the rings on the planet is more difficult than drawing the shadow of the planet on the rings. It requires vertex/pixel shading programs, which are in Celestia's shaders folder. They use some OGL v1.4 features. (My impression is that many of the OpenGL v2 shader routines that Celestia uses are written "on the fly" rather than being preprogrammed.)

I suspect OpenGL v2 is what you meant when you wrote just OpenGL. What version of OpenGL do your Matrox drivers claim to support? The OpenGL version is shown in Celestia's Help/OpenGL Info menu. The most recent drivers available on the Matrox Web site, v5.96.004, are dated May'06. My understanding is that some v1.4 features were included in their v1.3 drivers, but I don't know what OGL version Matrox is shipping now.

The Matrox G400 is very, very old

$ glxinfo -l
name of display: :0.0
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_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
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_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 extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: VA Linux Systems Inc.
OpenGL renderer string: Mesa DRI G400 20030328 AGP 2x x86/MMX
OpenGL version string: 1.2 Mesa 6.2.1
OpenGL extensions:
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_compression,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_logic_op, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_copy_texture,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
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_object,
GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
GL_ATI_texture_env_combine3, GL_IBM_rasterpos_clip, GL_MESA_ycbcr_texture,
GL_MESA_window_pos, GL_NV_light_max_exponent, GL_NV_texture_rectangle,
GL_NV_texgen_reflection, GL_SGIS_generate_mipmap,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays
OpenGL limits:
GL_MAX_ATTRIB_STACK_DEPTH = 16
GL_MAX_CLIENT_ATTRIB_STACK_DEPTH = 16
GL_MAX_CLIP_PLANES = 6
GL_MAX_ELEMENTS_VERTICES = 3000
GL_MAX_ELEMENTS_INDICES = 3000
GL_MAX_EVAL_ORDER = 30
GL_MAX_LIGHTS = 8
GL_MAX_LIST_NESTING = 64
GL_MAX_MODELVIEW_STACK_DEPTH = 32
GL_MAX_NAME_STACK_DEPTH = 64
GL_MAX_PIXEL_MAP_TABLE = 256
GL_MAX_PROJECTION_STACK_DEPTH = 32
GL_MAX_TEXTURE_STACK_DEPTH = 10
GL_MAX_TEXTURE_SIZE = 1024
GL_MAX_3D_TEXTURE_SIZE = 256
GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 2048
GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB = 0
GL_MAX_TEXTURE_UNITS_ARB = 2
GL_MAX_TEXTURE_LOD_BIAS_EXT = 11
GL_MAX_VIEWPORT_DIMS = 4096, 4096
GL_ALIASED_LINE_WIDTH_RANGE = 1, 10
GL_SMOOTH_LINE_WIDTH_RANGE = 1, 10
GL_ALIASED_POINT_SIZE_RANGE = 1, 20
GL_SMOOTH_POINT_SIZE_RANGE = 1, 20
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

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 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x28 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x2a 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x2b 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x2d 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x2f 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x30 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x31 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x32 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow

Even with software GL_ARB_vertex_program support, it can only use the Multi-Texture rendering path. So we can forget about ring shadows on planets because I was only looking at planet shadows on rings.

Oddly enough, celestia 1.4.1 seems fine with the G400. Which OpenGL features are being used to draw the planet's shadow, please? Because maybe the real bug is in the Radeon 9250's OpenGL support.

While the G400 may be old, brand new drivers are available for Windows and Linux, released just this year: v5.46.004 in May for XP, v4.4 in July for Linux.

http://www.matrox.com/mga/support/drive ... t/home.cfm

Are you using the new drivers?

Unfortunately, I don't know for sure just which vertex and pixel shader routines are used. I'd have to look at the code, which you can do as easily as I can. Maybe Chris has noticed this thread and can comment.

Actually, I was using the XOrg 6.8.2 drivers with the G400 (which aren't the latest, but then the G400 setup is working.)

But the XOrg developers have now accepted that the shadow rendering bug is in their Radeon r200 driver, and have given me a patch (which works).

Great!

Thanks for letting us know.

I have an image of a ring shadow "bug" on Saturn's rings that I would like to submit for discussion. how can I upload images? I see the "img" button on the form, but is it possible to upload non-hosted images direct from my hard drive? thank you

ronin wrote:but is it possible to upload non-hosted images direct from my hard drive?

nope. http://imageshack.us/ ftw.

Johaen wrote:

ronin wrote:but is it possible to upload non-hosted images direct from my hard drive?

nope. http://imageshack.us/ ftw.

Unless you are operating your own web-server on your machine.

Chuft-Captain wrote:

Johaen wrote:

ronin wrote:but is it possible to upload non-hosted images direct from my hard drive?

nope. http://imageshack.us/ ftw.

Unless you are operating you're own web-server on your machine.

Well, there's that too. But that's not what he was asking

... atleast I don't think he was.

you're right. that's not what I was asking

anyway, let me see if I can upload this image

o.k. so that's a bit huge, but you get my point. this is the error of which I spoke. any proposed fixes?

That's due to bugs in the drivers for your computer's graphics hardware.

You can download the current version of the drivers for free from the Web site of the manufacturer of your graphics card.