Overlapping of transparent objects

[C3R14L.K1L4]

Hello again,

I'm having some problems using transparency, shown on the following image. As you can see, the skybox is been drawn over the map, even if the sky is quite far. Also some of the map's walls are a little transparent (but not all). My code is configured to only use OpenGL.



Only two of them have the setTransparency(int) set to some value (currently 2) which I've not yet understood it's logic. Those objects are (in the picture) one of the skyboxes (the lowest one) and the map. The same objects have at least one of their textures loaded with alpha information (giving the flag true to the Texture constructor). Finally, I'm not using any kind of sorting information (and collision detection) like octrees and portals (the last one I don't even know how to use).

I've read of Config.glTransparencyMul and glTransparencyOffset but don't know how to apply them here. So, I really need some help here... Is it caused by missing sorting information?

PS: Im my opinion, there's missing some documentation on how to use transparency, portals and more. One solution could be adding a 'User tutorials' section on the forum.

[C3R14L.K1L4]

Humm, setting

Code Select Expand

Config.glTransparencyMul = 2.56f;
Config.glTransparencyOffset = 2.9f;


(the values were 'random' generated ) resulted on reduction of the transparent walls, but the sky problem remains:

[EgonOlsen]

That's caused by the painter's algorithm (used for sorting transparent polygons) producing sorting errors for large polygons. Why is the sky using transparency at all? Anyway, because the skybox is always behind everything else, you can apply a sort offset by using http://www.jpct.net/doc/com/threed/jpct/Object3D.html#setSortOffset(float). Try some large, positive values. That should help.

EDIT: About portals...well, i don't really recommend using them. An Octree is the better solution in most cases. In fact, nobody has used portals for years. I'm not sure if they still work as expected under all circumstances.

[C3R14L.K1L4]

Thanks, I suspected it was probably caused by missing sorting information, but I didn't know how to "give" it. I thought the jPCT api used this information while retrieving it from the octrees/portals (ie, no only using it for colision detection but also for drawing things in order). Adding the z-sort offset to the skybox's corrected the problem. Excellent.

I'm using two skyboxes, so having two layers of moving clouds is quite cool, that's why the lower one is transparent .

[EgonOlsen]

I thought the jPCT api used this information while retrieving it from the octrees/portals (ie, no only using it for colision detection but also for drawing things in order).

It does, but z-sorting based on polygons can never be correct in all cases, especially if large ones mix with smaller ones. What's the purpose of that application btw? The level reminds me of "killhouse" from Call Of Duty 4... 

[C3R14L.K1L4]

It's a artificial agent simulator I'm writing for my MSc. It's purpose is to have agents (bots) doing actions (intentions) according to what they want to be done in the environment (desires). I'm using your API because I needed a simple rendering engine allowing me to focus more on my research.
The map is 'Bzz-Drunk' from Wolfenstein: ET, a game I've played for years and quite probably, never stop playing It's a small symmetrical map best suited for two opposing teams, which it's what I need.

I'm having another problem now (damm), not related to transparency but still possibly to rendering order. Now, according to the camera's position, some triangles of the map disappear... (the map has transparency enabled, if I disable it the triangles appear OK). I've added octrees to all complex object3d but the problem remains.



seems that this problem is the same as here:

http://www.jpct.net/forum2/index.php/topic,1281.0.html

Egon, I wonder why you say the painters algorithm doesn't guarantee a sorting order, has it depends on where it get's it's sorting (deepness/z) information. For instance, if there's an octree for the object, why does it fail?

[EgonOlsen]

This has nothing to do with octrees, it's just a problem of painter's algorithm. If two or more transparent polygons get sorted, the sorting may be inaccurate. There is no real solution to this, except for

a) modifying the geometry so that it can't happen
b) don't use so much transparency
c) apply a sort offset

c) is only possible for things that are always behind (like the skybox) or always in front.

The problem with painter is this: You sort by the average depth of a polygon (or by the depth of one of its corners...it doesn't matter, the problem is the same). Have a look at this skillfully drawn picture



Assume that the average z-value of those lines is calculated by adding the z-values of their ends and dividing by 2. The camera is located to the left in this example.
Fig 1 will be sorted correctly. Fig 2 will most likely be sorted correctly but Fig 3 for sure won't. The short line has a lower average z-value then the long line has. So it will be sorted in front where it should actually be sorted behind the long line.

As said, this is a problem of the algorithm....why is your whole map transparent?

[C3R14L.K1L4]

The whole map was set to transparent for this:



Humm, so the problem is that the z is the average depth value of the polygon / triangle 'corners'...
then... how doesn't this happen on quake's bsp for instance? The sorting info is retrieved from the bsp, right?

Ok, in my case the best is to load those transparent objects separately and setting the whole map as opaque (not transparent).

Thanks again m8, for your patience 

[EgonOlsen]

Humm, so the problem is that the z is the average depth value of the polygon / triangle 'corners'...
then... how doesn't this happen on quake's bsp for instance? The sorting info is retrieved from the bsp, right?

Most likely yes. But i've never seen a fully transparent quake level anyway. However, just split the level into transparent and opaque parts and you should be fine. It's much better for performance anyway.

[C3R14L.K1L4]

In the api, the sorting algorithm is applied on the object's polygons or on a per-pixel basis (like OpenGL does when using the depth-test)?

[EgonOlsen]

In the api, it's per polygon (when you are using the OpenGL renderer, with the software renderer, it's a different story). The OGL-renderer itself uses the usual depth test per pixel of course.