"PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals."
- Jon Ribbens
More pages: 1 2 3 4
Started working at ATi
Tuesday, May 4, 2004 | Permalink

Just began working at ATi today. Been spending the day setting up my work system and doing the paperwork. So it has been a big day, but very little exciting things to do. The more exciting stuff is ahead, once I get to do any real work.



Enter the code below

Thursday, June 3, 2004

I don't call 15% performance improvement lame or useless. That's what I'm getting in my test app I'm running right now. It will probably go up when I increase resolution. The normal way of doing bumpmapping is by using a RGBA8 texture. That gives 4:1 compression. If we start revising things like you do then we could conclude that DXT1 isn't the typically quoted 8:1 either, only 6:1, or actually just 4:1 if we take into account that the stored pixels are only 16bit precision. You can count whatever way you want depending on what your source material is. If you use a RGBA32f source you could claim a 32;1 compression for DXT1. Comparing typical usage scenarios, it's a 4:1 compression.

Sunday, June 6, 2004

I don't think so that the normal way of doing "normal mapping" (Just a side note: real bump mapping ala Blinn actually requires only a single value heightfield) is RGBA8 texture, at least I normaly would use U8V8 (upps I forgot that is probably a format which does not exist under OGL). Yep DXT is not that great either I agree with you (it basically brings more problems than benefits)

Sunday, June 6, 2004

Well, first of all, there's no such thing as "real bumpmapping". Just because Blinn did it in one particular way doesn't mean that's how it must be done. It's inefficient to deal with heightmaps directly.

No, you don't agree with me on DXT. Both DXT and 3Dc rocks IMO. Benchmarks in a test app I've done:

DXT1 + 3Dc = 530 fps
DXT1 only = 490 fps
3Dc only = 380 fps
No compression = 280 fps

I get almost twice the performance with compression than without, and if I add some per-pixel phong lighting I'm still getting over 60% performance boost, at nearly no visible quality reduction.

Monday, June 7, 2004

Excuse me but Mr. Blinn was the original idea provider. Personally I do not see a great inefficincy in Blinn's approach, many people just say that because Blinn's approach is more difficult to understand and using normal maps is plain easy (but for dynamic maps, filtering gets more complicated and takes more time than just calculation the partial difference from a heightmap).

Oh and about DXT tell that your artist he will likely kill you!

Tuesday, June 8, 2004

Well, it depends on if you want to call normal maps efficient or if you want to call height maps inefficient. But normal maps are more efficient. Just grab a texture sample and you're ready to rock.

Oh, and I am my own artist. But I guess real artist aren't quite happy with RGBA8 either. RGBA32f or nothing.

Tuesday, June 8, 2004

Well you still have to convert your light and eye vector into tangent space. I think heightmaps have three major advantages:

-Less space
-Pretty straightforward for dynamics content
-Probably easy to filter

They have one big disadvantage: It is hard to store surface details taken from High-Res-Models for Low-Res-Models.

Well about RGB please show me a paintprogram which can handle RGBA32f? I don't know one. The problem with DXTx (x=1-5) is that it really can screw your colors. If you have many graytones or grayscale images it can become a real nightmare.

More pages: 1 2 3 4