Alpha texture "bleeding"

[JulyForToday]

Okay, lately I've been having a technical problem that is driving me nuts, and I don't know how to fix it.

When using alpha maps, there are generally 3 areas of the alpha channel. Totally transparent, semi-transparent (see-through), or totally opaque Usually all three get used.

gimp.jpg (42.82 KiB) Viewed 4358 times

When you see the image in Gimp, it's represented how it should be shown. But in Uru (and windows 2000's explorer preview) the transparency doesn't always display correctly.

alphableeding.jpg (69.08 KiB) Viewed 4357 times

Often times the middle semi-transparent areas have problems when something with an alpha map is in from of something else with an alpha map. The drawing of transparent surfaces doesn't seem to have a problem with being the only transparent surface around. But when you have one object using an alpha channel in front of a different one also using an alpha channel, some funky things can happen.

I had a water plane with a texture that has it's color input (really a texture's transparency setting for the plugin) set to 0.5. And some objects (with normal opaque textures) won't display behind it at all! I had to put an environment map on it, and then it seemed to work, except for everything with an alpha map.

I can't seem to get any of the alpha stuff working correctly to make anything look decent, and I'm not sure if it's just my settings.

[Paradox]

The main issue with Alpha textures is how they are placed in the scene.

I'm sure everyone has noticed a few glitches in Uru with Relto firemarbles in the fog; or the Pod portals against the pod windows...

The plugin tries to put object with Alpha in a separate Span object so that they are rendered properly, but even this has limits. What you might want to do is make sure that the image only has two Alpha values (full opacity, and full transparency), then manually add it to PRPExplorer as a DXT1 image.

[Trylon]

Here, this article might be intreresting:
http://www.sjbaker.org/steve/omniv/alpha_sorting.html

[Grogyan]

Often times the middle semi-transparent areas have problems when something with an alpha map is in from of something else with an alpha map. The drawing of transparent surfaces doesn't seem to have a problem with being the only transparent surface around. But when you have one object using an alpha channel in front of a different one also using an alpha channel, some funky things can happen.

This is a bug with the game engine, which still isn't fixed in MOUL, and I repeatably ticketed, but still no word on it being fixed for MOUL.

CC however, this double transparencys overlapping and cancelling out is quite noticeable, if you know where to look, Er'Cana bushes, lights (texture planes) in Bevin and cavern.

The game engine also has problems rendering dynamic moving shadows, often appearing as choppy and pixelated, but not so noticeable in CC but is quite bad in MOUL.
The game engine also doesn't have a layer dedicated to markers, so in places where markers should move, they don't and vice versa, again this is a bug since prologue and still occurring in Live.

But I digress, back to the point, if you are finding overlapping transparent textures to cancel out that is a bug.

Take this example, load up CC and get the firemarble page or go to Bevin, hover your mouse over the avatar, with the firemarble in between the avatar and 3rd POV camera. Is the problem your having have an effect like this?

Or am I confused about your problem, that you see a "seam" between two textures, couldn't that be fixed using texture blending?
Otherwise the only other way is to open the image, in say MS Paint, fill the empty region in red, thus giving you a good indication on "shades of greay" that can easiy be considered white by mistake.

[Trylon]

No, I'm sorry, but you are wrong about this.
Alpha textures that are incorrectly overlapping is not a "bug" in the game system!
It is a limitation of the current technology.
Read the article I referenced in my previous post in this thread for a rather technical explanation.

Short explanation is that It's not always possible to determine which object should be drawn first, if the wrong object is drawn first, it can't take the transparency of the other object into account, since that one hasn't been drawn yet.

The problem is similar to this: Take an artist who draws a line drawing with an non-erasable pen, but he draws the entire background first into the tiniest detail, and only after that he draws in the people. Since he can't erase the lines that make up the background, in the areas where he draws the people, the people end up having the background drawn into them, in the spots where they should have no ink at all.
The problem is with the order of drawing. Same occurs with the alpha map's, as the graphics card cannot always correctly determine which object to draw first.

Since it's not a bug, but a limitation, Cyan can't fix it, no matter how many bug reports are given out.
The only thing cyan or any writer can do is try to work around the problem, by e.g. manually setting which

[JulyForToday]

Good article, does a good job in explaining what the problem is.

I don't suppose that there is a way yet to sort the alpha polygons with the plugin. In some cases I have a very very clear order of objects that need to be rendered (namely a sky dome with alpha mapped clouds). But this does given me some ideas on how to work around it (like cutting up the dome and cloud layers..).
Thanks guys

[JulyForToday]

Sorry about double posting.. :-D

I've done some experiments, and I've found that you indeed can mess around with the order of the z-index. After messing around with nearly everything, and trying *lots* of settings, I've found that it largely depends on the object names.

The name of objects seem to effect the order they are drawn in. They apparently go in alphabetical and numerical order (so A or 01 is a low value, B or 02 is a higher value).

If an object's name has a greater value (think box20300 as compared to box2) it will apparently be drawn last. Or maybe the plugin sets the z-index based on the names. But changing the names around changes your results. Remember, it's the object name, not the mesh name.

So we have 2 types of transparency:

1.) textures with alpha channels (the .png images with transparency like above in this thread.)
2.) texture layer transparency (the total opacity/transparency of the texture itself (any texture, normal rgb or alpha)

(and maybe a number 3.) vertex paint alpha mapping ... but that we can't do yet).

textures with alpha channels
Most of the time textures with alpha channels seem to respond well to properly ordering the names.

What I mean by proper order is something like this:

01 background (sky gradient)
02 sun
03 clouds
04 sun rays
05 sun glow


Those objects should be named in such a way that the background is drawn first, and the sun glow drawn last. That is why they are number 01-05. If they are not drawn in this order, there will be a glitch in the way those elements look in the game. However, even when they are named properly there still seems to be something else that prevents them from being drawn in the correct order. From my example, my clouds get drawn after the sun rays, and sometimes by the sun glow, and there will be a giant transparent holes in the cloud's element. I suspect that the spans my possible be the reason for this. (the sky dome is curved after all, even if broken in 4)

texture layer transparency
(Set with the col value on the map-input panel for any texture -- needs to be set for each material)

I originally thought this aspect of things wouldn't have much of a problem. It's just the opacity (or lack therof) of the texture layer. If an object has 1 texture, and it's set to 0.5 then the whole texture, and the whole object will appear 50% see-through. I've found that when making objects partially see-through certain problems come up with objects that are behind the see-through object. Entirely opaque objects and objects with alpha-channeled textures both have problems. Again, it seems to be related to the naming of the objects effecting the z-index.

So say you put up a plane like you would a curtain in front of a bunch of objects, name the curtain something beginning with a, and name the objects behind it with the letter k. Give the plane a material with only 1 texture that has no alpha channel. Now set that texture's transparency (col value) to 0.5. Export to Uru, and look at the objects through the curtain. They are invisible! Anything before the letter j won't be shown behind that curtain, regardless of having an alpha channel. Now if you pass your avatar through it (3rd person here), the avatar is on the other side with the objects, but the camera is still looking through the curtain, and the avatar is also invisible. If you name the same curtain something beginning with p, you'll see all the objects before the letter p. The avatar still won't show up though. I tried, but I couldn't figure out how to get the avatar to show.

Now if you take that curtain, and apply an environment map, viola!!! Everything, regardless of name (but not regardless of the alpha channel) will appear, including the avatar.

Environment maps seem to gain priority in the order and are rendered last However if you have two transparent objects with an environment map, you will again run into problems with the draw order.

[Whilyam]

Hmm. I've had this problem, but by setting it to be a transparent object and making sure it has a material, the bleeding goes away for me.

[Trylon]

Well, some things regarding materials aren't yet aas they should be in PyPRP. It is being redone however,but slowly..

[Lontahv]

Have you tried just not having a semi-alpha texture?