>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
>Subject: [JAVA3D] Ordered Groups and Optimizations
>To: [EMAIL PROTECTED]
>
>Hi all:
>
>I am trying to get a handle on managing the sorting of transparent
>vegetation. My first stab at it used an ordered group, with each shape
>being in a seperate branch group. After the user moves a short distance I
>check to see if the nodes are out of order (based on distance from eye to
>center of sub-scene. If they are out of order I detach the BG parent of the
>ordered group (because the following detaches are very expensive if they are
>live), and detach all the nodes from the ordered group and then place the
>children back into the ordered group in the proper sorted order. This is
>extremely expensive when the sorted sub-graphs reach past 100 or so.
>
>1. Does the renderer still optimize at all, if the sub-graphs have the same
>material, appearance, etc? Say I have 100 sub-graphs which are branch
>groups with links to the exact same geometry. Technically the only thing
>different is the transform. Is the ordered group causing java3d to
>repeatedly send all the appearance info for each ordered group?
>
The Rendering structure tracks which attributes are current in the
rendering context, so the redundent updates should not happen.
>
>2. I would like to consider an alternate approach for a specific case. The
>case is that I have, say 4 batches of 100 sub-graphs. Each batch of 100 has
>exactly the same sub-graph, but with different transformations. Would it be
>more efficient to just sort the trsnaformations? In other words don't sort
>the groups each pass, just sort the transforms, swapping transforms as I
>sort?
>
I don't quite get the feel for what you are trying to do here, but if this
let's you do a fine sort on the sub-graphs, with an easier sort on the
batches, then yes this should be a win.
>3. One problem I have been having is with intersecting alpha blended shapes.
>Like a simple bush which has 2 or 3 intersecting planes with alpha blended
>textures. The problem is that ordering the entire bush with other such
>bushes is fine as far as its relation to each bush goes, but the ordering of
>the planes within a single bush can (and almost always do) cause them to
>step on each other. So sometimes you look at it from one angle and you see
>that the back to front pane must have been drawn before the left to right
>pane, causing you to see behind the bush on the left, missing the left hand
>part of one pane. I could make those 4 seperate planes, so there is no
>intersection and sort them.
>
Self-intersecting transparent objects are a big problem. Our current
proposal for adding depth sorted transparency in 1.3 only sorts down
to the Geometry object level. It still assumes that within a Geometry
object, there are no self-intersecting polygons.
> A. This is more sorting, would increase the objects being sorted 400
>percent.
Unfortunately, this is your only option in 1.2.
> B. Could I place all four planes in one shape node? Would I need to
>sort the geometries then?
This would work in 1.3, assuming you are using multiple Geometry objects
in one shape node.
> C. If I have to sort the geometry arrays then I can no longer use links
>and shared groups right?
>
1.3 should be able to handle this case. But in 1.2, you are correct, if you
need to sort a subgraph of a SharedGroup, then SharedGroup is out.
>Any suggestions would be helpful,
>
>I would love to hear how the Sun engineers would code this if they were
>doing it in Java3d.
>
Wait until 1.3. :^) I think you have explored the space pretty well, and
have seen the only way to do it in 1.2. If you look at the VolRend demo
that Doug G. wrote, I believe you will see him doing similar things.
This is a very hard problem. This is why many applications that use
multiple levels of transparency do so in a very constrained way.
Doug Twilleager
Sun Microsystems
===========================================================================
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".
