Shiny transparent textures

The place to discuss creating, porting and modifying Celestia's source code.
Topic author
lukr
Posts: 40
Joined: 16.04.2005
With us: 19 years 4 months

Shiny transparent textures

Post #1by lukr » 20.07.2005, 23:34

During the development of the 'Captain Haddock' add-on I noticed that it seems impossible to make transparent meshes (eg. helmets, canopies) look very shiny.

It seems to me that the specularity is also reduced by the transparency setting.

Is that something that could be relatively easily fixed in the next release? I know there is a lot of other (far more important) work going on, but I thought it might be relatively trivial to fix it.

I've got no coding experience whatsoever, so forgive me if this is equivalent to asking mountains to be moved.

Avatar
selden
Developer
Posts: 10190
Joined: 04.09.2002
With us: 22 years
Location: NY, USA

Post #2by selden » 21.07.2005, 10:47

Did you try adjusting the specularity in the CMOD file?
Selden

Topic author
lukr
Posts: 40
Joined: 16.04.2005
With us: 19 years 4 months

Post #3by lukr » 21.07.2005, 12:18

Dear Selden,

Yes I did try changing specular and specular power settings.

Below is a variation of a picture I posted before in the Tintin thread. I hadn't tried specular values higher than 1 (didn't think it would make sense). I've tried that now (see frontmost row). As you can see there is no difference. Specular values start off at: 1 1 1 and went as high as 100 100 100.

To get a small specular reflection, specular power needs to be set low. Higher values give the impression of a brushed metal. See second row from the right.

Can you see that the specular area itself inherits the transparency value? For a realistic helmet or a spacecraft canopy this specular area should be much brighter (opaque rather than transparent is my guess). Given the black bakground glass would almost behave like a mirror.

Any further thoughts?

Image

Avatar
selden
Developer
Posts: 10190
Joined: 04.09.2002
With us: 22 years
Location: NY, USA

Post #4by selden » 21.07.2005, 17:48

There are two entries for specularity.

specular [color]
specpower <float>

[color] specifies the values (0.0 - 1.0) for the three primary colors: red, green and blue. So
specular [ 1 1 1 ]
means that the specular highlight is white.

specpower specifies the OpenGL "specular exponent" with values of 0.0-128.0. The default is
specpower 1.0
Selden

Topic author
lukr
Posts: 40
Joined: 16.04.2005
With us: 19 years 4 months

Post #5by lukr » 21.07.2005, 21:21

Yes, I figured that out by experimentation. The tests with /any/ combination of values don't seem to give me a more convincing result than the rather faint reflection on the spheres in the picture above.

So, I'm probably right then to conclude that this is a current limitation of Celestia.

Is there any chance somebody can tell me whether this can be fixed or not?

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 7 months
Location: Seattle, Washington, USA

Post #6by chris » 10.09.2006, 03:12

lukr wrote:Yes, I figured that out by experimentation. The tests with /any/ combination of values don't seem to give me a more convincing result than the rather faint reflection on the spheres in the picture above.

So, I'm probably right then to conclude that this is a current limitation of Celestia.

Is there any chance somebody can tell me whether this can be fixed or not?


Celestia is behaving as intended, though you are correct that the appearance of the highlight on a transparent object is not realistic. The problem is that graphics hardware requires that all pixel color channel values are between 0 and 1. Values smaller than 0 get clamped to 0, and values larger than one get clamped to 1. Specular highlights tend to be very bright; realistically rendered ones generate pixel values much larger than one. Unfortunately, the pixel value gets clipped to 1 before it's multiplied by the opacity, so it affects the final blended pixel value much less than it would if it was clipped after the multiplication.

This is another problem that would be fixed by using high dynamic range framebuffers, where pixel values can have a much larger range of values. Other than that, it's possible that premultiplying by the opacity in the shader might do the trick. I'll look into that, but I don't have time for it right away.

--Chris

Topic author
lukr
Posts: 40
Joined: 16.04.2005
With us: 19 years 4 months

Post #7by lukr » 10.09.2006, 08:08

Thanks, Chris. It all makes sense now.

I'm thrilled you are even considering looking into it! I have been following the recent developments closely and don't imagine that this issue currently ranks high on the priority list. One day maybe...

Looking forward to the next release and a big thank you to ALL involved!

lukr


Return to “Development”