Thanks for your comments. Not being a 3D graphics expert makes me unsure as to what's hard and what's easy and whether or not its my Java 3D inexperience that's the cause of my problems or not. I am surprised that this is rated as a hard problem, but, again, that's my lack of 3D experience.
At this point, I am trying to think of another way to do the whole thing. Maybe find a way to split the object up into 4 quadrants: 1) Back half of sphere, 2) back half of funnel, 3) front half of sphere, 4) front half of funnel. Then, as the view platform changes position, what rectangles are assigned to the back or front half spheres and funnels is changed. But this means dynamically changing the coordinates and normals in the quadArrays at each frame refresh. Would this be very slow? Maybe I need to split it into more than 4 parts.... Thanks for letting me know that the OrderedGroup isn't doing anything for me here. Bob Gray -----Original Message----- From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED]]On Behalf Of David Yazel Sent: Friday, January 04, 2002 10:15 PM To: [EMAIL PROTECTED] Subject: Re: [JAVA3D] Transparency Bug Report???? Ok.... 2 quick notes: 1. The ordered group will completely mess up what you are trying to do. The reason is that while the three objects seem like they should be rendered in-to-out, that is not really true. Take a point of the inner shell that is farthest from the viewer... it is still in front of the back side of the middle shell. You need to let java3d have full power to sort every triangle independant of which shell they are in. 2. As a general note. Not every problem in 3d can be solved in a general way. You could not have really come up with a more difficult transparency rendering problem. The only way to really solve this efficiently is to design a custome solution where you comepltely control the rendering process. You could, for example, using a geometry updator on a single geometry array, sort the triangles every frame and have perfect results. This would require writing a higher level triangle node type that let you specific the vertex color or anything else you would want to differentiate between the triangles as they were rendered. Then using code to place all the triangles into a special geometry updator designed to take collections of your special nodes and keep them sorted. Then in a behavior sort your collection, then iterate through it and set the geometry properly. 3. The depth buffer freeze transparent has nothing to do with the ordered group. It has to do with whether java3d will allow the zbuffer to be modifed when it writes the alpha blended pixels. So if there was a condition by which two triangles were sorted so that two vertices of different colors generated the same depth value for the same pixel, and this was option was enabled, then the second pixel would not get written or blended at all. Dave Yazel ----- Original Message ----- From: RWGRAY <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 04, 2002 9:41 PM Subject: Re: [JAVA3D] Transparency Bug Report???? Hi Kevin, First, thank you, thank you for responding. I really appreciate the fact that you looked at the transparency problem I am having. In order to interest others a little bit, I see 3 geometric objects, one inside the other, as being used for showing transparent body: skin, bones, heart or lungs. I'd like to see the heart beating behind the rib cage, so I'd like skin, bones to be partially transparent. Or, three objects could be part of a nuclear reactor core in some game, etc. So 3 objects, one inside the other, with the ability to see all three objects, I think, would be cool, if I can figure out the correct way to code it. Now, on to your comments. >Seems to me the color of three toruses are >green, blue, red from inside to outside. Correct. >As you may know, the way Java3D doing depth sort is to >compute the centroid of each GeometryArray and use the >distance from the viewpoint. O.K., I "know" that. Which is why I coded 1 rectangle per quadArray. Then Java 3D should sort each rectangle correctly with respect to all the other retangles. This didn't seem to be the case in a couple of the images in which I can see green (inner most object) but no blue or red (middle and outer most object). >In the torus like >shape there is a vertical part which connect the top and >bottom. When view from the top, the >distance from for all three (green/blue/red) of this >vertical parts after you subdivide the torus are about the >same to the viewer so the sorting order is not correct >and green circle is seen. This is expected. But since the green is completely within/behind the blue which is completely in/behind the red, shouldn't the green (rectangles) always be further from the viewer? Or are you saying that the distances to viewer are so close to being the same that Java 3D can not calculate it accurately enough to know the correct distance/order? Which then brings up the question, how accurate is the calculation and is this a problem or not? Is it like, +-0.001 or more like +-0.0000000001 in some distance units? >Breaking the geometry into 3,168 quadarrays >and depth sort this one EVERY frame is going to be >very slow if not memory expensive. For 30 of these >object you are taking about sorting ~100K >geometry EVERY frame. Yes, I know. Which is why I keep asking this list "how to" code such objects efficiently? Or what is a better approach? >Using only one GeometryArray for a Shape3D under SharedGroup >should have better memory usage. However it will not solve >the transparency problem that you want. In general >this is a hard problem without hardware support for >depth sort per pixel or using stencil buffer >(which Java3D do not support) technique. You >can also try to simulate the effect if hardware >support 3D texture as in Volume visualization. This is actually the way I am currently thinking of doing it: with a SharedGroup. But you say its not really the way to go? What if I have, as I do, an OrderedGroup, and attach 3 BranchGroups with each BracnhGroup having a link to the same shape? Would that depth sort the 3 Shape3D's (geomertyArrays) correctly?? >One thing you can try to do is instead of using >BLEND_SRC_ALPHA for source blend function >BLEND_ONE_MINUS_SRC_ALPHA for destination >blend function, use BLEND_SRC_ALPHA for source >blend function and BLEND_ONE for destination >blend function instead. In this way there is no need to >subdivide the torus and doing depth sorting since the effect >after rendering is order independent. The drawback of this >approach is that the effect is additive. >i.e. the color of second layer will multiple by alpha1 >and add to inner layer. The final color is the >color of third layer multiple by alpha2 and add to >the previous result. So you can only achieve the effect >from dim to bright from inner to outer layer. I only sort of understand this. I'll try to do more reading to understand what you are saying. Do you have an on-line reference for applying this technique? >The weired banding effect that you get when >(1) Turn off depth sort transparency >(2) Disable setDepthBufferFreezeTransparent > (which is true by default) >(3) Set PolygonAttributes.CULL_NONE > >is expected. Hold on.... I need to learn something here. Where in my code did I do all that? I have: SU.getViewer().getView().setTransparencySortingPolicy(View.TRANSPARENCY_SORT _GEOMETRY); which I thought turned on depth sort transparency. Do you mean that the OrderedGroup makes this irrelevant? I have: SU.getViewer().getView().setDepthBufferFreezeTransparent(false); because I thought I did not want the depth to be frozen, but instead, to be sorted according to OrderedGroup (or by the individual rectangle (quadArray) in the previous case of 1 rectangle per quadArray)? In any event, I thought this enabled depth sorting, otherwise its frozen to some value. I think I am confused once again. I have: PolygonAttributes.CULL_NONE but I just tried PolygonAttributes.CULL_BACK and your right, it got rid of the "banding" aspect, *but* I still have the left side of the image/object much brighter than the right side of the image and now other aspects are messed up. Like the bottom half of the image/object is cut away as if some cull plane is passing through the bottom half only and the front is all cut away. Weird! And not what I need. (I thought the normals might all be wrong for the bottom half, so I reversed the direction of the normals... This resulted in the bottom half being black!) >Since the backface from the far side of >the sphere may drawn in front of the frontface as >Z buffer turn off. The color of backface drawn >is darker than the color of frontface. It is perfectly >legal for the graphics card to tesselate the QuadArray >and drawn in whatever order it prefer when the geometry >array is pass down to the native library. I just tried: SU.getViewer().getView().setDepthBufferFreezeTransparent(true); with PolygonAttributes.CULL_BACK and I still get very bad results, as described above. >Hope this helps to explain the transparency issues. Does it help... YES! Are all issues resolved... no. I still get left side bright, right side dim or missing and bottom half front culled away or something even though the quad points are defined in the same quadArray. I have posted new pictures of this problem, with the code I am using, on my web site at: http://www.rwgrayprojects.com/Java3D/Transparency/trans02.html If possible, please have a look and any other comments or suggestions would be greatly appreciated. Has any one else done this kind of thing and got it all to work? If so, could you share some of the code? Thanks again. Bob Gray =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
