Transparency problems

Engines, Libraries and Tools Xith3D Forums
#1

I’m on the track of Xith’s Transparency problems demonstrated in Bleeding_Blending test. It has to do with the depth test. I’ve searched the internet for this problem and many sites say, that when rendering the transparent shapes, the depth test needs to be turned off. This is not totally true, but I think, I can solve our problems with this information. Maybe there’ll be the need to render in multi pass mode to solve it for some cases.

Well, anyway. I’ll post here, when I’ve more info.

Does this bring anyone to an idea?

Marvin

#2

Heh ? I don’t really understand here…

If you turn off depth test and render a transparent sphere behind an opaque plane after the plane has been rendered, you’ll see the transparent sphere yet it should be hidden.
If you render a transparent sphere first (with depth test off) and then an opaque plane (“behind” the sphere, from the user point of view, with depth test on) it will hide the sphere…

I think I miss something here… or is everything being played on the rendering order ?

Note : probably appearing as a very silly noob in this post but during the few years I spent on this forum I learned many things in this way. Thanks in advance for all knowledge share.

#3

Well, no. You don’t sound like a silly noob. It simply is a thing we both need to fully understand next to other things we already understand ;).

I said, I’m on the track of it. I didn’t say I fully solved it. When I googled for the issue, all pages talking about this topic, told to first render the opaque primitives with depth test on and then render the transparent primitives with depth test off and in back-to-front order.

So, yes, it depends on the rendering order, but you’re right when you say a transparent shape rendered with depth test off after an opaque shape positioned in front of the transparent one, will be visible in front of it. So I cannot say, how the solution will look like, but I guess it will have to be done with the help of multipass rendering.

Marvin

#4

Huh ? okay glad I do not yet have nightmares about that.

In the ColorCube example, you clearly see the rendering order is changed while the cube structure (composed of small transparent spheres) is rotating… I guess it can’t be avoided really…

#5

Little correction here. You probably meant that “Depth Writing” have to be off when drawing transparencies, but not the depth test itself! So, that when drawing transparencies (and when they are sorted already from back to front) - they will still be depth tested against the values in depth buffer (filled in when the opaque shapes where rendered) but transparencies will not modify the depth buffer (this is what you want to achieve setting depth buffer writing off) - then this will work fine!!!
In general, you set Depth test off only in very special cases really.

#6

P.S. What about particular case of Bleeding_Blending, please see my posts:
http://www.java-gaming.org/forums/index.php?topic=15018.msg119335#msg119335
and
http://www.java-gaming.org/forums/index.php?topic=15018.msg119339#msg119339

This is definitely at least one of the problems. As you can see, wrong BackToFront sorting + depth writing = that problems we see in Bleeding_Blending test. BTW, depth writing actually not necessary need to be switched off really if you have proper BackToFront sorting (but would be probably prefered and standard way to do).

#7

It could by using OrderedGroup, if they were ever working ;).

Ah! Great hint. Thanks ;D. I’ll check that.

#8

Well, you can’t have a generally “correct” sorting criterion. Consider this case:


xxxxxxxxx
        x
aaaaaa  x
        x
xxxxxxxxx

Where the x-es describe one shape and the a-s another one. These ones can’t be universally sorted. So I guess bounding sphere centers as the criterion and depth buffer writing fix are the best achivable way.

Marvin

#9

And then what you’re waiting for some more magic hardwork to make it work in 2 sec ? ;D (more time ? who wants more time ? 8) )

#10

Yes, totaly agree with you!!! Bleeding_Blending will start looking much better if you set depth writing off - already. And if you have 0.5 transparency, for two planes - you will see no difference even if wrong sorted - yes, this is pretty good already.
There is no universal sorting really (which is fast enough), agree, but still consider that mostly transparent objects are “flat planes”, and to have sorting based on bouncing spheres (well, even not that - on their centers only!) is to rough… i think. Why not to get use of BouncingBox - it is not used in some reason in xith, everything is done with bouncing spheres. But when calculating bounds and if for flat shapes you use bouncing box rather then spehere the you can check if two atoms bounds are bouncing boxes - you can do very fast and much more precise sorting that with the spheres centers.
You don’t have much of transparent objects in the scene, just few really, so even if sorting will be little slower that current implementation - it will not affect anything really.

Bohdan.

#11

It is BoundingBox, not BouncingBox ;D

Yes, I know, there’re really few transparent shapes. And activating BoundingBox for flat shapes could be a good way. But we must be carefull not to activate it for all shapes. Are you maybe interested in doing that?

#12

;D ;D, yes, you are right ;D, sorry…

Yes, of course, bounding boxes will be only where appropriate.

Well, actually why not, i thing i know exactly what and where to correct, so I can do that. The only thing is at the moment I’m really busy with my work (at least till tuesday), so I will do that slowly, if that’s ok? I think I probably can do even little bit different way, not touching bounding boxes even… just one extra flag to be set in Shape3D… well, I need to think a little first (and I will let know which way I planning to do that), but anyways - this is relatively easy to do one way or another… So, can I assume that this task is assigned to me?

Bohdan.

#13

Good example of the delegation pattern applied in team coding
;D

#14

please do ;D contributions will always be welcome… as long as they do not introduce more bugs than features…

#15

;D

Ok, so I’ll post here when I ready.

#16

Thanks.

#17

Glad to contribute ;D

#18

Sorry guys, I was late with the deadline on my work, so have to disappear for a while, but now I’m back and going to do that thing.

I see Yuri is back! Glad to see you again, Yuri! :slight_smile:

BTW, Yuri, any objection or advices on adding another comparator speccially for sorting transparencies as discussed here above?
It is not going to be ideal, but should serve much better then current back_to_front comparator does, at least in most of the cases.
Will try to tuch as less as possible behind the sorting itself, but I may need some information to be specified for Shape3D to speed the things up (some flags etc…, maybe vector…) Well I just get back to that thing so I should have some good enough implementation ready in 1-2 days.

Basicaly, it will not break anything at all, for sure, just that the user will be able to choose one more sorting method for transparencies besides those existent.

Bohdan.

#19

Cool ;D.

For the additional Shape3D flags: Just ask :).

Marvin

#20

Hi,

I definitely have no objections on new comparator.

I was digging into mutually intersecing shapes transparency problems time ago, and can tell you few things:

  1. It is theoretically not possible to render mutually intersecting or self-intersecting shapes with standard OpenGL rendering modes.
  2. The best one can do is to depth-sort geometry triangle-by-triangle, but it is too slow and even this does not guarantee correct result if some of triangles mutually intersect - you should cut trianges to smaller before sorting.
  3. There are some combinations of alpha test, depth test and additive alpha blending that produce more or less good result, but in some angles they still do not work.
  4. Most interesting. There are CORRECT TRANSPARENCY rendering techniques that can be implemented with modern cards and fragment shaders. At least one technique is called “Depth Peeling” which gives 100% correct result, but it is multipass (number of passes depend on the correctness required and degree of shape self-intersection).

OK, I will disclose one link that might be intersting for you: take a look at http://www.jproof.at/3d/. All examples there use Xith3D for the rendering. You should note that these examples are relatively old, and require JDK 1.4.2 (I think it will be installed on demand), so even don’t ask me to update them.

If you can run them (and I believe it is possible - some people from this forum confirmed they are running OK), check the House example, and take a closer look to the trees: they use 2-pass rendering with alpha test and render-to-depth-buffer, if I remember correctly. Also try to take out the house levels and you will see the transparency behavior when the level disappearing.

Yuri

P.S. Let me know by posting here if everything runs OK