Re: [Celestia-developers] GLSL Betterness!

[Selden E B. Jr <se...@le...>]

Chris,

You wrote

> I was wrong.  Celestia already isn't neglecting the alpha channel for
> textures.  Does the texture in your sample have an opacity of 99% or
> greater?  I'm assuming so, because it seemed to obscure everything behind
> it.

Two thirds of the image (the white parts) are supposed to have an opacity 
Alpha channel value of 255. The other third (which is drawn black)
is supposed to have an alpha channel value of 0. 

What I did was convert the 24bit black-and-white image (ppm) that's used 
for the texture's primary channel into an 8bit grey-scale (pgm)
image and used that to create the Alpha channel in the final PNG image. 
I expected the white areas to be opaque and the black areas 
to be invisible.

Inside the CMOD file, though, the mesh's material is defined to be
opaque (1.0).

> The problem with translucent objects is that in order to render them
> correctly, you usually need to sort the triangles and draw them back to
> front.  Worse yet, if you're really fussy, any triangles that intersect
> each other must be split at the line of intersection. (The z buffer makes
> sorting and/or splitting unnecessary for opaque objects.)  Sorting
> triangles isn't practical for real-time rendering of even moderately
> complex models.

Unfortunately, that makes sense. :-(

> Celestia does a few things to try render translucent objects at least
> approximately correctly in some cases.  It identifies the complete opaque
> submeshes in a model and draws them first.  It then disables the z buffer
> writes (but not the z test!) and renders translucent or partially
> translucent submeshes. Rendering opaque objects first assures that a
> translucent submesh will never completely occlude an opaque one.  Turning
> off z writes means that translucent meshes will never completely obscure
> each other. Even though this doesn't guarantee correct rendering, it
> usually helps in the case when two translucent objects are rendered in the
> wrong order--usually, but not always.  In your trans-bug sample, the final
> image would look much better if the z test was left on.  Since the objects
> are almost completely opaque, it's better to render them using the same
> technique as for opaque objects.

In other words, it'd be best to define individual meshes within a model 
to be entirely translucent or entirely opaque and not to depend on a 
texture to provide the transparency. Is that correct?

(I've been working on a spaceship model where I've found that to seem 
to be the case. So far it looks like its mesh porthole glass is being drawn 
correctly; when it's used as an SSC model, anyhow. I had hoped to be
able to do the portholes in the texture rather than in the model: it'd
be a lot less work.)

> I hope this gives some idea of the issues involved with rendering
> translucent objects. There are some things I could do to improve the
> situation in Celestia. I could make the renderer look at the opacity value
> for mesh materials and the alpha values of texels to choose between the
> opaque (z write on) or translucent (z write off) strategy for drawing.
> Currently, Celestia turns off z write because in the great majority of
> cases when add-on creators use opacity, they use to make mostly
> transparent meshes. Adding a an alpha heuristic would make Celestia draw
> your model correctly, but is it worth adding?  Is there a case where
> someone would use 90% opacity?

Textures used for 3D DSC nebulas have varying opacity, of course.
I'm not sure if magnetosphere models would qualify. They'd tend
to have low opacity values, too.

Slightly different issue, probably not critical for 1.4.0:
3D nebulas would look a lot better if there were some way to draw 
them "properly". Simply depth sorting their vertices (as if opaque)
would be a big help.

FWIW, I'd been trying to make a 3D version of the Orion Nebula 
(similar to what was done by the Hayden) but just gave up after a 
while (but mostly due to my own problems with coming up with a 
reasonable distance assignment algorithm: slopes for the regions
with intermediate brigtness values are ambiguous :-(  ).

> Another thing that Celestia could do is some rough back to front sorting.
> It's not perfect, but sorting meshes at submesh granularity would help
> when rendering objects containing several translucent submeshes. It would
> do nothing for your example model however. For cases when a texture
> contains a mixture of completely opaque and completely transparent pixels,
> Celestia could also use an OpenGL feature called the alpha test, which can
> completely discard transparent pixels. Has anyone created an add-on where
> this would help?

The cases that I'm aware of are my own: the non-CMOD DSC graticules.
They're a solid color in the primary channel and all the lines are
provided by opaque regions in the alpha channel.
Since their textures consist mostly of areas with opacity=0, 
and the graticule areas have opacity=255, 
I'm guessing that it might help performace for them.

Would this seem to sharpen edges, too? One of the things I'd
noticed was that as the graticule textures are magnified, the 
magnified edges of the opaque regions become blurred and translucent.

> Finally, there's the order independent transparency technique I mentioned
> in a previous message. I'm still thinking about it, but I believe the fact
> that it requires several passes over the entire scene makes it impractical
> to use in Celestia. In any case, here's an image of it used in my 4D
> surface renderer:

> http://www.shatters.net/~claurel/images/hypertorus-1.jpg

> Another drawback is that it only works for GLSL-capable hardware . . . :(

I'd suggest considering it seriously for the OpenGL V2 render path 
(or a new one) in some major release of Celestia after this one.

I hope these thoughts help a little.

Selden




> --Chris


> >> OK . . . I believe that this should be quite easy to fix.  Celestia
> >> seems
> >> to be neglecting the alpha attribute of textures for CMOD files; it
> >> needs
> >> to treat meshes with alpha textures the same as meshes with an opacity <
> >> 1.0.  Unfortunately, there will remain some problems with depth sorting
> >> of
> >> transparent objects.
> >
> > OK.