WELL!!! Looks like I am WRONG!
Although its too bad... behaviors in shared groups rocked!
Hmm, I am never seeing the exception.. I must be losing the exception
somewhere.... does that happen when you put it the shared group, when you
make the Link or when you insert the shared group into the scene?
Dave "Jump the Gun" Yazel
----- Original Message -----
From: Kelvin Chung <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 15, 2001 9:17 PM
Subject: Re: [JAVA3D] v1.2.1 (Bug)
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".
