As Mark indicated, blended transparency is inherently order dependent.
Note that for intersecting objects, it isn't sufficient to order the
shape nodes. To correctly render from back to front, the objects must
be broken up into individual, non-intersecting triangles.
In Java 3D 1.2, we have proposed alternative blending functions that
can be used to effect order-independent transparency, but this mode has
its own artifacts: namely, there is an additive effect where two
partially transparent surfaces overlap.
- Kevin
>Date: Tue, 24 Aug 1999 13:59:15 -0700
>From: Mark Hood <[EMAIL PROTECTED]>
>Subject: Re: [JAVA3D] Major Problem
>To: [EMAIL PROTECTED]
>
>> Date: Tue, 24 Aug 1999 14:20:56 -0400
>> From: Bob Gray <[EMAIL PROTECTED]>
>>
>> I have tried transparency modes of NICEST, BLENDED and FASTEST. None of
>> these work for me. They do not allow the 2nd polyhedron to show through and
>> leave big blck areas where the 2nd polyhedron surface should be.
>>
>> Can anyone tell me why?
>
>I haven't taken a close look at your code, but I believe you're running
>into a limitation of Java 3D here.
>
>In the general case, traditional Z-buffering techniques don't work for
>transparent objects. In order for the colors to be blended properly their
>facets must be rendered in a view-dependent order, from back to front. This
>isn't a trivial task for most applications, and Java 3D doesn't provide any
>help here. You'll only get reasonable results if most of your objects are
>opaque and you have only a few, non-overlapping transparent surfaces.
>
>There are techniques that work for many cases. All opaque objects can first
>be rendered using the normal Z-buffer technique. Transparent facets can
>then be sorted from back to front in the view projection space using some
>metric; for most objects using the centroid (averaged vertices) works OK. A
>reasonable effect can then be achieved if the Z buffer values from the
>opaque objects are frozen and the transparent facets rendered in their
>sorted order on top of them.
>
>This is not directly supported by Java 3D; perhaps some other users have
>tackled this problem and could help you out. Your only other alternative is
>to use SCREEN_DOOR, which doesn't have any view dependencies, but has other
>lousy rendering characteristics, as you point out.
>
>-- Mark Hood
>
>===========================================================================
>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".
