DDS DXT1 bleeding edges on lightmap
Blitz3D Forums/Blitz3D Programming/DDS DXT1 bleeding edges on lightmap
| ||
| I have converted the textures for a lightmapped mesh to dds and patched the mesh file. This works so far. But there are some places with bleeding edges on the lightmap, like when a blue bulb of the neighbour room will bleed on the edge of the current yellowish lit room. This usualy hapens when you scale down a lightmap, so some texels have to share diffrent light sources. What could it be? I saved it as DXT1 with the default settings from within the PS plugin. Probably there's a limit for the size? The lightmap size is 1024*1024. |
| ||
| I'm not sure but to me it looks like the DXT1 compression get some color distortion in the pixels similar to the changes you see in a .jpg compression, this might be because of dxt1 is the lower quality, have you already tried with dxt3 and 5? may be, giving more "quality" to the compression will work ... Paolo. |
| ||
| Thanks, I'll try that next time. Although, I had the impression at least the default settings of DXT1 are nonlossy, if not all DDS textures ?!? |
| ||
| Maybe something to do with the Mip mapping settings. As you say, if you scale the lightmap down you can also get this effect sometimes. Doesn't the mip mapping also scale down the lightmap. I've had similar problems when using the standard Blitz mip mapping and a .bmp lightmap, but only when the camera is quite a distance from the object. Disabling the mipmapping corrected this but of course you need the mipmapping so never did solve this problem. Haven't had it with .dds files yet. |
| ||
| yep, essentially dds/dxt is lossy compression. for all 5 formats it takes a block of 4x4 pixels (called a texel block) and stores the 2 most significant colors. it then calculates 2 more colors from those, and thats it, just 4 colors per block. dxt1 uses this system alone, or with dxt1a it uses color3 for the transparent mask. dxt2 to dxt5 use the same system to store color but on top of that they have an alpha block of the 4x4 pixels, which doubles the filesize. dxt2/3 are called "explicit" because they use the alpha level directly, whereas dxt4/5 are interpolated which gives the smooth alpha gradient. so using dxt3 or dxt5 shouldn't fix the bleeding, if it is because of dxt compression. |
| ||
| If you could pack lighmap parts as 4*4, 4*8, 8*8 etc. divided by 4 regions then at least compression should not cause the bleeding? |
| ||
| Thanks for the info! I guess I'll use PNG for it then. Not so much loss, 2 megabyte or so. Got to edit the meshfile patching code, so it will exclude certain filenames from ".dds" patching. |
| ||
| It would be nice if we could use uncompressed R8G8B8 24bit dds. then the lightmaps would be without the bleeding... but as far as i know only dxt1-5 are supported by b3d ;-( maybe someone knows how to fix that?!? btw... here u can find a free converter for all available dds-formats: http://www.mnwright.btinternet.co.uk/programs/dxtbmp.htm |
| ||
| uncompressed dds? then you can use bmp as well... i can live with those bleedings, regarding the lower memory consumption compared to uncompressed bmp (especially with big lightmaps like 1024x1024). |
| ||
| ok, but if u use a lightmap 1024x1024 in bmp, tga, png, jpg or whatever the size of the file varies but still uses over 4mb in vram. the uncompressed 1024x1024 dds file is 3mb and would only use this size in vram... so we have 1/4 less... and on 512x512 its only 1/2 vram usage cheers, chi |
| ||
| "the uncompressed 1024x1024 dds file is 3mb and would only use this size in vram..." seems like i was wrong... i was told that this vram-advantage only works with dxt dds... if this is true it wouldnt make much sense to use uncompressed dds (also they doesnt work in b3d yet) so... sorry about that ;-) cheers, chi |
   |