Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Transparency problems  (Read 4057 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Posted 2006-10-14 01:30:50 »

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
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #1 - Posted 2006-10-14 14:53:56 »

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #2 - Posted 2006-10-14 15:01:49 »

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.

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 Wink.

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #3 - Posted 2006-10-14 15:13:25 »

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..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline bohdan

Junior Devvie




Java-positive...


« Reply #4 - Posted 2006-10-14 15:23:25 »

I'm on the track of Xith's Transparency problems demonstrated in Bleeding_Blending test. It has to do with the depth test.
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.
Offline bohdan

Junior Devvie




Java-positive...


« Reply #5 - Posted 2006-10-14 15:36:22 »

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).
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #6 - Posted 2006-10-14 15:37:55 »

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..

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

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.

Ah! Great hint. Thanks Grin. I'll check that.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #7 - Posted 2006-10-14 15:45:13 »

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).

Well, you can't have a generally "correct" sorting criterion. Consider this case:

1  
2  
3  
4  
5  
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
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #8 - Posted 2006-10-14 15:48:33 »

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..

It could by using OrderedGroup, if they were ever working Wink.
And then what you're waiting for some more magic hardwork to make it work in 2 sec ?  Grin (more time ? who wants more time ?   Cool )

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline bohdan

Junior Devvie




Java-positive...


« Reply #9 - Posted 2006-10-14 16:00:00 »



Well, you can't have a generally "correct" sorting criterion. Consider this case:

1  
2  
3  
4  
5  
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
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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #10 - Posted 2006-10-14 16:06:07 »

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.

It is BoundingBox, not BouncingBox Grin

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?
Offline bohdan

Junior Devvie




Java-positive...


« Reply #11 - Posted 2006-10-14 16:24:05 »

It is BoundingBox, not BouncingBox Grin
Grin Grin, yes, you are right  Grin, sorry...
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.
Yes, of course, bounding boxes will be only where appropriate.
Are you maybe interested in doing that?
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.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #12 - Posted 2006-10-14 16:24:46 »

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?
Good example of the delegation pattern applied in team coding
 Grin

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #13 - Posted 2006-10-14 16:27:35 »

So, can I assume that this task is assigned to me?
please do  Grin contributions will always be welcome.. as long as they do not introduce more bugs than features..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline bohdan

Junior Devvie




Java-positive...


« Reply #14 - Posted 2006-10-14 16:35:48 »

Good example of the delegation pattern applied in team coding
 Grin
Grin

So, can I assume that this task is assigned to me?
please do  Grin contributions will always be welcome.. as long as they do not introduce more bugs than features..

Ok, so I'll post here when I ready.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #15 - Posted 2006-10-14 16:48:32 »

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

Thanks.
Offline bohdan

Junior Devvie




Java-positive...


« Reply #16 - Posted 2006-10-14 16:53:54 »


Glad to contribute  Grin
Offline bohdan

Junior Devvie




Java-positive...


« Reply #17 - Posted 2006-10-23 16:53:30 »

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! Smiley

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.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #18 - Posted 2006-10-23 17:08: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! Smiley

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.

Cool Grin.

For the additional Shape3D flags: Just ask Smiley.

Marvin
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #19 - Posted 2006-10-23 17:19:27 »

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

Yuri Vl. Gushchin
JProof Group
Offline bohdan

Junior Devvie




Java-positive...


« Reply #20 - Posted 2006-10-23 18:32:33 »

For the additional Shape3D flags: Just ask Smiley.
Thanks Marvin! Smiley

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.
Alright... understand, that one I going to do going to assume transparent objects to be flat, which is mostly the case... and it should give much better results in general, especcialy if there is no intersection, though not always will be 100% correct...

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).
Alright.. yep, sounds very interesting!, haven't heard of something like that exists.... Great to know!

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.
Thanks a lot for link and information! It was great to see, very nice done! Wokred fine, no problems. And transparencies handled surprisingly really nice there! It was good material to see how things can be possibly done!
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #21 - Posted 2006-10-23 18:40:16 »

Hi,

Quote
And transparencies handled surprisingly really nice there!

You can believe me - was a hell of work, and significant part of my contributions to Xith3D came that time when we at JProof made these apps.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline bohdan

Junior Devvie




Java-positive...


« Reply #22 - Posted 2006-10-24 13:51:00 »

You can believe me - was a hell of work, and significant part of my contributions to Xith3D came that time when we at JProof made these apps.

Yes, I believe it was Smiley, results are amasing...

Question to everybody... Can anybody ran Bleeding_Blending_test please? Same old version as it was before...
I get latest xith from CVS and experiencing odd behaviour of transparencies.... Have difficulties to explain really  Undecided, just need to get it working "normally" to test new sorting... please look at it and advice... something like color buffer is not cleared every frame + improper culling I guess as well, since top shape is freezing on revers go (like it is drawn once and that's it)... anyhow very strange to me...

Bohdan.

Edit: and when I set shapes to be opaque - no animation is happenning at all  Huh Like transform is not updated or something...
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #23 - Posted 2006-10-24 22:48:55 »

Question to everybody... Can anybody ran Bleeding_Blending_test please? Same old version as it was before...
I get latest xith from CVS and experiencing odd behaviour of transparencies.... Have difficulties to explain really  Undecided, just need to get it working "normally" to test new sorting... please look at it and advice... something like color buffer is not cleared every frame + improper culling I guess as well, since top shape is freezing on revers go (like it is drawn once and that's it)... anyhow very strange to me...

Edit: and when I set shapes to be opaque - no animation is happenning at all  Huh Like transform is not updated or something...

Sorry, was my fault. Was easy to fix at last. Just setting the initial TransformGroupId to 1 instead of 0 Smiley.

I also changed the test class to make it able to be run with LWJGL, which was not possible because of the Swing thing. I hope you're not annoyed because of that.

Marvin
Offline bohdan

Junior Devvie




Java-positive...


« Reply #24 - Posted 2006-10-24 22:55:24 »

Sorry, was my fault. Was easy to fix at last. Just setting the initial TransformGroupId to 1 instead of 0 Smiley.

I also changed the test class to make it able to be run with LWJGL, which was not possible because of the Swing thing. I hope you're not annoyed because of that.

Marvin

Thanks Marvin!  Smiley
No problems  Grin, going to check it out in a little while...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (29 views)
2014-11-22 12:13:56

xFryIx (71 views)
2014-11-13 12:34:49

digdugdiggy (50 views)
2014-11-12 21:11:50

digdugdiggy (44 views)
2014-11-12 21:10:15

digdugdiggy (38 views)
2014-11-12 21:09:33

kovacsa (62 views)
2014-11-07 19:57:14

TehJavaDev (67 views)
2014-11-03 22:04:50

BurntPizza (65 views)
2014-11-03 18:54:52

moogie (80 views)
2014-11-03 06:22:04

CopyableCougar4 (80 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!