Re: The textures on Octane MXI looks dirty

New Message Reply Date view Thread view Subject view Author view

Rob Jenkins (robj++at++sgi.com)
Wed, 20 Jan 1999 00:54:17 -0800


When Hector mentions trying with no TRAM, I was assuming he meant with
no TRAM at all, not just 1M TRAM so texture would be done SW ( so should
look good, if slow ). If you have 1 M TRAM then you're subject to the 16
bit texture limitation on Impact ( and OCTANE ) and can see the banding
Brett describes. With any TRAM installed, artifacts other than banding:
eg white spots, weird colors etc normally suggest a TRAM HW problem,
and, as Angus points out, this is best dealt with via an SGI support
call, TRAM is sensitive.

I have some general notes for Impact ( OCTANE ) texture which I'll paste
below, SGIers can see them on:
http://mirage.reading.sgi.com/support/impactInfo.html some if that page
is a bit out of date but most is useful.

Cheers
Rob

Banded Textures

Impact machines with 1MB of TRAM ( texture memory ) only support up to
16 bit textures. If an OpenGL ( or Iris GL ) application uses 4 channel
( RGBA ) textures then the maximum resolution is 4 bits per colour
component. This can mean that on textures with subtle colour gradients
in some banding may be apparent. To check the hardware on the machine
do:

/usr/gfx/gfxinfo

RESOLUTION/RECOMMENDATION

If you require 32 bit texture in their applications, upgrade to 4 meg
texture memory system.

In summary, the following are the supported texture formats on different
TRAM configurations.

BITS/COMPONENT 4 4 4 4 8 8 8 8 12 12 12 12
COMPONENTS 1 2 3 4 1 2 3 4 1 2 3 4

1 TRAM Y Y Y Y Y Y N N N N N N
4 TRAM Y Y Y Y Y Y Y Y Y Y Y Y

It is possible to disable the use of HW texturing on a 1 TRAM machine
see the texture summary below

Texture Summary

1) the largest texture you can load with one TRAM is 512x512... if a
polygon is supposed to be textured but shows up white, this is a good
candidate for your problem.

2) textures *must* be a power of 2 on each edge... i.e. 8x8, 16x16,
32x32, etc.

More specifically, the texture size is bounded by the TRAM size. We have
1M TRAMs, so the largest texture *size* is 1M. The amount of texture
data is dependent on the number of TRAMs in the system. There can be
either 1 or 4 TRAMs. With one TRAM, all channels of a texture are
multiplexed into the same TRAM. With 4 TRAMs, each channel is split out
into the individual TRAMs.

So, if you have 2D Luminance textures, you can create 1K x 1K textures
on a 1 or 4 TRAM system. But if you have RGBA textures, on a 1 TRAM
system, you can only create a 512 x 512 texture. A 1K x 1K RGBA texture
will work on a 4 TRAM system, each 1M R, G, B, and A channel will fill
the full 1M of each of the 4 TRAMs.

Same goes for 1D or 3D textures. The largest 3D texture size is still
1M, a possible size is 128 * 128 * 64. Depending on the number of
channels: Luminance, Luminance-Alpha, RGB, or RGBA, and the number of
TRAMs in the system, the texture size may have to be reduced.

There is an environment variable to control use of HW or SW texturing on
a 1 Meg TRAM Impact.

setenv USE_SOFT_TEXTURE 1

will disable HW texturing - only on 1 TRAM machines though. Obviously
just use unsetenv or set it back to 0 to re-enable. This isn't global,
in other words if you set this in a shell it only effects programs run
in that shell afterwards -if you run the same code in another shell (
without the variable set ) it'll use HW texturing. Also if you use
OpenInventor you can also use thetextureQuality field in a SoComplexity
node set to 1.0 to achieve this. This is useful if you are suffering
from banded textures.

Brett Chladny wrote:
>
> Hi,
>
> I don't know what exactly you mean by the textures look "spotty", but if
> you mean banding, it is because you are not using enough bits internally
> for the textures. The internal (in TRAM) and external (RGB 24 bit file)
> formats do not need to be the same. On an Octane, the default internal
> format is PFTEX_RGB_4 for RGB textures as appose to PFTEX_RGB_5 on the
> other computers. Try setting all textures to PFTEX_RGB_12 and see what
> happens.
>
> My next guess would be that the textures are too large and are being
> scaled down to fit into TRAM. I believe the largest single texture you
> can have in TRAM on an OCTANE MXI is 1 meg. This would mean that your
> texture could be blurry or fuzzy. To get around this, cut your geometry
> and texture up in such a way that you can map the original texture as
> two or more textures.
>
> Brett Chladny
>
> Hector Morales Campos wrote:
> >
> > Hello Everyone !!!!
> >
> > I have a Customer using Performer 2.2 on Onyx and O2, He development a
> > proyect
> > on those machines, and he bought a Octane MXI. The problem is when he wants
> > to use the same proyect on that new machine. the texture looks a litle spotty,
> > all of the images are RGB 24 bits.
> >
> > One test that I did, was run the same project without TMEZ board in the
> > Octane, and looks better but it ran slowly, and It isn't better as O2 or Onyx.
> >
> > Does any body know something about it, any information is helpfull
> >
> > Thanks a lot !!!!!
> > =======================================================================
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
________________________________________________________________
Rob Jenkins	Silicon Graphics 	mailto:robj++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Jan 20 1999 - 01:00:39 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.