From: tom flynn (tflynnt2++at++yahoo.com)
Date: 02/20/2004 14:47:53
--- David Lannan <david.lannan++at++sydac.com.au> wrote:
> The problem appears to be Performers'
> internal texture usage, and I
> am pretty sure no matter how you set the internal
> texture format you will
> always only get 16bit or 8bit indexed textures.
If I remember correctly, if you don't explicitly set
an internal format for your texture (see pfTexture man
page look for PFTEX_INTERNAL_FORMAT), Performer will
pick the optimal (best performing) internal format for
the hardware you're running on. On most IRIX systems,
that'll probably be an RGB 565 format. Windows might
default to something similar depending on your gfx
card.
If you're explicitly setting the internal format to
something like PFTEX_RGBA_8 and you're still seeing
a 16bit texture, then it may be a bug in Performer.
(maybe some code ifdef'd wrongly).
> Even with the Perfly app, perfect 32bit textures are
> reduced to ugly colour paletted textures.
> Is this because of the 'limited'
> windows support and the
not likely.
> IRIX systems are colormapped based (our Onyx3 does
> this also)?
colormap based?? Not sure what you mean by that.
Most of the visuals on Irix systems nowadays are RGB
or RGBA visuals. I believe the root window for X uses
an 8bit visual (except Onyx3), but that's about all I
can think of that uses an 8bit visual.
> Again, this has nothing to do with our engine, since
> perfly also exhibits
> exactly the same behaviour. I am hoping there is a
> simple fix for this, like
> a env variable that is supposed to be set on
> windows?
> PF_RGBA_INTERNAL_TEXTURES??
No env variable that I know of, just the
pfTexture::setFormat() method.
>
> Our model has been tested with flt (with rgb and
> rgba texture)
There's probably a flag that can be set in multigen on
that texture to make sure the texture internal format
is RGBA8. Someone more familiar with mutligen should
probably comment on this...
> What is Performer doing internally to the textures?
probably picking a more optimal format for the
underlying hardware.
> It would be helpful on
> PC if we could use compressed textures (ala dds)
> since many video cards
> support it, but I am guessing that only a move to
> DirectX would provide this
> capability.
OpenGL provides this capability as well. The .dds
textures that you refer to are known as S3 compressed
textures (S3TC). It would be up to Performer to allow
reading in such a texture and using the appropriate
OpenGL calls to use the texture. I don't know if such
functionality made it into pf3.1. This would only be
available on OpenGL implementations (gfx cafds) that
export the S3TC and ARB_texture_compression
extensions.
> Also, as a side note (and has been posted
> previously) Performer 3.1 has
> issues with is fragment and gprograms. Even though I
> get a valid
> vertex_program extension on my video card, the
> examples to not run the
> vertex program. Has anyone had success with the
> GProgram examples on
> windows? If so, what was your video card? We have
> tried FX1000, GF 4200, and
> ATI 9200.. again, these problems make DirectX seem
> well ahead of the game.
? How is DirectX even relevant? it's a low level
graphics renderer like OpenGL. (except using DirectX
ties you to Micro$oft forever and makes it more
difficult to port/run your program on any other
platform ever, ack!)
Performer is a scene graph that uses OpenGL for
rendering. The gfx card manufacturers write DirectX
and/or OpenGL drivers for their card. vertex and
fragment program support is available in both DirectX
and OpenGL and has been for quite some time.
Performer added support for opengl vertex and fragment
programs in pf3.1. Since you say your vertex programs
aren't working, perhaps there is a bug in the pf
implementation or in your code. showing a small
example (with full source code) that reproduces the
problem may help in getting your situation resolved.
hope that helps,
tom
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
This archive was generated by hypermail 2b29 : Fri Feb 20 2004 - 14:50:08 PST