OpenGL Simply does NOT perform correctly.

[BobHegwood]

Sorry to bother again, but I thought that I'd try once more here. I can still not use the OpenGL 2.0 rendering path on my system without major problems in the displays which are generated by Celestia. Two main areas here. The first is simply the incredible brightness of the planets even when displayed using 100% specularity, or 2% for that matter. Jupiter, Saturn, and especially Venus are simply NOT acceptable. The other problem occurs with cloud shadows. When I go to Jupiter or Saturn, there is such a mess of dark lines displayed that I cannot use this feature. I am including my Nvidia code below just to see if anyone can spot a problem. My drivers are all updated, to no avail. This has been my problem since I bought this machine, and I simply have to use the Multi texture mode in order to View Celestia in a pleasing manner. Again, can anyone see something wrong with my OpenGL Driver info below? Thanks, Bob

Venus under OpenGL 2.0:


Venus under Multi texture mode:


Jupiter with clouds under OpenGL 2.0:


Jupiter under OpenGL 2.0 with NO clouds:


Jupiter with clouds under Multi texture:


Saturn with clouds under OpenGL 2.0:


Saturn with clouds under Multi texture:


Saturn under OpenGL 2.0 with NO clouds:

Code: Select all

Vendor: NVIDIA Corporation

Renderer: GeForce 8400 GS/PCI/SSE2

Version: 2.1.1

GLSL version: 1.20 NVIDIA via Cg compiler

Max simultaneous textures: 4

Max texture size: 8192

Max cube map size: 8192

Point size range: 1.000000 - 63.375000



Supported Extensions:

GL_ARB_color_buffer_float

GL_ARB_depth_texture

GL_ARB_draw_buffers

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_float

GL_ARB_texture_mirrored_repeat

GL_ARB_texture_non_power_of_two

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_ATI_draw_buffers

GL_ATI_texture_float

GL_ATI_texture_mirror_once

GL_S3_s3tc

GL_EXT_texture_env_add

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_compiled_vertex_array

GL_EXT_Cg_shader

GL_EXT_bindable_uniform

GL_EXT_depth_bounds_test

GL_EXT_draw_buffers2

GL_EXT_draw_instanced

GL_EXT_draw_range_elements

GL_EXT_fog_coord

GL_EXT_framebuffer_blit

GL_EXT_framebuffer_multisample

GL_EXT_framebuffer_object

GL_EXTX_framebuffer_mixed_formats

GL_EXT_framebuffer_sRGB

GL_EXT_geometry_shader4

GL_EXT_gpu_program_parameters

GL_EXT_gpu_shader4

GL_EXT_multi_draw_arrays

GL_EXT_packed_depth_stencil

GL_EXT_packed_float

GL_EXT_packed_pixels

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_stencil_two_side

GL_EXT_stencil_wrap

GL_EXT_texture3D

GL_EXT_texture_array

GL_EXT_texture_buffer_object

GL_EXT_texture_compression_latc

GL_EXT_texture_compression_rgtc

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_integer

GL_EXT_texture_lod

GL_EXT_texture_lod_bias

GL_EXT_texture_mirror_clamp

GL_EXT_texture_object

GL_EXT_texture_sRGB

GL_EXT_texture_shared_exponent

GL_EXT_timer_query

GL_EXT_vertex_array

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_buffer_float

GL_NV_conditional_render

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_fragment_program2

GL_NV_framebuffer_multisample_coverage

GL_NV_geometry_shader4

GL_NV_gpu_program4

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_parameter_buffer_object

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_transform_feedback

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_NV_vertex_program3

GL_NVX_conditional_render

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



[cartrite]

Your specs look almost like mine.
Jupiter and Saturn shouldn't have any cloud shadows. They don't have an official cloud map. What are you using as a cloud map for these planets? Do they have an alpha channel like earth cloud maps. Theses planets would be tough to implement cloud shadows because Jupiter and Saturn has no surface and the surface of Venus is completely blocked by the clouds. So how would the cloud shadows work? There is no surface to draw shadows on. How do you define them as clouds in the ssc file? Maybe you should consider using a cloud normalmap and leave the cloud shadows off for those planets.

I didn't see any problems with the official Saturn and Jupiter textures with cloud shadows on. Maybe you are using different textures and there is a problem with them. You are trying to do something special here no?
cartrite

[BobHegwood]

Your specs look almost like mine.
Jupiter and Saturn shouldn't have any cloud shadows. They don't have an official cloud map. What are you using as a cloud map for these planets? Do they have an alpha channel like earth cloud maps. Theses planets would be tough to implement cloud shadows because Jupiter and Saturn has no surface and the surface of Venus is completely blocked by the clouds. So how would the cloud shadows work? There is no surface to draw shadows on. How do you define them as clouds in the ssc file? Maybe you should consider using a cloud normalmap and leave the cloud shadows off for those planets.

I didn't see any problems with the official Saturn and Jupiter textures with cloud shadows on. Maybe you are using different textures and there is a problem with them. You are trying to do something special here no?
cartrite

Yes, you are correct. I'm using Runar's Saturn textures, and Jupiter Clouds from another add-on. Sorry, do not remember who's. Aside from the clouds though, which I now understand (I think) what about the overly bright planets? This has been my main problem with OpenGL 2.0 from day one. Does no one else have this problem?

At any rate, thanks very much for the cloud explanation. Again!

[Derek]

Hi Bob,

There was sometime ago a similar thread where it was said that "cloud shadow" would produce results like yours and which I also get if used with planets other than Earth.
As for your bright planets are you perhaps using "SpecularTextures"?

[BobHegwood]

Hi Bob,

There was sometime ago a similar thread where it was said that "cloud shadow" would produce results like yours and which I also get if used with planets other than Earth.
As for your bright planets are you perhaps using "SpecularTextures"?

Whether I do use them (or NOT) I get the same results in OpenGL 2.0... I am using NO specularity map for venus, but I have tried playing with the specularity settings in the SSC files to NO avail.

I understand the cloud problems now thanks to Cartrite, but this brightness thing has me stumped. I almost NEVER use the OpenGL 2.0 path now simply because of the brightness problems. Am I the only one this problem occurs to?

[cartrite]

You should probably check your settings in the Nvidia Control panel. I can get close to what you posted by turning the digital vibrance and gamma correction up with ambient light set to medium. But yours is brighter. Are you sure that Nvidia has the proper settings for your monitor? I'm not sure how Windows does this except that you should have the proper drivers for the monitor. Do you have the monitor set to very bright?
cartrite

[cartrite]

Do you get the same results when using all official textures and data files that came with the official 1.5.0 download?
cartrite

[BobHegwood]

You should probably check your settings in the Nvidia Control panel. I can get close to what you posted by turning the digital vibrance and gamma correction up with ambient light set to medium. But yours is brighter. Are you sure that Nvidia has the proper settings for your monitor? I'm not sure how Windows does this except that you should have the proper drivers for the monitor. Do you have the monitor set to very bright?
cartrite

Have done as you suggested and I thank you once again. Here's what I did...

My brightness was set at 50% and I lowered it to 0% and it made NO change to the brightness of Venus when in OpenGL 2.0 mode.
Gamma correction was also set to 50% - but again - changing this value has no effect to Venus (No noticeable effect anyway.)
Digital vibrance was set at 0% so I don't think it has any effect. I also have the Nvidia settings handled as "Let the 3D application decide."

Have all the latest drivers, but perhaps this is simply a problem with my particular machine. 'Tis just very frustrating to me since I have been trying to
use the OpenGL 2.0 mode since I bought this machine. The displays (and Celestia itself) run beautifully under Multi texture, so I guess I'm just stuck with this.

At any rate, I really appreciate your advice, and I'll leave you alone for a while.

Again, thanks very much, Brain-Dead Bob

[BobHegwood]

Do you get the same results when using all official textures and data files that came with the official 1.5.0 download?
cartrite

Yes I did... Thanks.

[abramson]

Bob, I can't help, but I wanted to mention that I also had the problem with the clouds shadows on Saturn (I didn't have clouds on Jupiter) under OGL2. Interestingly, the shadows corresponded to Earth's clouds, and I think, from thir shape, that the same happens in your case. That was certainly a problem with the video card memory, which was keeping a texture at a wrong memory space. I was never able so solve it, but it went away by itself, without me realizing how: either with new drivers, or a new Celestia version.

Guillermo

[BobHegwood]

Lest anyone thinks I'm criticizing here...

Please be aware that I am NOT criticizing. This program (and all of its creators) deserve an immense amount of thanks from all of us here. I am very grateful that I CAN use the Multi texture mode in order to view Celestia in a manner which is pleasing to me. Great forethought and brilliance have gone into this entire system, and I am, again, extremely grateful for this experience.

Many thanks to Chris, Fridger, Cartrite, Vincent, and especially to Selden - who always has to put up with jerks like me.

I am simply unable to resolve the brightness problem (in OpenGL 2.0) but I can still enjoy my favorite activity using the other mode, so again thanks very much for all of the help here. Methinks honestly that this problem is simply related to my particular machine, but I can certainly live with it.

Thanks again, Bob

[chris]

Bob,

It's true that cloud shadows simply do not look correct on gas giants with some of the existing cloud textures. I'll find a way to address this problem, but for now just turn off cloud shadows.

As for the extra brightness in OpenGL 2.0: simply turn down the ambient lighting (via the render menu, or the { key.) In Celestia, ambient light is just a little extra illumination added in to assist visualization--it's not realistic. In space, shadows tend to be very dark, as there aren't many surfaces near by to reflect light and give the generally softer lighting that we're used to here on Earth.

In the non-OpenGL 2.0 render paths, color 'clamping' occurs in the vertex processing stage. In OpenGL 2.0, it doesn't happen until later, during the pixel processing stage. The net result is that there are 'overbright' pixels in the OpenGL 2.0. This is in fact a more accurate depiction than in older render paths of what you would see if there was some sort of ambient light in space.

--Chris

[BobHegwood]

Bob,

It's true that cloud shadows simply do not look correct on gas giants with some of the existing cloud textures. I'll find a way to address this problem, but for now just turn off cloud shadows.

No problem Chris. Thanks for the advice.

As for the extra brightness in OpenGL 2.0: simply turn down the ambient lighting (via the render menu, or the { key.) In Celestia, ambient light is just a little extra illumination added in to assist visualization--it's not realistic. In space, shadows tend to be very dark, as there aren't many surfaces near by to reflect light and give the generally softer lighting that we're used to here on Earth.

In the non-OpenGL 2.0 render paths, color 'clamping' occurs in the vertex processing stage. In OpenGL 2.0, it doesn't happen until later, during the pixel processing stage. The net result is that there are 'overbright' pixels in the OpenGL 2.0. This is in fact a more accurate depiction than in older render paths of what you would see if there was some sort of ambient light in space.

--Chris

Again, I appreciate the help here. When I do as you suggested (using the { key) I still see an overly bright spot in the center of Venus though. It is NOT as blinding, but makes the whole display un-appealing because the rest of Venus is so dark. Not to worry though... I'll play with it some more.

Again, MANY thanks for all that you guys do here.

[BobHegwood]

One other quick note here...

OpenGL 2.0 is the ONLY path I have any trouble with on this PC. ALL of the other paths render any object in a pleasing manner. This includes Basic, Multi texture, OpenGL Vertex, and the OpenGL Vertex program/NVIDIA Combiners modes.

Again, it is only the OpenGL 2.0 path giving me trouble.

Is it possible that my screen (HP w2207) is the problem? This is a very large flat screen.
Just FYI...

Thanks, Bob

[cartrite]

You probably already tried this but what the hell.
http://h10025.www1.hp.com/ewfrf/wc/soft ... ct=3363837
cartrite

[chris]

One other quick note here...

OpenGL 2.0 is the ONLY path I have any trouble with on this PC. ALL of the other paths render any object in a pleasing manner. This includes Basic, Multi texture, OpenGL Vertex, and the OpenGL Vertex program/NVIDIA Combiners modes.

Again, it is only the OpenGL 2.0 path giving me trouble.

Is it possible that my screen (HP w2207) is the problem? This is a very large flat screen.
Just FYI...

It has nothing to do with your screen or driver or anything else. Celestia is behaving exactly as programmed. You are getting the expected results when increasing the ambient light level.

With non-HDR rendering, the each color component of a pixel--red, green, and blue--has a value between 0 and 1. Each pixel color component is computed as the texture color times the light color (ignoring effects of specular light and atmospheric scattering for a moment.) The light color is the sum of the colors of all light sources, including ambient. Like texture colors and pixel colors, light source colors components are also values between 0 and 1. However, the sum of the light sources colors ay produce color components greater than 1. In render paths other than OpenGL 2.0, each component of the light color sum is clamped automatically by the hardware to a value of 1 or less before multiplying by the texture color. No such clamping is done in the OpenGL 2.0. This could be changed by adding a single shader instruction to clamp the light color. However, this would give less realistic images in situations where there is more than one light source.

I suppose that one workaround would be to scale the light intensities by (1 - ambient) to guarantee that pixel color components don't exceed 1 when there is a single light source.

--Chris

[BobHegwood]

You probably already tried this but what the hell.
http://h10025.www1.hp.com/ewfrf/wc/soft ... ct=3363837
cartrite

Yes, I tried the option (But only after you suggested it. ). Makes no difference whatsoever.

I'll shut up for a while now. Thanks VERY much for your attempts to help here, but I guess Chris knows
what he's talking about, so I'll simply leave it alone now.

Thanks again, Bob

[BobHegwood]

Okay Chris, I finally have this bug figured out.

The "Brightness" for lack of better terminology, is being caused by the way in which my PC is handling the Ambient Light values supplied by Celestia in the OpenGL 2.0 render path. If I set the Ambient Light value to "None," then the brightness on Venus, Saturn and Jupiter simply does not appear any more. The problem then becomes something else altogether. After changing this setting, the planets and moons are simply way too dark to view properly. This occurs even when I set my monitor's brightness setting all the way up. This is okay though. I thought that I was nuts because I could NOT see what was happening, and why it was happening only to me. Apparently, HP's w2207 monitor needs some driver and/or machine code changes.

This is just for information. Hope it helps someone else.
Thanks for your patient explanations and attempts to help me here. I do appreciate it.

Take care, Brain-Dead Bob

[cartrite]

Apparently, HP's w2207 monitor needs some driver and/or machine code changes.

If there is a way to do it,? you should make sure that the monitor is using the HP driver and not one supplied by Vista.
Or maybe vise versa?
cartrite

[John Van Vliet]

edit 5:30 pm