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