#146 RGBA textures no go in OGL2 for meshes

[cartrite]

RGBA textures are not rendered properly in OGL2 render path when declared in the mesh's ssc file. A good example of this is to use my 3dmars addon from the ML and use Don Edwards Mars Texture "Mars_4k-050104.zip" and rename it to mars.dds and place it in the textures/hires folder. Then goto Mars. In OGL2 render mode the texture will turn black. All other render modes render it properly.

[cartrite]

Logged In: YES
user_id=1965129
Originator: YES

I tried Selden's suggestion and added a line to the 3dmars model as follows:
texture0 "mars.*" and this did not fix the "Black" rendering in OGL2.

[cartrite]

Logged In: YES
user_id=1965129
Originator: YES

I found this behavior has to do with the Modify command in the ssc file.
The RGBA texture renders properly if I don't use Modify and use "Mars2" "Sol/Mars" and assign a custom orbit instead.

[Chris Laurel]

Logged In: YES
user_id=159994
Originator: NO

I found the source of the problem, and it turns out that it's not related to Modify. The reason that the version without Modify was rendered correctly is because it used an old style atmosphere. The new atmospheres are rendered as spherical shells, and when an planet is translucent, the dark back part of the atmosphere shell is getting painted over the planet.

The explanation for this behavior is convoluted. For opaque objects, writes to the depth buffer are enabled. Any object behind an opaque object will be occluded, regardless of rendering order. In contrast, translucent objects are rendered without depth buffer writes to minimize artifacts from unsorted rendering. This means that an object rendered after a translucent object will obscure it, even if the translucent object is in front.

Celestia treats any object with a texture with an alpha channel as translucent, regardless of whether there are actually any texels with opacity < 1. The only way around this would be to actually load the texture and scan for translucent texels, which isn't done right now.

Celestia could render the atmosphere shell before the planet, but this also means that the atmosphere could be rendered before the rings, which messes up the appearance of rings as viewed from a planet's surface.

Another possibility is for Celestia to treat any object with an atmosphere as opaque. This might prevent some special effects using atmospheres, but using atmospheres for purposes other than their intended use is likely to be troublesome anyway.

[Chris Laurel]

Logged In: YES
user_id=159994
Originator: NO

To summarize my last ramble. To reproduce this bug, an object must have three things:
- A mesh
- A texture with an alpha channel
- Scattering atmosphere

[cartrite]

Logged In: YES
user_id=1965129
Originator: YES

If Modify is used your summary is true. However, with 3dmars as an example, if you change:
- Modify "Mars" "Sol"
to
- "Mars2" "Sol/Mars"
in the mars.ssc file, An RGBA texture is rendered in OGL2 with the new atmosphere code.

[cartrite]

Logged In: YES
user_id=1965129
Originator: YES

Sorry.
Forget what I just posted above.
Chris your summary is correct.
I thought an RGBA was being rendered but I was going to the wrong model.

[Chris Laurel]

Logged In: YES
user_id=159994
Originator: NO

I just checked in a simple fix for this bug: depth buffer writes are no longer disabled for translucent objects when scattering atmospheres are enabled. In the future, we'll turn on scattering for objects other than planets, and this code should be revised slightly to allow scattering together with depth write off for some objects (e.g. surface features of planets.)

Cartrite, if you could independently verify this fix, I'll close the bug.

[Chris Laurel]

Logged In: YES
user_id=159994
Originator: NO

Verified fixed by cartrite; closing.