John,
BranchGroup does create some duplicated data, and the amount of memory
varys depending on what is above and below the BranchGroup. The memory may
increase significantly with the number of heavy weight nodes in it path, such
as TransformGroup, OrderedGroup, SwitchGroup and SharedGroup.
But in the case you've mentioned, the amount of duplicated data per
BranchGroup is pretty small.
- Chien Yang
Java 3D Team.
> X-Accept-Language: en
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Tue, 24 Apr 2001 10:53:33 -0500
> From: John Wright <[EMAIL PROTECTED]>
> Subject: Re: [JAVA3D] Performance Sutras - BranchGroups
> Comments: To: Kevin Rushforth <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> Thanks for the clarification Kevin, that makes good sense. For our
> projects, performance concerns are reasonably handled by scheduling our
> work inside behaviors that wake up every so often (typically 20 times
> per second). Our GUI has remained responsive and the frame rate is
> often over 100 fps. I think I'll look into using this for exactly the
> purpose you just mentioned (the user might want another application or a
> non-3D thread to be more responsive).
>
> Kevin, (or any other Sun Engineer) could you tell us exactly what impact
> a BranchGroup has? We are looking at having to put hundreds of models
> underneath BranchGroups just so that we can attach and detach them as
> the user moves in the scene. Is each BranchGroup going to use a few
> bytes of memory or will they create significant duplication of data?
>
> Just to clarify this assume this relatively absurd example:
> BG
> |
> BG
> |
> BG
> |
> BG
> |
> BG
> |
> Shape
>
> vs
>
> BG
> |
> Shape
>
> Do those extra BranchGroups waste a lot?
>
> Or our more practical, actual application:
> BG
> |
> -----------------------------
> | | | | | | |
> BG BG BG BG BG BG BG
> | | | | | | |
> S S S S S S S
>
> vs
>
> BG
> |
> -----------------------------
> | | | | | | |
> S S S S S S S
>
> How much impact will this make to memory usage and performance?
>
> - John Wright
> Starfire Research
>
> Kevin Rushforth wrote:
> >
> > This was put in at the direct request of application developers who
> > were complaining that their scenes were running at greater than 100
> > frames per second and chewing up all of the CPU time needlessly. The
> > intent is to allow an app to set a speed limit of, say, 1/60 or 1/30 of
> > a second.
> >
> > If what you want is the fastest possible frame time, then yes, it isn't
> > useful to you.
> >
> > --
> > Kevin Rushforth
> > Java 3D Team
> > Sun Microsystems
> >
> > [EMAIL PROTECTED]
> >
> > >Date: Tue, 24 Apr 2001 09:28:24 -0500
> > >From: John Wright <[EMAIL PROTECTED]>
> > >Subject: Re: [JAVA3D] Performance Sutras
> > >To: [EMAIL PROTECTED]
> > >
> > >Chris,
> > >
> > >Another case of weak documentation, (setMinimumFrameCycleTime) "will
> > >ensure that the time between the start of each successive frame is at
> > >LEAST the specified number of milliseconds" ie this will introduce a
> > >"delay" between displaying frames. Perhaps useful if you are trying to
> > >make a slide show and want each frame to remain on screen for at least
> > >one second (or whatever set time you wish). But for developers trying to
> > >get the fastest frame rate possible it seems to be worthless.
> > >
> > >- John Wright
> > >Starfire Research
> > >
> > >ChrisThorne wrote:
> > >>
> > >> Thanks John, I will update these.
> > >>
> > >> >
> > >> > Under "Control of Framerate" you can set the MAXIMUM framerate, if your
> > >> > machine can't maintain that level of performance framerate could be
> > >> > lower.
> > >>
> > >> Curiously it sets the minimum frame rate - the delay between frames.
Java3D,
> > >> according to the API doc, will ensure at least this rate is maintained.
I
> > find this
> > >> a bit strange as on some systems it would not be able to maintain the
rate.
> > >> I would have thought a max frame rate API call would make more sense as
you
> > >> could use it to free up cycles for other work on fast systems.
> > >>
> > >> Chris
> > >>
> > >>
===========================================================================
> > >> 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".
>
> ===========================================================================
> 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".
