I can believe this, although your scene graph must be very big. Here are some reasons why this is the case. These are not completely specific, but the general numbers are what is important. In the first case, we are setting an attribute on a Shape3D node. One thing to note is that Shape3D nodes may not be shared in the scene graph. So when we create and send the message, it can be targetted fairly quickly. This operation also involves just a single message.
In the second case we are setting attributes on NodeComponent objects that may be shared among many Shape3D objects. So, the processing needed to target those messages is a bit more complex. And, that processing will generate three messages instead of just one. This is an artifact of the current implementation architecture of Java 3D. In order to facilitate a lot of parallelism and using optimized ancillary structures, we pay the price when lots of changes are happening to the scene graph all at once. This architecture does work very well when there are a relatively small number of changes to the scene graph on an ongoing basis. That is why I asked whether or not the frame rate was slowing down. If you were doing a few of the changes like the ones below on an ongoing basis, you would probably see that the second method was faster than the first from a frame rate perspective. I hope this helps explain it. Doug. and sending one message into the system. For the second case we are creating and sending three messages into the system. >Delivered-To: [EMAIL PROTECTED] >MIME-Version: 1.0 >Subject: Re: [JAVA3D] Performance of Appearance Changes >To: [EMAIL PROTECTED] > >(copied to the J3D list for interested readers) > >Doug, > >We are talking about the actual execution of the code. The operation that >results in that code being executed is done as a single user operation (not >interactively), so there is no frame rate involved. > >Also, we actually stop the Java 3D renderer when the operation is being >performed, since there is no need to update the view until after the >operation is complete. My understanding is that once the renderer is >stopped, the scene graph should resolve appearance changes with little (if >any) synchronization overhead, until the renderer is restarted. > >I will give you example running times for one of our scene graphs. > >- Building and setting the Appearance objects from scratch for every Shape3D >node (option #1) takes a few seconds. > >- Setting individual appearance attributes for every Shape3D node using >existing Appearance objects (option #2) takes about 30 seconds. > >Thanks for your help; let me know if you need additional clarification. > >- Mauricio > >-----Original Message----- >From: Doug Twilleager [mailto:[EMAIL PROTECTED]] >Sent: Monday, February 04, 2002 5:29 PM >To: [EMAIL PROTECTED] >Subject: Re: [JAVA3D] Performance of Appearance Changes > > >What do you mean by faster? Is the frame rate faster? Or, does faster >mean the actual execution of the code below? > >Doug Twilleager >Java 3D Team >Sun Microsystems > >>Delivered-To: [EMAIL PROTECTED] >>MIME-Version: 1.0 >>Subject: [JAVA3D] Performance of Appearance Changes >>To: [EMAIL PROTECTED] >> >>Hey folks, >> >>We have observed some interesting behavior when setting Appearance >>attributes on large scene graphs, and I was wondering if anyone could >>comment on this. >> >>We have found that building and setting the Appearance object (from >scratch) >>on a Shape3D node is actually faster than setting values for a few >>attributes of an existing Appearance object. For example, the first block >>below appears to execute faster than the subsequent block (as an example): >> >>// Build an Appearance object from scratch, and set it. >>Appearance myNewAppearance = new Appearance(); >>initAppearance(myNewAppearance); // this inits *all* relevant attributes >on >>the given object >>myShape3D.setAppearance(myNewAppearance); >> >>// Change a few attributes on an existing Appearance object. >>Appearance myExistingAppearance = myShape3D.getAppearance(); >>myExistingAppearance.getPolygonAttributes().setFillMode(myFillMode); >>myExistingAppearance.getRenderingAttributes().setVisible(myVisibleState); >>myExistingAppearance.getColoringAttributes().setColor(mColor); >> >>Does that make sense? If so, why would building and setting the Appearance >>object be faster than adjusting a few values on an existing Appearance >>object? Thanks for any insight. >> >>- Mauricio > >=========================================================================== >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".
