Page 1 of 1

OpenGL 2.0 issues

Posted: 12.08.2006, 15:45
by abramson
Friends,

For some time I have noticed that there is something wrong in the way that Celestia displays when I select the OpenGL 2.0 render path. It happens at both my desktop machines, at home and at work, both sporting GeForce FX 5200 cards, 128MB, with updated drivers. PC's are XP boxes, Pentim 4 3Ghz, 1 and 2 GB RAM.

The first effect I saw when choosing the OpenGL 2.0 path is that haze in atmospheres is not seen, as opposed to what happens when choosing the vertex/combiners path. Shadow borders, nevertheless, are correctly displayed smooth by OpenGL 2.0.

The most recent problems I have seen are the lack of the new atmospheric effects recently incorporated by Chris, which I tried with a fresh CVS distribution, compiled by myself. For example, when reproducing the sunset image shown by Chris, what I see under OpenGL 2.0 is almost identical to what I see under vertex/combiners.

Does anyone have a suggestion? Is there a setting that I could change, either in Celestia, or in the display properties? Thanks in advance.

Guillermo

This is the content of the OpenGL info box in Celestia:

Code: Select all

Vendor: NVIDIA Corporation
Renderer: GeForce FX 5200/PCI/SSE2
Version: 2.0.3
Max simultaneous textures: 4
Max texture size: 4096
Point size range: 1.000000 - 63.375000

Supported Extensions:
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
GL_ARB_half_float_pixel
GL_ARB_imaging
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_occlusion_query
GL_ARB_pixel_buffer_object
GL_ARB_point_parameters
GL_ARB_point_sprite
GL_ARB_shadow
GL_ARB_shader_objects
GL_ARB_shading_language_100
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_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_vertex_shader
GL_ARB_window_pos
GL_S3_s3tc
GL_EXT_texture_env_add
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_compiled_vertex_array
GL_EXT_Cg_shader
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_framebuffer_object
GL_EXT_multi_draw_arrays
GL_EXT_packed_depth_stencil
GL_EXT_packed_pixels
GL_EXT_paletted_texture
GL_EXT_pixel_buffer_object
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_shared_texture_palette
GL_EXT_stencil_two_side
GL_EXT_stencil_wrap
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_texture_sRGB
GL_EXT_timer_query
GL_EXT_vertex_array
GL_HP_occlusion_test
GL_IBM_rasterpos_clip
GL_IBM_texture_mirrored_repeat
GL_KTX_buffer_region
GL_NV_blend_square
GL_NV_copy_depth_to_color
GL_NV_depth_clamp
GL_NV_fence
GL_NV_float_buffer
GL_NV_fog_distance
GL_NV_fragment_program
GL_NV_fragment_program_option
GL_NV_half_float
GL_NV_light_max_exponent
GL_NV_multisample_filter_hint
GL_NV_occlusion_query
GL_NV_packed_depth_stencil
GL_NV_pixel_data_range
GL_NV_point_sprite
GL_NV_primitive_restart
GL_NV_register_combiners
GL_NV_register_combiners2
GL_NV_texgen_reflection
GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4
GL_NV_texture_expand_normal
GL_NV_texture_rectangle
GL_NV_texture_shader
GL_NV_texture_shader2
GL_NV_texture_shader3
GL_NV_vertex_array_range
GL_NV_vertex_array_range2
GL_NV_vertex_program
GL_NV_vertex_program1_1
GL_NV_vertex_program2
GL_NV_vertex_program2_option
GL_SGIS_generate_mipmap
GL_SGIS_texture_lod
GL_SGIX_depth_texture
GL_SGIX_shadow
GL_SUN_slice_accum
GL_WIN_swap_hint
WGL_EXT_swap_control

Posted: 12.08.2006, 17:27
by selden
#1
From what Chris has written (either here or in the developers' mailing list, I don't recall which) the original Haze effect is not going to be implemented in the Opengl 2.0 render path. An equivalent effect is being drawn due to the atmospheric dispersion effects now implemented, but it isn't as pronounced. Note the brightening of the limb when Show Atmosphere is enabled. You could try varying the Mie and Rayleigh parameters to see what differences they make.

I created this "Addon" SSC file to demonstrate the effect and make the images below:

Code: Select all

Modify "Earth" "Sol" {
   Atmosphere {
# -------------------
Mie 0.001
MieAsymmetry -0.15
Rayleigh [ 0.001 0.0025 0.006 ]
Absorption [ 0 0 0 ]
MieScaleHeight 12
# -
}
}


Here's what I see with and without atmosphere enabled. There's clearly a haze effect.

Image Image

(Sorry, no URLs: I couldn't take the time to fight with the space problems.)

#2
Did you remember to add the Mie and Rayleigh parameters as above?
(It does still need some more work. Stars are vislble while the sun is up, and the atmosphere doesn't always go all the way to the horizon.)

This is what I see in the OGL2 render path. The other render paths have a much redder horizon.

Image

And here is a Cel: url to take you there:

sunset

(It works for me using Firefox under Windows)

[edit]
System:
1GB 3.4MHz P4-550, WinXP Pro SP2
128MB GF6600GT, ForceWare v84.21
Celestia built from CVS on Aug.10.

It should work with any of the 5nnn cards, too.
[/edit]

Posted: 12.08.2006, 19:12
by abramson
Many thanks, Selden. As always, your reply has gone directly to the point. I wasn't aware of the limitation of the OpenGL 2 path to render the "traditional" haze. I have used your suggested parameters for the atmosphere, and the display is as it should. There is nothing wrong with my cards.

Regards,

Guillermo

Posted: 13.08.2006, 12:00
by bdm
selden wrote:(It does still need some more work. Stars are vislble while the sun is up, and the atmosphere doesn't always go all the way to the horizon.)

This is not as unrealistic as one may think. It is possible to see a couple of the brightest stars during the day with the naked eye when the sun is up. It's a matter of knowing exactly where to look, like Venus. Sirius, for example, can be surprisingly easy to see during the day under the right conditions.

I think what's needed is some way of limiting the magnitude of stars. The limiting magnitude of the daytime sky is about six or seven magnitudes brighter than the nighttime sky. The sky is also much brighter, which makes the few stars that are visible during the day much harder to see.

Posted: 13.08.2006, 16:39
by cartrite
The amount of stars visible during daylight is controllable by the height field in the atmosphere declaration in the ssc file. With the new OGL2 cvs code anyhow. These following screenshots all use MieScaleHeight 16. The first has height set to 30 km. Even though the sky is almost black almost no stars are visible.

Image

The second uses 20 km for the height.

Image

The third and fourth use 10 km height. Note that all the shots are about 15 km high from the earth except the last one is about 7 km. Notice all the stars that are visible even with a blue sky.

Image

Image

Anyhow the higher the atmosphere is in the ssc height field the less stars are visible.
I like to have it at 30.

cartrite