Celestia Forums

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:

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

cartrite wrote: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!

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"?

Derek wrote: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?

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

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

cartrite wrote: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

cartrite wrote: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.

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

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

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

chris wrote: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.

chris wrote: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.

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

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

BobHegwood wrote: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

cartrite wrote: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

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

BobHegwood wrote: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

edit 5:30 pm