Re: p.s., Re: VisAD 3D surface graph performance

Hi Lezlie,

If your points are not truly random, but you know how
they arranged and how they can be organized into
triangles (or even a grid), then you write your own
text reader and construct your own DelaunayCustom for
them to express your organization into triangles (or
if they are in a grid, construct a GriddedSet).

But if they are random, you are stuck with Delaunay

Good luck,

On Fri, 8 Apr 2005, Lezlie Fort wrote:

> Hi Bill,
> Thanks so much for your reply.  I should preface my response by
> indicating my hope that you saw the second addendum message that I sent
> out.  The number in my initial mail (380) referred to a single "group"
> of Depth parameters.  There were 20 such groups in my data set, so the
> true number of points was 7600.  But even that number is small compared
> to the 42000 that you mentioned in your first reply!  I think that you
> nailed my problem, though, in your p.s.  I am using the TextAdapter to
> read in my data files, and I looked at to see what was
> going on.  Sure enough, based on my defined math type, it is creating an
> Irregular set using the Delaunay algorithm.  I did some brief research
> online and found out that performance of Delaunay can be as high as
> O(n^2), so that helped me to understand what was happening.  I read one
> post where someone was plotting over 100,000 points using the algorithm,
> and had to wait for over 8 hours for the calculations to complete.  I
> read about other algorithms out there, but Delaunay seems to be one that
> is prevalent.  I feel better just having an explanation for what I am
> seeing.  If I have time, I might do a little more research into the
> Delaunay algorithm.  One post suggested that a way to reduce performance
> time is to pre-sort one of the vectors involved in the calculations (the
> vector that is associated with the most dramatic changes in data
> values).  They indicated that such a step could result in a performance
> savings of 25%.  But, like I said, this is just cursory research.
> At any rate, I have been very pleased with VisAD, and this is really the
> only issue that I've run into (although I've had a few questions along
> the way, as my recent posts will attest ;).  And it's not really an
> issue, in the long run.  For large data sets I can always plot 3D line
> graphs, which are extremely quick.
> Thanks again!
> lzf
> Bill Hibbard wrote:
> >Another possibility is that you are constructing an
> >IrregularSet in your data, which can be slow. But
> >Test29 constructs and displays a colored surface from
> >an Irregular2DSet of 1024 points in just a few seconds.
> >
> >On Fri, 8 Apr 2005, Bill Hibbard wrote:
> >
> >
> >
> >>Hi Lezlie,
> >>
> >>Something's wrong here. Lots of the test programs in the
> >>visad/examples directory render surfaces with RGB mappings
> >>that are much larger than 380 points, and much quicker than
> >>a minute even on my old 500 MHz laptop with a bad old
> >>graphics card. You might try running Test33, Test37 and
> >>Test61 (its volume rendering is made of a series of flat
> >>surfaces with a total of over 42000 points, and runs in a
> >>few seconds on my laptop).
> >>
> >>Bill
> >>
> >>On Thu, 7 Apr 2005, Lezlie Fort wrote:
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>I have a VisAD performance question.
> >>>
> >>>I've written recently before - indicating that I am creating a number of
> >>>different graphs using ASCII space-separated input files.  One of the
> >>>graph types that I'm generating is a "4D" surface graph.  Yesterday, I
> >>>ran a case with the following math type:  (Time,Depth)->(Speed,col),
> >>>where "col" is a fourth dimension that I have mapped to Display.RGB.
> >>>The case that I ran had about 380 data points in  all four vectors, and
> >>>I found that on my Linux box (nVidia GeForce FX graphics card, 1.5GHz
> >>>processor, 512M RAM), it took about 1.5 minutes for the graph to
> >>>generate.  On my Windows XP box (2.27 GHz processor, 512M RAM, Intel
> >>>82845G video board - Open GL version of Java3D), it took about 3.5
> >>>minutes to generate.  I ran additional cases where I increased the data
> >>>size, and ended up killing the graph-generation process after 5 minutes
> >>>of intensive disk-chunking.  I know that 3D surface generation is very
> >>>computation-intensive (3D line graphs of the same data come up almost
> >>>instantly), but I was wondering if these performance numbers that I'm
> >>>seeing are typical.  I've tried to find information on other graphing
> >>>packages (eg:  MatLab) to determine what kind of performance one would
> >>>expect with them, but seem to have encountered varied information.  Any
> >>>ideas on whether what I'm seeing is typical, or is there perhaps
> >>>something that I am doing extremely incorrectly?
> >>>
> >>>Thanks alot,
> >>>lzf
> >>>
> >>>
> >>>
> >>
> >>

  • 2005 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the visad archives: