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
