Alpha Z Order problem?

BlitzMax Forums/MiniB3D Module/Alpha Z Order problem?

Kittomer(Posted 2011) [#1]
Can anyone explain this?



This is what it SHOULD look like:



It happens when I load the texture atlas for the terrain with the alpha flag enabled.

I searched around but I wasn't able to find a solution or even an explanation.

The texture is a 24bit PNG with transparency.


Yasha(Posted 2011) [#2]
EDIT: aww nuts I answered this on autopilot assuming we were in the Blitz3D section. The answer below may be true of OpenGL 1.whatever miniB3D uses, or it may be totally off; I have no idea. Sorry!


---


DirectX 7 doesn't support Z-ordering for polygons with alpha, sadly. Blitz3D will attempt to order the polygons based on the centre position of the whole object, so if the cube is nearer to the camera than the centre of the terrain, it will be drawn after the terrain, regardless of individual polygon positions. Within the object, polygons will be drawn in their mesh order regardless of distance from the camera, so it's best for alpha objects to be completely convex, too.

The best way to fix this is to severely limit your use of alpha, by splitting your larger objects into small, convex components that either do or don't have alpha applied to them at the moment. That way you can make it so that as far as possible the cube only overlaps subunits of the terrain that don't currently have alpha applied.

This restriction doesn't apply to masked textures, by the way, since texels are either visible or not, and it's therefore easy for a pixel to have a fixed depth value.

Last edited 2011


AdamRedwoods(Posted 2011) [#3]
Pretty much the same.

When your whole texture is flagged for alpha, you're going to get a mixed bag of sorting for all those objects, which as Yasha explained is based on z-ordering the center of each object. It needs to be drawn in a layered order from furthest to closest.

To fix this in miniB3D, there are a few ways. I usually set the atlas texture to a non-alpha, so by default, objects get the depth-buffer in openGL. But for any alpha entities, try setting them to be alpha-sorted, and it should solve the problem:
EntityFX(yourentity, 32)
'' ...or...
EntityAlpha(yourentity, 0.9999)


Last edited 2011


ima747(Posted 2011) [#4]
Entities randered with alpha are manually render ordered by minib3d based on object center point distance from camera. There can be plenty of quirks for plenty of reasons. Generally speaking if ordering is critical you can't involve alpha or things are going to go sideways on you... I'm a huge fan of alpha effects but the headaches they can raise are pretty staggering. A simple hack, if you can afford the overhead, in some situations is to break alpha things up into smaller chunks so that the center point is a more accurate representation of the render surface so the z ordering is more appropriate. I'm guessing you're batching objects based on those screen shots, probably for rendering speed, so that likely isn't an option for you...


Kittomer(Posted 2011) [#5]
Hmmm... I suppose I will have to split alpha blended faces into a different mesh then.
That will make things a bit more complicated.

It's probably not hard to get it to work, but it will double my drawcalls, essentially.

Either that or try to run with masked, there don't seem to be any z order problems when I use the mask flag instead of the alpha flag.

I hoped it was just a flag I forgot to set, or something, oh well.
Thanks everyone!


jtfrench(Posted 2011) [#6]
What workaround did you end up going with? I encountered this same problem and ended up just breaking down objects so that they were smaller. Had to eat the cost for breaking up batching.