Mipmapping is a trick used by game engines to reduce the load on videocards. Simply put, the further into the distance the object or model gets, the smaller the size texture is used BECAUSE all that detail is not used/seen at a great distance.
http://en.wikipedia.org/wiki/Mipmap
Mipmapping is of extreme importance in game engines like Source where squeezing the maximun amount of rendering detail into a map is essential.

There is only 1 exception that I find to this rule: First person models (v_models)

Here is the reasoning: mipmapping is for things that retreat into the distance and then get close again on your screen. A v_model never really does this. It is always at a fixed point on your screen. Okay, sure you barrel is technically farther away than the receiver, but not by that much, and certainly not the distances mipmaps were intended for. Now here is the kicker - not all video card process the mipmap genrating quite the same. What looks clear as a bell to one person looks like a blurry mess to others. However all cards process NO mipmap the same (nothing to process LOL) look at these examples



image stolen from another post ;)

NOW - How does this affects user who have their cards set on low texture setting in the options?
Well it doesn't really, unless their card is SO ancient that actually showing the entire 1024x1024 skin of the v_models cripples it. Seriously - if the card can't handle the v_model, which isn't all that far in the distance, without having to resort to blurring it to get past 24 FPS (what movies are filmed at), then they don't need to try and run this game at all.

ALL OTHER types of model (i.e. player, w_models, etc.) should have mipmapping enabled, otherwise it could cause serious performance hits on many vidcards to deal with 24 un-mipmapped player models and 24 un-mipmapped weaons.

Good post but some technical errors I need to point out ( sorry :( ).

MipMapping doesn't reduce the load on videocards, its just a visual trick used to improve the quality of a texture applied to an object in the distance of your scene. The problem with using the same resolution texture scaled down onto a distance surface is that pixels tend to produce a moiré pattern causing "jaggies" and wierd patterns to appear. You also tend to get pixels which pop out at you and appear over bright and un-natural to the human eye.

These problems can be overcome by downsampling the texture but doing it on the fly is expensive on CPU cycles. Hence MIPMaps, pre-downsampled versions of the original texture representing it at different distances from the viewer.

When a textured surface is a sufficient distance from the viewer the texture on it is replaced with the relevant MIP map. This results in a more natural appearence, removes the jaggies and better represents the way colours and details tend to blend together the further away you are.

MIPMapping doesn't save any texture memory - in fact it adds to it as the original texture plus all its MIP maps have to be loaded into texture memory for them to be used.

Regarding the No MipMap option, as you say it forces the engine to use only the largest texture of the MipMap set ensuring you see the best quality at all times.

The way I believe it works in Source (I know it works this way in other games) is that when the texture is read, if the No MipMap flag is set the engine only passes the largest texture to DirectX and tells it no mip maps exist, thus DirectX is forced to use only that texture. Otherwise, Direct X would choose the most suitable MipMap itself from the ones available in the texture.

Again, as far as I know there is no performance gain from using MipMap textures, only visual fidelity gains. Textures with No MipMaps actually give better performance as there is less texture data to transfer to the graphics engine but at the expense of visual fidelity when scaled down.

hey, don't blame me, I was just goin off the info I was reading

Rendering speed increases since the number of texture pixels ("texels") being processed can be much lower than with simple textures

But still, I gotta throw a flag on this one ;)

I quite distinctly remember the whole point of mipmapping was to reduce load, not help visual quality. Of course that was a few years ago. Modern video cards can eat ALL these hi-res textures for breakfast and not even burp - but not everyone is state-of-the-art yet!
I do agree that it also has the benifit of removing jaggies.

Yeah you are right in that it increases performance in reducing the number of pixels needed to be mapped onto the surface (say 256x256 at distance vs 1024x1024).

Being geeky me I was thinking in terms of memory/bus bandwidth performance rather than rendering speed - oh and I claim the "it was late" rule :D

These posts are great, especially for those of us "geeky" enough to find it interesting :D

An explanation of when to use 'NICE filtering would be good too. tinfoil

NICE filtering is better than simple box-filtering because it preserves high-frequency information: textures mipmapped with it look less blurry than those mipmapped with box filtering.

Correct me if I'm wrong, but mip-maps have specific cut off distances, right? That's what I always seem to notice anyway, a big line where the texture just blurries up...and that's what I don't like. Is there a different system with a more gradual transition? Or could one just increase the number of mip-levels, and make the transition distances closer together and thus more fluid?

Just tossing thoughts out there. Like I said, one thing I noticed with the defaults is that there seems to be just this big chunk where the blur sets in. But then on Gen's BAR you've kind of got a shimmer/jaggy effect on the foregrip going on because the resolution is almost too high. Tried turning off the "No Mipmaps" flag but it just looked too blurry. Needs to be a happy-medium solution!

Woah, just took a look at the generate mipmap options in VTFEdit and there are tons of them... Anyone actually know what kind of difference they make?

Originally posted by bazooka
Correct me if I'm wrong, but mip-maps have specific cut off distances, right? That's what I always seem to notice anyway, a big line where the texture just blurries up...and that's what I don't like. Is there a different system with a more gradual transition? Or could one just increase the number of mip-levels, and make the transition distances closer together and thus more fluid?


I believe that is what Anisotropic filtering does? Not sure though.

Originally posted by bazooka
That's what I always seem to notice anyway, a big line where the texture just blurries up...

an excerpt from my original post ;)
"not all video card process the mipmap genrating quite the same."

Originally posted by bazooka
But then on Gen's BAR you've kind of got a shimmer/jaggy effect on the foregrip going on because the resolution is almost too high. Tried turning off the "No Mipmaps" flag but it just looked too blurry. Needs to be a happy-medium solution!

Not to get TOO off-topic, but this actually dips into another post where I stated my reasoning for why 2048x2048 is too high a resolution for almost all first person (v_models) uses, 2 exceptions being the Garand and K98 because those actually DO get close enough to the screen (in iron-sights mode) to see the extra detail. Even on my custom player models, which are 2048x2048, you will NEVER really see the extra detail while playing, you most only catch brief glimpses of that extra detail while in spectator or death-cam, because the camera sometimes gets REAL close.

(I'm gonna get hung for this) If you are having problem getting acceptable video quality from the 2048x2048 custom v_model skins, do what I've been doing - open them up, re-size them to 1024x1024, sharpen them and them re-save them as VTF and include anistropic filtering and no mipmapping. Technically the "nice filter" would not be necessary as that refers to they way the smallr mipmaps are generated, and you have checked off "no mipmaps"

I've done the same thing with my BAR skin, I just havn't updated the release :vader:.