Small note about CS transparency problems

[LigH]

I asked in #crystalspace again about possible reasons for rendering problems behind transparent textures. 'mdmkolbe' told me the following:

well you have to make the Z buffer read-only when rendering transparent textures
(and render transparent textures after all the solid textures)   
I don't know how much of the Z buffer stuff CS will take care of for you

The last sentence might be related to rendering priorities I guess.

You have probably read such kind of tips several times; unfortunately, searching for "transparency" returns too many hits to find a good one. But I am curious if the reason is already addressed, or if you are still looking for a reliable solution.

[Wired_Crawler]

I asked in #crystalspace again about possible reasons for rendering problems behind transparent textures. 'mdmkolbe' told me the following:

well you have to make the Z buffer read-only when rendering transparent textures

According to CS docs you make z-buffer read-only by setting z-buffer mode to ztest. Unfortunately, this does not help always (but sometimes it do helps, especially when combined with proper render priority and mixmode alpha).

(and render transparent textures after all the solid textures)

AFAIK there isn't anything like texture priority (maybe binary alpha does it, but it is not acceptable in all cases). CS is object-oriented engine, so if you have model built of both transparent and non-transparent parts you have a problem .

I don't know how much of the Z buffer stuff CS will take care of for you

That's bad. Who should know it, if developers don't  ?

LigH, it seems, that there are two persons which see problems with transparency in CS: You and me . The rest desperately tries to use what they have . There are very few entries in history.txt related to transparency handling, there are no bug reports regarding transparency in CS bugtracker, also I couldn't find many (any?) complaints about it on CS forums.
IMO, transparency handling is one of weakest CS features. There are numerous problems related to this:

• incorrectly recognized color formats - try gfxtest application (gfxtest --info imagename) on different images, all PNG's and TGA's are always recognized as 256-color images, TGA's appear to always have alpha channel present. Why walktest and PS work "OK" ? They cleverly initialize one of parameters ("format" property if I am not mistaken) to recognize all images as truecolor images with alpha channel. Strange. I'm sure that format detection routines don't work properly.
• sorting (render priorities) problems - there is no way to define proper order of rendering without using lots of renderpriorities (which now can't be defined in map files); back2front sorting (priority alpha) does not always help.
• visibility culling problems - look at the following simple scene: three cubes and plane with transparent texture (binary alpha set). The plane has attributes: priority alpha and ztest, culler used: dynavis (frustvis it works fine).

[td]The scene

[/td]
[td]Oh! You can't see cubes through transparent texture!

(moving or turning slighgtly makes cubes appear/disappear)[/td]
[/tr][/table]
You can see this effect in PS in numerous places. Let's hope pvsvis will fix it  .

• transparent objects with incorrectly defined parameters tend to behave randomly (sometimes they look better, sometimes worse)
• last, but not least - parts of CS documentation regarding alpha maps are not sufficient, some more info with different, less and more complicated examples, would help map designers.

[LigH]

Simple test scenes are surely the best to demonstrate these issues...

I recorded another chat and uploaded it to my webspace, hope it explains more.

I already understand that visibility culling must not occur behind partially transparent textures; Object orientation in this case is not too helpful though, when it comes to tather complex and especially "concave" objects; if the rendering order cannot be determined by the GPU, then the CPU may have to pre-order the object's parts before rendering, to avoid "Escher" results (wrong depth order, making the object look like self-prenetrating).

(moving or turning slighgtly makes cubes appear/disappear)

This is the effect which seems to prove that specific calculations in CrystalSpace are not reliable. Priority textures must be drawn reliably always in the same way, or the priority rules are unusable. Even a check if an object is completely covered by another, must be disabled if one of them is partially transparent.

[Induane]

I've investigated this further as well.  Well, at least I've attempted to find a combination of flags in blender2crystals exporter that would produce good results because I've been trying to make some nice low poly trees.  In that I think I suceeded.  All I did was add a property to the genmesh plane that has the transparant texture.  The flag I ended up setting was a boolean, - texture_binary TRUE

and when exported I can find no issues at all on any of my tests.  Before I was using a combination of aplha priority, ztest zbuffer, with dynavis culler.  Not sure if that helps but it really made a major difference for me.

[Wired_Crawler]

The flag I ended up setting was a boolean, - texture_binary TRUE

Setting texture_binary to "true" in blender2crystal adds "binary alpha" tags to textures definitions. Yes, it helps in many cases, but not always (see images I posted above, texture_binary was set to "true" for the plane). Additionally - binary alpha does not allow having semi-transparent parts of textures (smooth transitions between opaque and transparent areas), You will see only fully opaque or fully transparent parts.
All of this is in described in CS docs.

[Induane]

well the issue I had was that setting it in the blender2crystal gui (I hope I was doing it right) didn't seem to make a reflective change in the properties area.  Setting it manually made the difference so that could be a b2cs bug.. I was using a cvs checkout of it.  I also noticed that if you set objects that can be obscured by it to clipping "false" then they quit disappearing in many cases.