Hi David,
From the specification (second Edition) P. 107, it
mentions that an IllegalSharingException is thrown
if Behavior node appear in a shared subgraph.
Do you see the following line
"Behavior: illegal node under SharedGroup Branch"
output from Java3D ?
Thanks.
- Kelvin
---------
Java 3D Team
Sun Microsystems Inc.
>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
>Date: Thu, 15 Mar 2001 20:54:13 -0500
>From: David <[EMAIL PROTECTED]>
>Subject: [JAVA3D] v1.2.1 (Bug)
>To: [EMAIL PROTECTED]
>
>I have determined that we are running into a bug. Took a real long time to
>islolate the condition. Here is a synopsis of the setup.
>
>Root BG
>|
>OrderedGroup - BG1 BG2 BG3
>|
>Sky - terrain - water - structures - mobiles - transients - alphas
>
>1. So there is a BG with children, one of which is an ordered group
>2. Siblings to the ordered group are BG's
>3. Each of these BG's are constructed from "PositionedBuilders"
>4. When our LOD system determines we need to build an object, it asks the
>PositionedBuilder to make it and place it at proper location with a Level of
>Detail.
>5. The builder asks the contractor for the sub-scene from its cache, if not
>found it calls the carpenter associated with the builder and asks for a LOD
>version of the sub-scene.
>6. The builder creates a transform group and puts the sub-scene BG into it,
>then assigns the rotation, scales and translations that the builder
>specifies.
>7. It then puts these into a BG and returns it to the LOD system
>8. The LOD system creates an update node for addBranchGroup() and adds it to
>a current transaction
>9. all the changes for that LOD cell are placed into the same transaction
>node
>10. the transaction node is then queued to the sceneupdator
>11. The sceneupdator behavior wakes up once per frame and processes the
>transactions and their updateNode.execute() methods, which make changes to
>the scene. (Transactions are to ensure that "batches" of associated updates
>built by other threads are performed in a single frame - critical to reduce
>popping and flicker of massive changes)
>12. This bug only happens when the carpenter returns a Link of a shared
>group, where the shared group has a TG and inside the TG there is a
>behavior that has a wakeup of elapsed frames(0).
>13. I replaced our real behavior which swirls the texture coordinates of a
>magic portal and pulses the material colors, with a do nothing behavior that
>just wakes up per frame... problem persisted.
>14. I then commented out the addition of the behavior to the TG and the
>problem goes away.
>15. I then made the carpenter stop returning a Link, but a BG instead....
>problem went away
>16. Conclusion : behaviors in shared groups break things... and this is new
>in this version.
>
>so BG->BG->TG->Link->SharedGroup->behavior does not work anymore
>
>Also, the damage is quite catestrophic, all sibling BG's added after that
>one also do not render.
>
>
>Dave Yazel
>Cosm Development Team
>http://www.cosm-game.com/
>
>
>----- Original Message -----
>From: Yazel, David J. <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Thursday, March 15, 2001 8:26 AM
>Subject: [JAVA3D] v1.2.1
>
>
>Has anyone had any issues with v1.2.1 relating to random branch groups not
>getting rendered? Our app is definitely acting differently under v1.2.1
>than under beta 2. This may be showing up a bug in our code and I have a
>lot more testing to do before I can figure out what is happening.
>Specifically I was wondering if there were any changes to behavior
>scheduling or changes made to the re-entrancy of Java3d objects being
>updated from threads. As a particular example I have a piece of geometry
>which has always been at a particular location, but which is no longer
>there. I can see where the geometry is getting constructed and then being
>added to a transaction. The transaction is queued and processed by a
>behavior. If there is a bug in our code it is somewhere in the transaction
>processing. Maybe something has changed in the timing that is causing a bug
>in our code to drop transaction nodes on the floor.
>
>Anyway, I will continue debugging.
>
>Dave Yazel
>
>===========================================================================
>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".
