Re: texture quandery.

New Message Reply Date view Thread view Subject view Author view

Fred Dech (fred@cerulean.bvis.uic.edu)
Fri, 6 Aug 1999 12:40:23 -0500 (CDT)

great. a native Performer Volumizer API sounds nice. however...

i guess i still don't follow exactly what is being describing. if i'm
working with a 2byte 512x512 image list, and i'm using, say, 1 128x128rgba
2D texture, i can get acceptable performance using various different brick-
sizes. but after i exceed 128 data images, whether with a brick size of
32x512x512 or 64 or 128, performance hits a logjam. now a 64zsize brick
volume of 129 slices performs alot better than a 128zsize brick for that
number of slices, but i can't live with anything less than about 12 fps,
and i'm getting more like 1.

i tried not running voAppearanceActions::volumeOptimize(). i tried
changing the parameters to INTERLEAVE_2WAY or SHARED_OBJECT. if anything
performance got worse.

if i remove the 2D textures, i get performance back, but there goes
the visual ID structure of my GUI. even an itibit 2x2pixel 2D texture will
cause the app to grind to a stand-still. i have to resolve this. i can't
make an effective GUI without textures. any more advice?

thanks.

--fred

Chikai Ohazama wrote:
>
> Hmmm... I guess I misunderstood the problem. If you're willing to live
> with a 32 MB texture and all your other 2D textures fit into 32 MB, then
> that works too. I just reread Fred Dech, and realized that he's using
> Performer. For those of you at SIGGRAPH, go to the Friends of Perfomer
> session and you'll find a pleasant surprise. We've got a Volumizer node
> working in Performer.
>
> ________________________________________________________________________
> 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, JB West wrote:
>
> > 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
> >
> 

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