AnimationControl

• To: visad-list@xxxxxxxxxxxxx
• Subject: AnimationControl
• From: Doug Lindholm <lind@xxxxxxxx>
• Date: Tue, 18 Dec 2001 16:50:58 -0700

Hi,

I'm getting some great animation performance using AnimationControl, but
it is causing other problems.

I have multiple Fields which are functions of RealType.Time (which is
mapped to Display.Animation.) The Fields' time sets are NOT the same.
For a given time, I need to be able to display the appropriate time
sample of these Fields. Test03 gave me hope that this would work, but
now I'm running into some issues.

1) Say field1 has 1 minute intervals and field2 has 20 minute intervals
with the same start and end times. As I step through 1 minutes
intervals, I expect field2 to change at 20min, 40min,.... But, it
changes at 10min, 30min,...! I'm assuming this one is just an off-by-one
bug in VisAD?

2) I'd like to be able to call AnimationControl.setCurrent() with the
double value of my time. However, I don't want to see data from the
future. It looks like visad is rounding to the nearest time sample. I
can get around this by grabbing the AnimationSet, doing my own math, and
using setCurrent() with the integer index. So far, this is not a problem
but: setCurrent(-1) defaults the the LAST sample and
setCurrent(nBiggerThanLength) defaults to the FIRST! Is it just me, or
is this backwards? Bug?

3) With different end-points, things get more interesting. If I set the
animation time to now, I'd like to see my most recent sample from each
field. Unfortunately, only the most up to date field is visible in the
last animation step. The philosophy with setCurrent seems to be "always
display something" (even if it is from the wrong end ;-). Shouldn't the
animation steps do the same? If it is going to package up the nearest
neighbor into each step, would it make sense to make it do the same at
the extremes? Just an end-point bug?

4) Now with completely different time samples, things get to be a real
mess. I need to understand how scene graph caching works to make sense
of this. Does each Data object (DataRender?) have an associated scene
graph? I assumed "yes." But a Display has one AnimationControl whose
AnimationSet appears to be based on the first Field object added to the
Display. Samples of additional Fields seem to be added to the animation
steps in undesired places. Please, tell me this is only a result of bug
#1 above? I would expect the AnimationSet to be a union of all the
Fields' domain (time) sets. Is that the case? 

Now the caching question: If I have 4 huge image samples (15min
interval) and 60 smaller samples of something (1min interval), will I
have only 4 huge scene graphs cached and 60 small ones, or will I have
60 (or 64) huge things cached? Hopefully not the later. If I change a
property (e.g. color) of the smaller data set, would scene graphs be
recomputed only for the smaller data, or will I get hit by recomputing
scene graphs for the huge images also? 

I've been getting some unexpected performance hits. I'm testing VMET
with 100 samples of a 200x200 image and about as many samples of 20
shapes. (I'm running on a dual P4 1.7GHz with 2Gb RAM running Linux and
a pretty beefy graphics card.) It takes about a minute to start up and
display the data. Now here's the odd bit: If I change a Display property
such as RangeControl.setRange() on the axis maps, it take THREE times
longer than the init time to complete the change! I'm not ruling out my
own bug here, but it's something to keep in mind if you're debugging
VisAD. 

Thanks,
Doug

-- 
*----------------------------------------------------------------------*
| Doug Lindholm, Software Engineer          |  E-mail: lind@xxxxxxxx   |
| Research Applications Program             |   Phone: 303-497-8374    |
| National Center for Atmospheric Research  |                          |
| P.O. Box 3000                             |     There's no place     |
| Boulder, Colorado 80307-3000              |        like $HOME        |
*----------------------------------------------------------------------*

• Follow-Ups:
  • Re: AnimationControl
    • From: Bill Hibbard