Re: texture quandery.

New Message Reply Date view Thread view Subject view Author view

JB West (jbwest@slomo.bothell.lgc.com)
Thu, 5 Aug 1999 14:01:07 -0700

The following is NOT a great idea. I make a LOT of use of 2D textures in
my application. Thus, what I do is cut the Volumizer texture size to 32Megs,
interleaved, shared texture objects; works great. With the latest Volumizer
& patch, I can get > 200Mbytes/second average download rate on an IR2E/2RM's.

On Aug 5, 1:20pm, Chikai Ohazama wrote:
> Subject: Re: texture quandery.
> IR doesn't manage textures well at all, so you have to do it yourself. So
> here are some suggestions on possibly making it faster. Try taking out
> the volumeOptimize command in the init call. This will make it so that
> texture-objects are not used, there forcing a download each frame. Also
> try change it to INTERLEAVE_2WAY. It will still be slow, but hopefully
> not as slow as you're going now.
>
> Hope this helps.
>
> ________________________________________________________________________
> Chikai J. Ohazama, Ph.D. SGI
> Member of Technical Staff 2011 N. Shoreline Blvd. ms 525
> Advanced Graphics Division Mountain View, CA 94043.1389
> Telephone: (650) 933-6533
> FAX: (650) 932-0511
>
>
>
> On Thu, 5 Aug 1999, Fred Dech wrote:
>
> > hi.
> >
> > my dev platform is IR w/4 RMs. displaying large volumes.
> > application is Performer-based, using a heavily modified version of
> > Volumizer Performer node from the Performer example program.
> >
> > symptoms:
> > 1. 512x512data at 128 (1 brick) or less slices, great performance (~20
fps).
> > 2. with over 128 slices (>1 brick) performance goes south, big-time
> > (~0.15 fps)
> > 3. remove small texture(s) from GUI portion of application and great
> > performance returns to multiple brick volume (512x512ushort) over
> > 128 slices.
> > 4. i uninstalled patch3696, just to check. no change.
> >
> > conclusions:
> > 1. i'm sc**wed! :o :^)
> > 2. the texture(s) in my GUI are killing Volumizer performance when more
> > than one brick is required to hold the voxel data. but why?
> >
> > any suggestions would be greatly appreciated.
> >
> > --fred
> > --
> > Fred Dech fdech@uic.edu
> > VRMedLab
> > (312) 413-3092: fax (312) 996-8342
> >
>-- End of excerpt from Chikai Ohazama

-- 
JB West | jbwest@lgc.com | downsized .sig

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:21:40 PST