Re: texture quandery.

New Message Reply Date view Thread view Subject view Author view

Chikai Ohazama (chikai@talula)
Thu, 5 Aug 1999 13:20:06 -0700 (PDT)

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
>

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:39 PST