Mipmap Levels

[rattle]

Is there any chance on increasing the threshold when they kick in? No wonder MR.D's textures look like pie. At a closer distance you already look at the third mipmap level which is 128x128 for a 512x512 texture.

I made a test model and DDS texture with numbered mipmaps, get it from here.
(excuse me for making it reflective, was stupid I know)

Anisotropic filtering or and the speed ups in the driver were disabled.

Screens:


Click for bigger images.

[smoth]

Click for bigger images.

Wow, I always thought it was low mip but never thought it was this bad. This one here really blew my mind, the fact that it is so close and on the side it already want to go to mip three.

This confirms what I have been thinking for sometime. Dear god tell me there is away to adjust the miplevel threshold

[KDR_11k]

That looks as bad as some of tghe "optimizations" graphics cards use on popular benchmarks.

[Kloot]

Mipmap thresholds are determined per fragment by the OGL
implementation, and as far as I know that behavior cannot be
changed programmatically. It's possible Spring sets the wrong
filtering type somewhere (ie., not GL_LINEAR_MIPMAP_LINEAR),
but nothing seems out of place with the texture-handler code
so this is pretty hard to pinpoint.

[rattle]

Uh nevermind...

The crappy results came from AF being disabled, mip level is a lot better when it's enabled.

[AF]

Code: Select all

glEnable(GL_AF);
glAFfunc(GL_COOKIES);

[rattle]

I disabled AF on purpose, but spring uses the maximum available AF anyway if the driver is set to application control, which I found out later.

[jK]

Mipmap thresholds are determined per fragment by the OGL
implementation, and as far as I know that behavior cannot be
changed programmatically. It's possible Spring sets the wrong
filtering type somewhere (ie., not GL_LINEAR_MIPMAP_LINEAR),
but nothing seems out of place with the texture-handler code
so this is pretty hard to pinpoint.

glTexEnv(GL_TEXTURE_FILTER_CONTROL,GL_TEXTURE_LOD_BIAS,-1.0)

[Tobi]

Shouldn't be needed tho, unless driver is bugged? Forcing lower mipmap level should just cause moir├â┬® patterns to appear when moving.

[KDR_11k]

Most likely the drivers are intentionally bugged to make the card seem more powerful in benchmarks.

[jK]

you could make it a springrc option, 'cos it seems there are many ppl complaining about it (me likes blurred textures and i would favor to add mipmaps to textureatlases ^^).

[Tobi]

Adding mipmaps for texture atlases is a bit of work because the images need to be spaced out properly for each mipmap level. (just downsampling the top level mipmap gives artifacts on the borders of the textures on the lower mipmaps of the atlas, as you probably know)

Would be nice to have it, but someone would need to code it then; for now all attempts at mipmapped texture atlases I remember resulted in some form of texture bleeding / black rectangles around sprites in anything but the top level mipmap.

The option is fine with me, same thing applies tho; I won't code it, but if someone else does I wouldn't mind applying the patch.

[rattle]

Or the UV coordiantes need to be offset inside by a pixel on all sides for each mip level I guess...

[Argh]

Yeah, that would work, but that'd require very strict sizes for textures, otherwise it'd just be a guesstimate, given that it'd have to be done through the GL_TEXCOORDs. I think that the problem there is that if it goes outside the bounds, it assumes an alpha of 255, when it should assume a value of 0.

[Tobi]

Or the UV coordiantes need to be offset inside by a pixel on all sides for each mip level I guess...

They'd need to be offset by a different amount for each mipmap level, which'd require figuring out the mipmap level in software, which, AFAIK, is impossible (or very hard) to do reliably.

[jK]

Also you would stretch the image each level a bit more, and clamp things of.

Btw, there is already a problem with the uv-coords. If you work with transparent pngs in full-opaque alpha CEGs, you get always get ugly borders around the particles (tested with 3 gfx cards).
So it would be nice if there would even w/o mipmaps a border around each image in the texture atlas.

[rattle]

There shouldn't be any if the borders are fully black. If you were using transparencies and Photoshop I'd put the alpha on with DXTbmp instead, IIRC it supports PNG too.

[jK]

the borders are fully black.

the problem is it shows ~1pixel of a different image (linear filtering?), those have black borders but they aren't using transparency, so if you don't use additive blending, you the always see those black lines around the particles.

[Argh]

Hmm. So, if the texture coordinates were set to X,Y values for the grid, then 0.99 of that size, then offset appropriately, they might work right, as they'd always be on the "inside". The only problem then would be that textures that went right up to the edge of their area would maybe lose the pixel at the edge. Nobody does that, unless they're stupid, anyhow, so that might just work...

[KDR_11k]

I always thought mipmaps were generated by combining 4 pixels into 1 so there would be certain coordinates (some powers of two) that would never get crossed.