Advanced lighting?

[Fenerit]

Bob, if you're talking about Fenerit's exposure -32 screenshot, it's actually supposed to look almost completely white (negative = bright). I think however that either due to a precision problem or a math error at this extreme exposure level, pixel values are going negative instead. It's not a driver problem.

For Dirkpitt:
I've posted it by guessing that you would have already seen it, of course. I'm wandering if the beahviour at -32 would have to do with 32 bit integer; due to the number affinity (so speak the profane). I'm unable to reproduce (I do not why) the strange behaviour that I've had with my taskbar (the blooming around of it) where the gray band tiny chess of the Vincent's screenshot were replaced by the O and 1 listed together!

For T.C
I'm attempting to erase the post concerning my remarks about your "invisible" images; but I'm unable to get the erase button!

[dirkpitt]

No, I understood that, but the white "brightness" (for lack of better
terminology) behaves exactly as my screen was behaving. Where
I was looking at deep black space, I kept seeing white, fuzzy
"brightness."

Bob, fuzzy brightness - bloom - has several causes, but in airless space it is caused primarily by light being bent and scattered in the lens (the human eye/camera). I can show you several photographic references of the ISS glowing in the sunlight, etc.

The brightness of my HDR builds is currently incorrect in certain cases. I'm aware for example of bugs in the brightness of atmospheres and nearby stars. If there are other cases, perhaps in ElChristou's screenshots of models, which do not seem quite right to you please point these out. You can PM me if you feel this forum thread is getting too crowded.

[Chuft-Captain]

DW,

Some feedback...

Firstly, on my machine your HDR build renders textures in a blotchy and seemingly lower resolution and/or lower color-depth fashion. (whether or not bloom is enabled).

Secondly...
Perhaps this is difficult or impossible, but have you considered selectively applying different amounts of the bloom effect depending on the "type" of surface material.
At present it appears that ALL surfaces are treated as though they are the same (eg. metallic in nature, which is probably fine for exterior of many spacecraft), however I'm thinking for example of inflatable space-station modules where large parts of the craft are cloth rather that metal. I would expect less (or no bloom effect) on the cloth parts than on the metallic parts.

I expect there's no easy way to do this as Celestia knows little about surface properties except for specularity and albedo. Perhaps the only way would be to use a new SSC command to enable / disable or specify the amount of bloom on and object by object basis.

Another example is scenes involving land, vegetation and/or human figures dressed in normal clothing, all of which are not completely unheard of in Celestia.
eg.

[dirkpitt]

Firstly, on my machine your HDR build renders textures in a blotchy and seemingly lower resolution and/or lower color-depth fashion. (whether or not bloom is enabled).

This is a limitation of my HDR method - this is called "color banding" or "mach banding". Each pixel is normally 256 values per color, but I compress 512 values into 256. The lower 128 is LDR, higher 128 is HDR. This works ok in many cases, but you'll notice blotches and gradation in darker areas.

At present it appears that ALL surfaces are treated as though they are the same (eg. metallic in nature, which is probably fine for exterior of many spacecraft)

Bloom effect is currently applied to any pixel value that is > 1.0 in brightness (i.e., superbright). Diffuse-only ("matte") materials will never have bloom applied to them, unless maybe if you shine two or more lights on them.

But add any specularity (even low specularity), and you are almost guaranteed to have pixel values becoming superbright and trigger the bloom effect.
So if you've been applying specularity to materials just to "brighten them up" a bit, that trick will backfire in HDR.

[ElChristou]

...But add any specularity (even low specularity), and you are almost guaranteed to have pixel values becoming superbright and trigger the bloom effect.
So if you've been applying specularity to materials just to "brighten them up" a bit, that trick will backfire in HDR.

DW, on the shots I send you via mail, the model is not THAT bright! It would be a really bad limitation to not be able to use spec to play with material anymore...

[dirkpitt]

Could you try sending me the soyuz model+ssc (or maybe just the blue/grey part that's causing trouble)?
It may be a bug in the HDR code so I'd like to check for myself what the real pixel values are.

[dirkpitt]

Update:

It seems that bright models on ElChristou's config (and possible others too) is due to glPixelTransfer not working as expected.

I'm currently using glPixelTransfer in order to extract superbright pixels:

Code: Select all

    blurTextures[blurLevel]->bind();
    glPixelTransferf(GL_RED_SCALE,   8.f*0.2126f);
    glPixelTransferf(GL_GREEN_SCALE, 8.f*0.7152f);
    glPixelTransferf(GL_BLUE_SCALE,  8.f*0.0722f);
    glPixelTransferf(GL_RED_BIAS,   -0.5f);
    glPixelTransferf(GL_GREEN_BIAS, -0.5f);
    glPixelTransferf(GL_BLUE_BIAS,  -0.5f);
    glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE8_ALPHA8, 0, 0,
                     blurTexWidth, blurTexHeight, 0);
    glPixelTransferf(GL_RED_SCALE,   1.f);
    glPixelTransferf(GL_GREEN_SCALE, 1.f);
    glPixelTransferf(GL_BLUE_SCALE,  1.f);
    glPixelTransferf(GL_RED_BIAS,    0.f);
    glPixelTransferf(GL_GREEN_BIAS,  0.f);
    glPixelTransferf(GL_BLUE_BIAS,   0.f);

Brief explanation: I scale each color component up, then chop off the LDR portion using -0.5 bias.

On ElChristou's config, the result is a colorized texture (instead of greyscale luminance), and looks exactly as if I'd commented out the pixel transfer commands!

Since glPixelTransfer has been supported since OGL 1.1, this was supposed to have worked on 99% of all configs.
A simple bug in the above code maybe?

[dirkpitt]

Another update: The Geforce4 MX does not appear to support GL_LUMINANCE_ALPHA textures either (or at least the Mac driver doesn't...)
Luminance ought to be computed as L=R+G+B according to the GL spec, but for some reason it's not. It's probably another driver bug.

This may require adding more render passes - at least 2 more for each R,G,B component to convert to luminance (assuming the final texture is RGBA).
This is on top of the passes needed to scale and bias each color component (as a replacement for glPixelTransfer).

[Vincent]

Another update: The Geforce4 MX does not appear to support GL_LUMINANCE_ALPHA textures either (or at least the Mac driver doesn't...)
Luminance ought to be computed as L=R+G+B according to the GL spec, but for some reason it's not. It's probably another driver bug.

This may require adding more render passes - at least 2 more for each R,G,B component to convert to luminance (assuming the final texture is RGBA).
This is on top of the passes needed to scale and bias each color component (as a replacement for glPixelTransfer).

Wouldn't it be more simple if Christophe and I simply changed our graphics ?

[ElChristou]

...Wouldn't it be more simple if Christophe and I simply changed our graphics ?

Definitively...
Now, perso, changing the card mean changing the laptop... so I'll do that but not yet... (apart for Celestia I'm satisfied with my config so I'll change when flash HD and LED screen will be available...)

[Vincent]

Now, perso, changing the card mean changing the laptop... so I'll do that but not yet...

I think I'll buy a new PC quite soon... So far, I've been interested in keeping a low config to make sure my addons would work on any other system, especially in schools...

[ElChristou]

...So far, I've been interested in keeping a low config to make sure my addons would work on any other system, especially in schools...

It's also my preoccupation; with a hardcore config, will I resist the temptation of doing real HighRes models??

[BobHegwood]

It's also my preoccupation; with a hardcore config, will I resist the temptation of doing real HighRes models??

For shame...

NEVER resist the temptation to create HighRes models.
Some of us very much LOVE your models.

Thanks, Brain-Dead

[ElChristou]

For shame...

NEVER resist the temptation to create HighRes models.

Yep, you say that because you have now a high end PC, but what with your old one? wouldn't be the same story, right?

[Cham]

It's also my preoccupation; with a hardcore config, will I resist the temptation of doing real HighRes models??

I can garanty you that, no, you wont resist !

Especially if you have a large high resolution screen, with a fast video card. There's simply no end to this effect.

[ElChristou]

It's also my preoccupation; with a hardcore config, will I resist the temptation of doing real HighRes models??

I can garanty you that, no, you wont resist !

Especially if you have a large high resolution screen, with a fast video card. There's simply no end to this effect.

I fear so, but really I do want to keep doing models for everybody! ...Let's wait and see...

[BobHegwood]

For shame...

NEVER resist the temptation to create HighRes models.

Yep, you say that because you have now a high end PC, but what with your old one? wouldn't be the same story, right?

I will have you know Mr. El, that I loved, viewed and used ALL of your
models on the very VERY low-end machine too. In fact, everything
worked fine on that machine. That machine was purchased in 1994
and lasted (and was used primarily for Celestia) up until my recent
purchase. The old machine was in fact, VERY much easier to use.

The only things I can see now that I couldn't before are DDS textures.

Granted, I can now use much larger textures, but VT's got around
that limitation on the old machine too.

Just FYI.

[dirkpitt]

Wouldn't it be more simple if Christophe and I simply changed our graphics ?

Haha, that would be the easy way out yes
I'm kidding, there're probably at least a couple more Geforce4 MX users out there apart from you guys.

Anyway - with Christophe's help I think I've come up with another way to get the correct luminance textures that is possibly even better than the existing method (so we do have something to thank the GF4 MX for )

This method uses EXT_blend_subtract and a couple of blending passes instead of glPixelTransfer (which can be slow), and plain GL_LUMINANCE with final output to RGBA to get a luminance + alpha texture. Obviously this can be streamlined considerably in the OGL2 path using shaders, etc but the idea here is to provide something that works acceptably on all cards, not just OGL2-capable ones.

Todo: Integrate this into my Celestia build and benchmark.

[chris]

Wouldn't it be more simple if Christophe and I simply changed our graphics ?

Haha, that would be the easy way out yes
I'm kidding, there're probably at least a couple more Geforce4 MX users out there apart from you guys.

Anyway - with Christophe's help I think I've come up with another way to get the correct luminance textures that is possibly even better than the existing method (so we do have something to thank the GF4 MX for )

This method uses EXT_blend_subtract and a couple of blending passes instead of glPixelTransfer (which can be slow), and plain GL_LUMINANCE with final output to RGBA to get a luminance + alpha texture. Obviously this can be streamlined considerably in the OGL2 path using shaders, etc but the idea here is to provide something that works acceptably on all cards, not just OGL2-capable ones.

Todo: Integrate this into my Celestia build and benchmark.

I'd be happy to help out with the OGL2 implementation. It seems like a lot of the work could be condensed into a single shader, thereby saving framebuffer bandwidth.

--Chris

[MFN1444]

Wow. It looks very impressive, but why it isn't available for "simply users"?

Can we expect some link to this build? Or we most waiting for Celestia 2.0. final release?