Strange transparency issues on some objects

[Irri]

This problem has been around for a few months, but even after upgrading to a newer video card (older Nvidia legacy-driver Geforce2 to a FX5500) it's still going on, and gradually seems to be getting worse.... first it was just the rocks, near Levrus' shop, then some barrels and boxes, now it's even the statue of Laanx and the treetops!

It makes for odd sceenies, but want to see if I can get it fixed before I log one day and see only blueish nothingness

   

Maybe a relight could help??

[loux]

hello, i got the same things too
i will look forward to hear news
loux

[Bartholin]

tough you run linux this is more of an everyone bug. I am using Windows atm and i have the same problem. Seems to me (who has no exper to back him up ) that a few textures/ moddles went missing when they released it.

[Irri]

Hmmm... but the textures are there for me on the rocks and the statue and things, but sometimes they are not fully opaque. The boulders near the magic shop in particular are variable- some days they look normal, some days they are virtually invisible, other days they are bluish and half-transparent like in the screenshot. The pipes and iron gates and ladders in the sewers come and go as well!

[Caarrie]

I used to have this problem in the last version it seems i got rid of it when i built my own client you could try that and see if it helps to resolve this issue. [ati card]

[nerdful1]

I've had those problems since I started a couple weeks ago.  Especially barely visible bars in sewer, and lots of blue or transparent boxes above. Running nvidea n6200 by asus with 9755 driver. Using PCLOS TR3 for linux.

[LigH]

  Irri can speak normally! -- 

__


Some related issues have been tracked for months, together with the CrystalSpace development team.

Transparent textures are in general a big problem for a 3D engine. Usually, 3D rendering is speed-up by using the "Z Buffer" (which is a kind of greyscale image that represents the nearest distance of any object rendered so far) to avoid drawing planes which would be overlaid by previously rendered planes. This works great for solid planes ... But if you use Z Buffer updates while rendering partially transparent textures, the following happens:

- The first thing rendered is the "sky box", which is mainly blue.
- When a close plane with transparent texture is rendered early, the Z Buffer early contains a rather near distance blueprint.
- All the following objects behind the one with transparent textures will not be rendered behind its area.

The result is: You see the sky box behind the transparent texture.

The obvious solution would be to first render all really solid planes, and later render all possibly transparent planes - preferably without Z Buffer updates. Unortunately, this last constraint might result in flickering texture overlays while moving. Apart from the fact that dividing objects into transparent and solid is neither trivial nor reliable.

The effects you see now might be related to tests of how to fix misrendered transparent textures. But I wonder how developers can alter the appearance of objects being defined in the maps - there would have to be a way to change them via server-side messages... Especially the translucent boxes and statue are interesting, but hard to explain.

I am ready to be told that I am completely wrong here, and it is just a graphic driver issue... 

[Induane]

Its definitely strange and I don't know whats going on either.  I have experienced the same issues.  I don't think its a transparant texture issue as these are objects that do NOT have transparent textures and are becoming transparent.  They also aren't showing through to the skybox, instead they seem to be locally transparent, showing grass or whatever is around them under them instead of the skybox.  The transparency issues can be resolved for the most part using convex or concave planes instead of flat planes (really anything but flat) when doing images that have some transparent parts (for example planes with tree leaves), then setting texture_binary flag in conjunction with mix mode alpha.  If issues still remain sometimes setting the z-buffer to ztest for those meshes often will fix it as well.  Given the correct flags and properly made meshes I've not had a single problem with CS's transparency support, although the fact that it can be such an issue without special work shows that its something that needs addressed.

As for this anomaly I would assume it has something to do with a combination of genmesh objects, and an issue with some opengl extension.  Most likely its a bug with the version of CS that was compiled into the client.  A fresh compile with a different date fixed it for me, and it sounds like it fixed it for Caarrie as well. 

[Wired_Crawler]

Those "special effects" are strange indeed, but I'm not surprised by them at all. Similar screens were posted here before numerous times. IMO, transparency handling is somewhat (heavily?) broken in CS (how many times I wrote this ? ). If artist does not explicitly set attributes of textures/objects and if he does not follow some unwritten rules and if he does not spent significant amounts of time on tuning of various subtle parameters, map containing transparency/translucency information sometimes will behave unpredictably (or it will behave predictably wrong).
Let's check Crystal Space features page. Can you find word "transparency" there? No. Developers don't make any announcements about transparency, so we can't demand it working perfectly (or at all ). On the other hand - check Ogre features page. There we can see:

Common requirements like render state management, spatial culling, dealing with transparency are done for you automatically saving you valuable time

Transparent objects automatically managed (rendering order & depth buffer settings all set up for you)

There You could complain, if a game shown similar problems.
Crystal Space has different aims, apparently transparency/translucency is on top of developers' task list. Let's be happy with what we get  (and we get pretty much).

Apart from the fact that dividing objects into transparent and solid is neither trivial nor reliable.

CS code contains (or at least it was there some time ago) quite trivial procedure, which scans whole texture pixel by pixel and checks if it contains transparency information (even distinguishing between binary alpha and smooth alpha), then it sets appropriate attributes accordingly. Apparently this function is not used or is broken or it suffers because of broken image loaders (try csimagetool application with switch -I on several different image formats ).
But I will say the same you said: I am ready to be told that I am completely wrong here .

[LigH]

Well, after reading again, I am sure now that I misinterpreted the topic.

CrystalSoace has issues with transparent textures ... at least if the requirements are not respected correctly, according to opinions in the CrystalSpace IRC channel. In other words: CrystalSpace has techniques to support "textures with transparent parts", but developers need to know how to handle them, it is not a "full automatic" feature.

Transparent objects, however, are a totally different issue. And that is the one Irri reported. I don't know much about CrystalSpace's interna, but if the opacity of usually opaque, solid objects appears to be random, then I would at first expect lazy code to be a reason. Like as if a variable is not well initialized, but used to calculate the opacity of vertices and planes (e.g. usually you can expect a local variable to be initialised to 0, but in case of doubt, set it to 0).

[Irri]

In some cases I /do/ seem to be seeing the blue sky/crystal texture through the objects, and in others, I do not. And what is transparent one day will be fine the next> Hmm... it's kind of like the grass in the forest road- it seems to randomly work.

I'm sure all this will get fixed eventually (of course it will!), I am just trying to give helpful data on a puzzling bug.

And, yes Irri's player has a good grasp of the language most of the people around her are using   

[Caarrie]

when i had it i noticed it was better or worse depending on what time of ingame time it was. I dont recall what times it was best or worse though.

[Eagel]

I've had those 'effects' some time ago, and searching I found this thread and solved my graphics issues.
Hope fix yours

[Rolenun]

If any windows user would like to help troubleshoot this issue, please go here http://trac.crystalspace3d.org/trac/CS/wiki/glIntercept and follow the instructions. Thanks.

[Irri]

Well, here's a bit of an update. The issues happen /much/ less now that I run the game at a higher resolution (1280 x 960 vs 1024 x 768) and have the multi-sampling and anisotropy set to maximum, Vertex buffer is off. I will play around with those and see if there's a spot where the effects return. Maybe that will help a troubleshooter find the issue!