On Tue, 5 Oct 1999, Jay wrote:
> "Jon M. Taylor" wrote:
>
> > On Mon, 4 Oct 1999, Club Neon wrote:
> >
> > > I can feel this falling from the GGI topic very fast...
> > >
> > > > > I am currently doing research on other ways to extremely compress images
> > > > > (which allow for lossless modes), but that will take a while.
> > > > Have you investigated wavelets?
> > > > As I understand them, they get incredible compression, and the quality
> > > loss
> > > > isn't very bad.
> > >
> > > The key part of that sentence is "quality loss", even if it isn't very bad
> > > there is still some.
>
> This has gotton WAY off-topic, but...
>
> >
> > Get used to it, because texture compression in hardware is here to
> > stay. People need to get used to machine-independent programming, and one
> > aspect of that is that you have to give up pixel-accuracy and lossless
> > compression. It is worth it, though, because you gain enormous
> > flexibility and portability.
>
> Compression has nothing to do with machine independency (unless you are saying
> you want to run on legacy hardware).
> Infact, it goes aganst platform
> independency. The new platform now must have a decoder written for it as well as
> the development machine.
The idea is that the decompression is done by the video hardware.
That is what makes it platform-independent. MPEG video is platform-
independent for the same reason.
> The only reason you would want to compress is if you
> have massive amounts of data (like video) or you are streeming it through a low
> bandwidth pipe.
Modern video games require CONSIDERABLY more bandwidth than
streaming video does. Even with AGP4X (~5Gbps bus), games like Quake3 can
peg the bus if you turn on all the fancy rendering options and crank the
resolution up (and use a tuned OpenGL library). That is why everyone is
moving to support texture compression in hardware.
> No flexibility is gained.
You can use larger textures without the performance hit. That's a
good deal of added flexibility for games designers, I can assure you.
> Avrage textures are about 512x512 and
> including bump-maps and RGB coloring + alpha you might as well say 512x512x5. If
> you have about 40 of these (which is about the amount you would use in an very
> average game screen) you want no bottleneck like your decompressor to slow your
> frame rates, even in hardware.
Decompression can be parallelized in hardware and only needs to be
done once per texture and then cached internally if you keep your
compressed textures in video memory. It will not impose ANY performance
penalty unless you go crazy with lots of rapidly changing huge compressed
textures.
> After that, what about multi layered textures,
What about them? Multitexturing will come after texture
decompression in the hardware pipe, and as such it should not impose any
penalty.
> and
> I haven't even begun talking about double sided textures,
? I have not seen any example of any such thing in hardware.
> or even multi-layered
> double sided textures with alpha holes.
I see what you mean now. Argh! Why do people do this sort of
thing instead of using alpha texture composition? Or even better, adding
some extra geometry for the hole so the hardware can properly remove
hidden surfaces?
> > > Also the important part is they aren't pixel accurate.
> > > Sure the longer you spend decoding the wavelet the closer you get to the
> > > orginal pixels. The problem with this is you can't be assured that when you
> > > are storing data for a sprite it will be decoded the same every time, by
> > > every machine.
> >
> > I got news for you, then: you have already lost that guarantee to
> > hardware texture filtering, which blends depending on lighting
> > characteristics and geometry.
>
> Which is exactly why you need to have acurate pixels. If you don't, your texture
> starts to look smeared Especily if you get really close to an object, or if the
> object has alpha in obscure places.
Which is why you are supposed to use alpha texture composition
instead of an alpha color component, so that the hardware has the ability
to apply the alpha op at the right place in the pixel pipeline.
> > > Might not be so bad for non-tiled textures wrapped around
> > > polygon solids, actually for organic things they might not tile to bad
> > > either especially if they were used in multi-layered textures were the seams
> > > can be obscured some.
> >
> > Precisely. Everyone is doing compressed textures.
>
> Not me. If I did, my demos would turn to crap ( as if they don't already look
> that way :-) )
Demos are not games.
> But your right, for a simple game, compressed textures are fine.
For a simple game, compressed textures are not necessary. For a
complex game, they are _vital_. You simply cannot put fine details that
don't fuzz out as you get close to them into your textures unless you
compress them or use a technique like vector texturing. And game
designers need to be able to add fine details to their games to take it to
the next level of realism.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
