Hi, > >>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? >
It is completely behind only when view from the side. When view from the top for the vertical cylinder part both are essential the same distance from viewer. double is used as temporary variables to compute centroid of geometry QuadArray. >>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?? > No, since the backface and frontface will not order correctly. Unless you can dynamically contruct geometry with only front/back face based on the view position. > >>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? Suppose 2 triangles T1 follow by T2 is draw with alpha1 and alpha2 in blending mode respectively. Using BLEND_SRC_ALPHA and BLEND_ONE_MINUS_SRC_ALPHA the resulting color is R2*alpha2 + (R1*alpha1 + Rb*(1-alpha1))*(1-alpha2) --- (1) (where Rb is the background color) Drawing T2 first than T1 will have resulting color R1*alpha1 + (R2*alpha2 + Rb*(1-alpha2))*(1-alpha1) ---- (2) Since (1) != (2) in general, the resulting color is order dependent and depth sorting is important to get things render correctly. Now suppose we use blending mode BLEND_SRC_ALPHA and BLEND_ONE, the resulting color becomes R1*alpha1 + R2*alpha2 + Rb no matter which triangles draw first. So depth sorting is not required. However the resulting color is additive, if you got 10 triangles blending together this will quickly add up to 1. >>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. > There is no need to set DepthBufferFreezeTransparent to false if Java3D depth sort geometry correctly, since the geometry is draw from back to front order whether this bit is on or off will have no effect. With depth buffer turn off and back face is drawn you will get the banding effect. >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!) Please try to reduce the scenegraph to only use one layer of sphere instead of three. This can help you debug whether normal is pointing to correct direction or not. > >>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? > - Kelvin ---------------- Java 3D Team Sun Microsystems Inc. =========================================================================== 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".
