True transparency

OpenGL OpenGL: Basic Coding
41

I’ll try and let you know.

Thank so much again.

Alberto

42

No Ilian,

Unfortunately 1/0.9999232 is always very close to 1.

We are missing something here…

Do you know any other resources on the internet on Ordering Trees?

Thanks,

Alberto

43

No, it was really hard to find those links, even when I know the stuff and keywords.
In practice, I’ve done the Z computation+quantization in my own projects in camera-space, not clipspace. So, get the modelview matrix, multiply the triangle-center point with it, and use the resulting Z. (instead of using gluProject).
Still, a quick fix for your current code could be:


float z1; // = 0.9999232 , this is what you already have

int z2 = (1.0f-z1)*10000; // notice your z-far has a say in this
if(z2<0)z=0; else if(z2>=OT_SIZE)z2=OT_SIZE-1;

tri->pNext = ot[z2];
ot[z2]=tri;
44

Hi Ilian,

Thank you again for your help.

In practice, I’ve done the Z computation+quantization in my own projects in camera-space, not clipspace. So, get the modelview matrix, multiply the triangle-center point with it, and use the resulting Z. (instead of using gluProject).

I love this: does it mean that using camera-space the z values are well distribuited between znear/zfar?

I’ll try immediately!

Thanks so much again Ilian,

Alberto

45

Hi Ilian,

After working all the morning and getting OT working I got this disappointing result:

The problem is that some long and skinny triangles sorted by their averaged Z depth are sorted wrong no matter how long the OT is:

In some favorable orientations the result is GREAT:

PLEASE, tell me that there is a workaround to this issue. What about getting the closer Z depth of each triangle?

Thanks,

Alberto

46

Hm, similar artifacts are to be expected, but I haven’t seen so bad cases :frowning:

Try Z_for_sorting = Zmin + (Zaverage/100);

47

No luck, do you think that I am doing something wrong or that this is an OT limitation? In my opinion it fails even on a cube model.

The result with the last formula you provided:

Thanks again,

Alberto

48

Of course any per-triangle sort will have problems, for perfect solutions I am only aware of bsp trees and zbuffer.

Some things to try :

  • disable depth write
  • enable backface culling
    If you actually need the backfaces, do it in two separate passes : cull frontfaces first, then backfaces (with or without depth write/test)

The screenshot of your ‘target’ in first pages does not have backfaces.

49

Hi ZbuffeR,

Thanks for joining again the discussion.

Some things to try :

  • disable depth write

Do you mean glDisable(GL_DEPTH_TEST)?

Just tried, even combined with dual pass:

gl.Enable(gl.CULL_FACE);
gl.FrontFace(gl.CCW);
DrawOT();
gl.FrontFace(gl.CW);
DrawOT();
gl.FrontFace(gl.CCW);

By the way, I have been reading from years “sorting triangles from farther to closer” but this fails in the most trivial case below. The quad behind from the view direction is closer than the other: this invalidates all the sorting algorithms.

The screenshot of your ‘target’ in first pages does not have backfaces.
You are right, I didn’t noticed this. They probably have face normal all outward that we don’t. Here is the resutl we are trying to achieve:

We feel to be very close to the solution but unfortuantely cannot guess what are we missing.

Any idea would be greatly appreciated.

Thanks,

Alberto

50

Just an idea: modelers can easily display dynamically-subdivided surfaces, and can handle complex concave poly, maybe they are subdividing flat transparent polygons before sorting?

51

Ilian,

Do you mean sorting faces instead of triangles?

Thanks,

Alberto

52

I mean: you already split faces (polygons) into triangles, maybe further splitting the triangles with long edges into smaller triangles is the next step.
A glintercept to see how other modelers do it may be necessary.

53

Mmm, we could subdivide skinny triangles if the face color has an alpha value different from 255…

Can we therefore say in summary that the famous sentence “sorting all the polygons from farther to nearer” is void if triangle sizes are not homogeneous?

Thanks to you all, it was a pleasure to discuss with you about this foundamental 3D graphics concept :).

Alberto

54

Look here: even this simple test fail, we are using the following with outwarding normals:

glEnable(gl.CULL_FACE);
glFrontFace(gl.CW);
DrawOT();
glFrontFace(gl.CCW);
DrawOT();

Are we doing something wrong or are these OrderingTable limitations? (none of the boxes touch the other)

Thanks,

Alberto

55

Could you upload those two meshes as .obj/.mtl , so I can try toying with them?

I inspected how a modeler draws some simple meshes, it was simply doing a qsort() , no subdivision, nothing fancy.

Ah, here’s a test:

56

Hi Ilian,

Here they are:

http://www.devdept.com/random_bars.zip
http://www.devdept.com/extrusion.zip

What is the difference between Modeler and Layout in your image?

Thanks,

Alberto

57

Exactly the same object. In Modeler, no lights are/can_be specified; in Layout, there’s one directional light - that’s why the darker shading.

The Modeler version looks perfect, but look at this:

58

Rhino3D does the job, perfect in any orientation… How?

I don’t believe they are splitting OBJ triangles…

What modeler are you using?

Thanks,

Alberto

59

What about treating planar faces as a single entity? Placing all the triangles in the same OT row ? Could this improve the result?

Only non planar faces need a different treatment, what do you think?

Thanks,

Alberto

60

The easiest way (that I know of) to sort the polygons perfectly is by using a BSP tree. There’s no way to avoid artifacts when sorting polygons on a z-value.
You only have to regenerate the BSP tree when the polygons change and you can use the bounding box of the changed polys to update only part of the tree. The sorting is very simple and fast.
Still IMO depth peeling is the way to do it.