Bumpmaps are blocky Created 18 years ago2006-03-09 04:48:31 UTC by Guinea Pirate

Im guessing its picking up those compression artifacts you get in JPEGs, since they were my source files. Any way to smooth it out?

add "nocompress" "1" to the normal's .txt file then recompile it through Vtex....?

What exactly is wrong about those textures? I mean, how did you intend them to look like?

Its not the textures, its the bumpmaps. Just that blocky pattern is undesirable.

Do you mean the blue squares on the top of the left one?

I noticed a big difference in bumpmap quality before i put "nocompress" in the .txt file, before bumpmaps turn blocky or squarish in one direction.

I did that but they still look blocky. I noticed in the vtex compiler it says "Implicitly disabling nice filtering". Could that have anything to do with it?

what exactly is a bumpmap?

A filter that enables 3d effects in flat 2d textures. A normal map indicates which parts of a texture stick out more than the rest.

I don't think normal maps and bump maps are the same.

They are. The Game industry gave it the name bump map, in the ol' days we called it normal mappin' . though i could be completely wrong here

In this case, the word "normal" refers to the mathematical concept of perpendicularity. A normal map gives data on the texture properties that are perpendicular to the 2d texture itself. In other words, the "bumps" the texture has. I'm not 100% sure though.

http://en.wikipedia.org/wiki/Normal_map

Edit: in HL2 materials, the method used is not bump maps (greyscale) but normal maps.

Is there any way to view the normal map after its compiled?

VTF explorer?
I haven't tried it, but I think it will work.
I thought the normal map was compiled exactly like the TGA you get when applying the Photoshop filter...

I seem to have resolved it by tweaking with the cubemap size. Ill have to experiment and see what size works best.

I am creating textures for HL?, too and I know this problem very well.

HL? usually compresses textures with the DXTn method.
Basics of DXTn: it splits the texture into 4*4 pixel blocks, then stores two reference colors for each block (2*16bit) so that each pixel of a block can mix its color from those two (16*2bit), that way you'll have 64bits for each block, which is quite a good ratio.
For normalmaps though, this compression method is rather useless and often causes entire blocks to have the same color, which makes them appear blocky.

Solution: do not compress normalmaps, or make them larger. Both will increase the filesize, the latter however might also make the texture cause longer rendering times.
For each normalmap, you'll have to decide, which is more important: size or beauty. In general, very smooth normalmaps should not be compresses, while noisy normalmaps hardly suffer from DXTn compression.

For HL? texture conversion and viewing, I strongly advise using VTFEdit.
It is the most advanced application for creating HL? textures and lets you easily control all propertires of a .vtf.