Mip Level Control

[Argh]

Basically, I think that Spring needs a feature that will allow users to force Spring to discard lower-level (larger) mip levels, and send a version of a mip'd texture that is missing the lower levels.

This would allow older hardware to play newer games. It'll be ugly, but it's better than nothing. The textures would have to be rebuilt, of course, and there would need to be a change in SpringSettings to allow this to happen.

Currently, the Setting value that changes which level is seen at which point works. But it doesn't really truncate the texture in VRAM, so it's of limited worth, when looking at serious performance problems. Since Spring's already making mips for textures, 90% or so of the code is already there- if TextureLevel > 0, discard any mip < TextureLevel, or whatever, and only keep the final resulting mip'd texturemap.

I don't have any other good solutions for this. Most commercial games do this, and have a "texture quality" setting, that's effectively doing exactly what I'm saying here. It's about the only way to make some games playable on older hardware, and I think Spring needs it as well.

[smoth]

discard lower levels... argh you do realize the maps are made of 10s of 1000s of tiles all of which are mipped and if we discard the lower levels they will have serious memory bloat right?

[lurker]

Memory bloat where? I don't follow.

[smoth]

I don't understand why he wants to remove the lower levels, if the machines are slower and have less memory, you would do better by reducing to one of those lower levels. Say you have a 1024, most of the time at medium distance you are at mip 2 already, if you remove the lower level mips at a distance they will not be able to go lower and render less.

Maybe I used the wrong term. Seems like he wants detail control which seems like it would be covered by using the lower mips sooner.

[lurker]

When argh says lower he means "less mipped." He wants to entirely throw out the full-sized level(s) based on a setting.

[smoth]

how can he, the dds it's self has to be loaded to access, the way dds works is it is all tossed into memory correct? As far as I know you cannot tell it load part of a dds.

[lurker]

Load it into ram, build a smaller texture from it, discard the original, only send the smaller texture off to opengl for later use.
It might be possible to build the smaller texture losslessly and without recalculating by pulling the mips out of the dds, it might not.

[imbaczek]

so you want something like r_picmip in q3/quakelive?

[lurker]

Yeah, pretty much.
http://www.planetquake3.net/tweak/bench ... shots.html

But 1. Does that setting change what is loaded or just the bias? 2. If it changes the bias, does that do as much as changing the textures themselves?

[imbaczek]

then let's just steal the appropriate code from ioquake3/challengeq3, it's opengl and GPL.

[smoth]

that would be pretty cool. Also q3 does not use dds iirc.

[lurker]

Well, looking at the image more and turning my brain on it's clear it's not just changing the bias, so time to open it up and see how it works.

[smoth]

it could be the mip that is like 1 pixel.

[Argh]

Hopefully it's not just adjusting bias, that would not help with this issue.

[imbaczek]

r_picmip cannot be changed live, it needs a vid_restart which does a full reload of all content. that would mean it does quite some work before displaying anything.