Thread: RE: [Algorithms] Normal Map Compression
Brought to you by:
vexxed72
From: Matt G. <ma...@ar...> - 2001-03-30 17:21:16
|
> Anyone got any suggestions as to a good method of lossy > compression to use > for normal maps? Just a quick thought - you could try using a Dreamcast style spherical polar coordinates system. Eight bits phi, eight bits rho. One of those can also have one less bit info, as you don't need to encode an entire sphere - only the positive Y hemisphere will do for most things. Matt -==- -- Matt Godbolt Coder, Kleaners Project Argonaut Games PLC, UK |
From: Alex C. <al...@ar...> - 2001-03-30 17:22:16
|
> doesn't hold up very well. S3TC has even more of a fit as it > is trying to > fit a simple line through 3d color space when the 3 > components don't have > the usual kind of dependence of natural images. Perhaps a different s3tc compressor, designed for normal maps could help? You could also try a 16-bit hi-lo texture (see nVidia OpenGL docs). Alex Clarke, Programmer Argonaut Games PLC |
From: bmarshall <bma...@ra...> - 2001-03-30 18:04:34
|
> Perhaps a different s3tc compressor, designed for > normal maps could help? > > You could also try a 16-bit hi-lo texture (see nVidia OpenGL docs). > > Alex Clarke, Programmer > Argonaut Games PLC Thanks for all the replies so far everyone. Unfortunately I'm not working on the PC, so NVidia hardware... HiLo maps look nice but I don't think I'll be doing that decompression in software. I've got my own S3TC compressor that's pretty good - but its always going to have problems on these maps. Often you get quite a few normal directions inside the 4x4 block which is just too much for the compressor. unfortunately these high information areas have a very big impact on overall image quality. If I can't come up with anything else I'll try palletising, but I'd like a higher compression rate if I can get it... The only other thought I've had is I remember some scheme for stopping bilinear magnified textures from looking so bad when magnified by generating another texture which was combined with the original during filtering. Not a very good explanation I know but I can't remember exactly what it was which is driving me mad. Sort of like detail texturing, but not... I can afford a separate texture for this if it helps compress things. Greener grass and all that, but right now I'd really like to be playing around on a PC with lots of memory and a GeForce 3. Oh well... -Brian. Brian Marshall Rare Limited, Manor Park, Twycross, Warks, England, CV9 3QN Phone: +44(0)1827 883400 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
From: Matt G. <ma...@ar...> - 2001-03-30 17:25:11
|
> > Well, palettizing is great. The old-school way to do this is > to convert the normal to a spherical polar coordinate (two angles, > one from 0 to 2pi, one from 0 to pi). You can then quantize these > angles and store them in a few bits. Commonly, they're quantized > to 4 bits each, but that's just a form of palettizing. If you want > more compression, you can quantize to fewer bits, like 3 and > 2 perhaps, > for 5 bits total, or you could just use a smaller palette !! Damn my slow mail server... :) |
From: Sebastien D. <SD...@nv...> - 2001-03-30 17:25:47
|
With a GeForce3 and OpenGL, and maybe at some point in DX8 as well, = there is a new texture format called HILO. it is a two channel texture where the first channel encode the x component of the normal, and the second = channel encodes the y component of the normal. When you pass that in the = hardware, it computes the z component as sqrt(max(0,1 - x*x - y*y)) after an = internal 16 bit filtering (pretty kick ass!) - This basically projects the z component onto the hemisphere - which is what you want for your tangent space anyway. You can specify the external format as either HILO16 (32bits/texel) or HILO8 (16bits/Texel). Because the filtering on the hardware is always done in 16 bits, the external format HILO8 gives = pretty awesome results at only 16bits/texel. Just something to be aware of - = check out the nVidia OpenGL SDK on http://www.nvidia.com/developer for = examples on how to make use of that... -S=E9bastien # -----Original Message----- # From: bmarshall [mailto:bma...@ra...] # Sent: Friday, March 30, 2001 9:03 AM # To: gda...@li... # Subject: [Algorithms] Normal Map Compression #=20 #=20 # Anyone got any suggestions as to a good method of lossy=20 # compression to use # for normal maps? #=20 # I've quickly tried the obvious of trying Jpeg, but there are 2 = obvious # problems. #=20 # - The R/G/B channels don't really in a normal map aren't=20 # really like the # R/G/B of a natural image. So the assumptions about the image,=20 # and the human # vision system to make Jpeg compression work well don't really=20 # apply. So it # doesn't hold up very well. S3TC has even more of a fit as it=20 # is trying to # fit a simple line through 3d color space when the 3=20 # components don't have # the usual kind of dependence of natural images. # - The loss in the compression can change the length of the=20 # normal. Making # the normal a little shorter isn't too big a problem, but=20 # being larger than # one is undesirable. (I adjust the texgen used for generating=20 # the actual # lighting lookup from the perturbed normal to take a range=20 # slightly bigger # than 1 bit this does degrade the results quite a bit so I'd=20 # like to avoid # it.) #=20 # I thought a little about trying to exploit the fact=20 # that the R/G/B triple # is normalised for compression, and to also make sure the result stays # normalised but I haven't come up with anything. # Using indexed normals normally holds up for quite a=20 # small number of # normals - 256 works well, so I could apply this to the normal=20 # map. (Which is # just palletising it in effect.). Unfortunately I'd like=20 # higher compression # than that. #=20 # Any thoughts? #=20 # -Brian. #=20 # Brian Marshall # Rare Limited, # Manor Park, # Twycross, # Warks, # England, # CV9 3QN # Phone: +44(0)1827 883400 #=20 #=20 # _______________________________________________ # GDAlgorithms-list mailing list # GDA...@li... # http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list #=20 |
From: Martin F. <mf...@ac...> - 2001-03-30 17:34:04
|
Using 8 bits to store for each component of the normal you should be able to easily delta compress them into perhaps as little as 4 bits per channel. (1 signed bit) Alternatively, something I was thinking about for our current game palettize the normals and delta compress that, if any hardware could light the pallete that would be great though none exists that I'm aware of. Cheers, Martin -----Original Message----- From: bmarshall [mailto:bma...@ra...] Sent: 30 March 2001 17:03 To: gda...@li... Subject: [Algorithms] Normal Map Compression Anyone got any suggestions as to a good method of lossy compression to use for normal maps? I've quickly tried the obvious of trying Jpeg, but there are 2 obvious problems. - The R/G/B channels don't really in a normal map aren't really like the R/G/B of a natural image. So the assumptions about the image, and the human vision system to make Jpeg compression work well don't really apply. So it doesn't hold up very well. S3TC has even more of a fit as it is trying to fit a simple line through 3d color space when the 3 components don't have the usual kind of dependence of natural images. - The loss in the compression can change the length of the normal. Making the normal a little shorter isn't too big a problem, but being larger than one is undesirable. (I adjust the texgen used for generating the actual lighting lookup from the perturbed normal to take a range slightly bigger than 1 bit this does degrade the results quite a bit so I'd like to avoid it.) I thought a little about trying to exploit the fact that the R/G/B triple is normalised for compression, and to also make sure the result stays normalised but I haven't come up with anything. Using indexed normals normally holds up for quite a small number of normals - 256 works well, so I could apply this to the normal map. (Which is just palletising it in effect.). Unfortunately I'd like higher compression than that. Any thoughts? -Brian. Brian Marshall Rare Limited, Manor Park, Twycross, Warks, England, CV9 3QN Phone: +44(0)1827 883400 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
From: Martin F. <mf...@ac...> - 2001-03-30 17:37:07
|
Another idea. After Quantizing the normals into a palette your index buffer could probably be reasonably heavily compressed by a non-lossy system. Trying to use S3TC or JPEG would result in the same problems that occured attempting to compress the raw normal map. Cheers, Martin -----Original Message----- From: Martin Fuller Sent: 30 March 2001 17:35 To: 'gda...@li...' Subject: RE: [Algorithms] Normal Map Compression Using 8 bits to store for each component of the normal you should be able to easily delta compress them into perhaps as little as 4 bits per channel. (1 signed bit) Alternatively, something I was thinking about for our current game palettize the normals and delta compress that, if any hardware could light the pallete that would be great though none exists that I'm aware of. Cheers, Martin -----Original Message----- From: bmarshall [mailto:bma...@ra...] Sent: 30 March 2001 17:03 To: gda...@li... Subject: [Algorithms] Normal Map Compression Anyone got any suggestions as to a good method of lossy compression to use for normal maps? I've quickly tried the obvious of trying Jpeg, but there are 2 obvious problems. - The R/G/B channels don't really in a normal map aren't really like the R/G/B of a natural image. So the assumptions about the image, and the human vision system to make Jpeg compression work well don't really apply. So it doesn't hold up very well. S3TC has even more of a fit as it is trying to fit a simple line through 3d color space when the 3 components don't have the usual kind of dependence of natural images. - The loss in the compression can change the length of the normal. Making the normal a little shorter isn't too big a problem, but being larger than one is undesirable. (I adjust the texgen used for generating the actual lighting lookup from the perturbed normal to take a range slightly bigger than 1 bit this does degrade the results quite a bit so I'd like to avoid it.) I thought a little about trying to exploit the fact that the R/G/B triple is normalised for compression, and to also make sure the result stays normalised but I haven't come up with anything. Using indexed normals normally holds up for quite a small number of normals - 256 works well, so I could apply this to the normal map. (Which is just palletising it in effect.). Unfortunately I'd like higher compression than that. Any thoughts? -Brian. Brian Marshall Rare Limited, Manor Park, Twycross, Warks, England, CV9 3QN Phone: +44(0)1827 883400 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
From: Tony C. <to...@mi...> - 2001-03-30 18:40:04
|
>With a GeForce3 and OpenGL, and maybe at some point in DX8 as well, there is >a new texture format called HILO. it is a two channel texture where the Nice format. You could expose this in your DX drivers today as a FOURCC. Do you do that? Tony Cox - Lead Engineer Windows Gaming Developer Relations Group http://msdn.microsoft.com/directx=20 |
From: Doug R. <DR...@nv...> - 2001-03-30 19:20:49
|
Yes, we are exposing these as FOURCC codes in Direct3D 8.0. NVHS, NVHU (signed and unsigned) -Doug Douglas H. Rogers Manager of Direct3D Technical Developer Relations NVIDIA Corporation 3535 Monroe Street Santa Clara CA 95051 do...@nv... -----Original Message----- From: Tony Cox [mailto:to...@mi...] Sent: Friday, March 30, 2001 10:40 AM To: gda...@li... Subject: RE: [Algorithms] Normal Map Compression >With a GeForce3 and OpenGL, and maybe at some point in DX8 as well, there is >a new texture format called HILO. it is a two channel texture where the Nice format. You could expose this in your DX drivers today as a FOURCC. Do you do that? Tony Cox - Lead Engineer Windows Gaming Developer Relations Group http://msdn.microsoft.com/directx _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
From: Alex C. <al...@ar...> - 2001-03-31 12:41:37
|
I'm not very familiar with how S3TC works internally, so this may be a bad idea, but you seem to be able to give weightings to the r,g,b(,a) components when you compress. I'm wondering what results you would get if you gave the blue channel a weight of zero (and you clear the blue channel to zero), then compressed, and on decompression, you use the results as a 8-bit HI LO texture in the pixel shaders (my reading of the Geforce 3 docs suggests that this is possible)... When I have some spare time, I'll have a look into this. Alex Clarke, Programmer Argonaut Games PLC |