TextureManagers' small textures; what's up with those?

#1 Is that causing the mipmap effect?

#2 well that effect is always present in some degree or another (on sharply angled polygons at least), unless you use anisotrophic filtering..
but these 'small textures' seem to amplify the effect
so it's quite possible that without these 'small textures' it'll look a whole lot better..

Edit:
I've actually looked at the water level with and without the 'small textures' and i couldn't see any difference..
But then again, the water level isn't a good test level for that; yours would be a lot better..

#3 Thanks Sander.

I know this thread is old, but I disabled this "feature" too.

static void setSmallTexturesActive(const bool t) {/*!!*/}

It fixed a hideous blurry texture problems on some dts files with IFL materials. At first I thought there was something up with the mipmap bias.

Can anyone familiar with the code involed point out any negative effects I should be looking for?

Thanks!

#4 I am adding DDS support to TGE and this "small texture" code in the TextureManager has me confused as well.

Can someone explain what this is for?

Thanks
Todd

#5 TGE keeps small versions of textures around to save GPU memory. It means if you have a lot of objects in view at once, at a distance, you'll be using a bunch of small textures reducing cache thrashing and video memory paging. It's basically a mip-paging optimization - in essence bigger mip levels are paged out when they're not needed.

It's a pretty cool thing, and something that's finally coming into vogue with more game engines... ;)

#6 Yeah, it's a cool feature... could be a bit more flexible though ;)
The distance when the textures switch is hardcoded in Shapebase iirc, and also doesn't take the scale of the shape into account... we had the problem that the texture switch happened way too early when we scaled the models up by 2 in a mission, so I just multiplied the value with 2 * objectscale or something ;) if I find the time maybe I make that a script or prev var or something and post the changes here :)

#7 Like Dave Moore notes in his comments in the interior code, it's nothing more than eyeball code... you could assuredly do a pixel metric and get fantastically better results. :)

#8 I disagree that this is truly a cool thing in the general case. What happens if in the same view I have two instances of the same object (or even two different objects sharing the same texture) and one is near and the other far away? As far as I understand from the code, the implementation sends both the large and the small texture to the GPU, therefore increasing the cache thrashing instead of reducing it. According to the type of the game, this case might actually occur more often than the "best" case where there's only one instance of each texture in the entire level. Detecting the "worse" case looks like a nighmare to me, so at least there should be a way to manually disable this feature on an per-texture base. For the time being, I chose the simpler path to just disable the feature completely.

#9 Hmmm, good question.

#10 It's not going to thrash because they're stored in seperate texture objects. So you have some overhead in this case, but no performance loss - and the small textures are pretty small, so it's not an unreasonable cost to pay.

Always measure before you cut, to quote some advice for tailors. :)

#11 I thought the quote was... measure twice, cut once.

#12 Better once than never. ;)

#13 Fair enough!

#14 Well, I did measure before cutting. It's pretty arrogant for you to think I didn't. BTW, did you measure before writing? It might be interesting to see the numbers. In my particular case there was no advantage whatsoever with small textures and as the most typical case is the one the I described in my post, I did not see the reason to keep that "overhead" however small it may be. Anyway, the "cut" was simply to add a console variable to turn the feature on and off (barely three lines of code) so it wasn't really something that I might regret doing.

#15 You said:

Quote:
What happens if in the same view I have two instances of the same object (or even two different objects sharing the same texture) and one is near and the other far away? As far as I understand from the code, the implementation sends both the large and the small texture to the GPU, therefore increasing the cache thrashing instead of reducing it.

No thrashing occurs in this situation unless the game is already exceeding available VRAM. I have measured this code, and, in fact, it doesn't thrash, unless you are exceeding available VRAM, in which case you're in trouble anyway...

I don't think it's a bad idea to disable it, I'm just pointing out that the example you gave isn't, in my experience, something that actually happens.

Sorry if it came off as arrogant! :)

#16 I've seen zero performance change from using small textures,
after testing on several modern machines and one old clunker machine w/ a GeForce 2.

i've tried the default "dynamic" small textures, as well as forcing them always on and always off.

the scene is quite heavy, texture-wise.

as a result i've also disabled small textures as some of the early posters in this thread indicated.