The reason I can't use the interpolator is that this is for a class, and I
need to derive the mechanisms to demonstrate the speed and path...
So, now, I'm using a thread to change the transformGroup constantly, it is
not ideal, as my program has lots of tiny idles instead of using the time to
process..
My loop:
Calculate new coordinates->updates coordinates to branchGroup -> sleep for
33ms(for 30fps)
This might be a general Java question... Is there better way to do this?
Chu
> Chu,
>
> my other post partially answers your question. I'd just like to add some
> more clarification.
>
> I have a 133 Mhz Pentium, and due to a bad choice of graphics cards it's
> limited to software-only rendering. I can only achieve frame rates of 1 to
> 2 frames per second! I'm telling you this so you know that you should not
> make any assumptions about rendering capabilities on the user's side.
>
> As my other post stated, Transforms are the way to move things in J3D.
> Definitely faster than destroying and re-creating elements of the scene.
> It's especially valuable that nodes moved with transforms don't need to be
> re-compiled.
>
> Now if you're going to be simulating continuous motion, the way to go is a
> PathInterpolator. You set this up with a starting position, an ending
> position and a speed, and then it manipulates the associated transform to
> move your part around.
>
> What ends up happening with PathInterpolators is that J3D will re-render
> your scene in a loop and as quickly as possible, and will move your part a
> distance corresponding to the time since the last rendering. Thus, if your
> user has slow hardware, your part will move in large steps and perhaps
> appear a bit jerky, but if the graphics hardware is good and fast the part
> will move in small steps and the motion will appear smooth. In either
case,
> the speed of motion as seen by the user, i.e. the amount of distance
> covered per second, will be the same.
>
> So once you have "programmed" the motion of one or more parts of your
scene
> using PathInterpolators, it's actually the rendering driving the motion
> rather than the other way around. This setup lets J3D work as quickly as
> possible, as efficiently as possible. Other List users may tell you about
> some problems in the details, but it's a good start.
>
> -Carl-
>
> At 03:07 09.11.00 , you wrote:
> >Just a add on question to my last question...
> >
> >I'm writing an app that simulates some kind of path generation and
velocity
> >control...
> >
> > >From my opinion the easiest way to do it is to regenerate the whole
branch
> >group constantly, about 5-10 times per second and constantly redraw the
> >canvas to simulate it..
> >
> >But before I go ahead and do it, can usual PCs with 300Mhz processor
handle
> >it and generate the frames in time?
> >
> >Chu Tan
> >
> >
> >_________________________________________________________
> >Do You Yahoo!?
> >Get your free @yahoo.com address at http://mail.yahoo.com
> >
>
>===========================================================================
> >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".
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
===========================================================================
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".
