Question About Annimation

So I'm working my way through the JOGL 2 tutorial on the web site (Chua Hock-Chuan's) and the first tutorial uses an FPS animator object but only a 2D triangle appears in the JFrame, and there is not annimation (movement).

One of the later tutorials draws a 3D triangle (pyramid) and a 3D square (cude) and then starts them rotating.  This program also uses an FPS animator object.

Why is the "movement" in the second and not the first?  Both animator objects are started in the code!

Is the first one actually moving (rotating) but because it's 2D the movement can't be observed?

Or are there other function calls in the pyramid and cube example besides the call to start the animator that cause the movement?

Sorry for such basic questions, but I'm just starting out.

Mike

The animator doesn't actually animate anything. It is a convenience class that calls the display method over and over again. That is so you have some place to put your own animation code and have it called repeatedly.
The difference between just making your own loop and the animator is that it tries to make the calls at an even rate.

So let me see if I understand this; when one uses an animator class (e.g. FPSAnimator) without sub-classing it all one is doing is saving the work of writing the loop to call the display function iteratively.

Am I to assume that as one would like more advanced animations, one then sub-classes an animator class and adds code to control the more advanced animation?

I think I'm going to have more questions on this as I work more closely with the first few examples in the tutorial, but I want to make sure I understand your reply for now.

Thanks,
Mike

On 03/25/2014 02:29 AM, Mike [via jogamp] wrote: The GLAnimatorControl implementations (Animator, FPSAnimator)
are helping to periodically issue a 'display()' call on the attached
GLAutoDrawable.

Further more, since GLAnimatorControl is attached to one or more
GLAutoDrawable, it makes the latter aware of the existence of such
periodically refreshing thread.
This allows GLAutoDrawable to defer a display() call,
i.e. allow the animator to handle it guaranteeing fluent updates.
This is documented in GLAutoDrawable, see invokeGL(..) etc.
Further, in case of NEWT or GLCanvas, the native windowing toolkit's update
will _not_ issue a display() call if an animator is attached and animating
for the same reasons.

Animation of objects in a scene is a different subject,
here you probably want to look into keyframe based animation,
i.e. changing rendering parameters over time.
  f(t,..) -> f', with t [t0..t1]

Of course, any animation will benefit from proper 'in time'
display update cycles, which is guaranteed if using the Animator
based on v-sync if enabled -> glSwapInterval(1).


~Sven

>
> Thanks,
> Mike
>