Thanks for the info, Bill. I'm afraid the current behavior is a show
stopper. I poked around in the code to see if I could override
something, but the changes went a bit too deep for my comfort. Any
suggestions?
Bottom line: I need to be able to set the current time (by value
preferably) and see my data for the nearest time samples <= the current
time. (kind of like the Price is Right :-)
That also means that if I setCurrent to the last animation step, for
example, I should see the latest of all my Fields, no matter how old.
(see point 3 below) If I setCurrent to something before I have data for
a particular Field, then I should see nothing for that Field, though I
may have valid samples for other Fields (e.g. I'm still within the range
of the AnimationSet.)
Thanks,
Doug
Bill Hibbard wrote:
>
> Hi Doug,
>
> > 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?
>
> No, this rounding behavior is intentional. It uses Set.valueToIndex()
> to pick the closest time sample in each sequence.
>
> > 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?
>
> Yeah, I admit this is a bit weird. Its there to implement
> cycling the sequence during animation. One way around it is
> to call:
>
> Set aset = animation_control.getSet();
> int max = set.getLength() - 1;
>
> then to clip your values to the range (0, max).
>
> > 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?
>
> If the current animation value falls outside the range for
> a sequence (i.e., valueToIndex() returns -1) then no image
> is shown for that sequence.
>
> > 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?
>
> Caching might not be the right word. Each image of each sequence
> is in the live scene graph, and one or zero image is chosen from
> each sequence using a Switch node in the sequence.
>
> The animation Set is computed iteratively. It starts as
> the Set of the first sequence encountered. Subsequent
> Sets add any points not covered by the accumulating
> animation Set. The idea is that the animation Set should
> be as small as possible, but still hit each image in each
> sequence at least once (note the sequences don't have to
> be of images - they can be Data objects of any MathType).
>
> > 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?
>
> The granularity of the recompute decision is each
> DataReferenceImpl passed via addReference() to the
> DisplayImpl. Changing a Control will affect a DataReferenceImpl
> if the MathType of its Data includes the RealType of
> the ScalarMap associated with the Control (i.e., if
> the Control change can affect the depiction of the
> Data).
>
> > 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.
>
> If you are calling setRange() for multiple axes, make sure
> you bracket them inside:
>
> display.disableAction()
> // calls to setRange()
> display.enableAction()
>
> If this doesn't fix the behavior problem, then I'd like
> to experiment with your application (if I can get it in
> reasoanbly compact form).
>
> I had to make some choices for how VisAD animation logic
> would work, and I used our experience with Vis5D as a guide.
> If you can find a way to make this logic do what you need,
> that would be a big help. But please let me know if there
> are any show stoppers.
>
> Cheers,
> Bill
> ----------------------------------------------------------
> Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
> hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
> http://www.ssec.wisc.edu/~billh/vis.html
--
*----------------------------------------------------------------------*
| 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 |
*----------------------------------------------------------------------*
