Perfect Texture Format (DDS vs TGA vs PNG)

[Argh]

Well, get back to work, and try some tests at home. I don't have an easy answer for your question, other than to say that yes, sometimes Spring is definitely fillrate-limited, depending on the scene and the overall size of the textures on the models.

Again, it's just not as simple of a tradeoff as you think it is.

Fillrate's fixed for every mip that's seen- if you have a 2048, then it's maybe 2048 here, 1024 there, 512 there and so on.

If you bring that 2048 down to 1024, then that's 1024 here, 512 there, 256 there- one-quarter of the total fillrate.

When they say cards are rated in "megapixels", well... a single 1024 at mip 0 is a megapixel, by itself.

If you have 50 characters on-screen at once, and they're all using the same skin... and they all have 1024 skins that you're seeing at mip 0, that's 50 megapixels, because that 1024 must be crawled 50 times (really it's far more than that, due to shader passes).

For just one character.

Now, imagine what I have to deal with. In World Builder, you have scenes where you routinely have 20-30 different characters on the screen, maybe multiples of them. Each one has a different skin.

That adds up, real fast. Spring doesn't really have tools to analyze that in-game, but it's definitely a factor- a larger factor than the shadowmaps. The only thing that sucks up more GPU is the fancy water shaders and the way that the map's not being sub-divided correctly for the POV right now.

[lurker]

Video cards sample from 1-few pixels for each onscreen pixel of a poly.

[Argh]

Um, the pixel shader's tessellating stuff a lot, to get things down to texels. Don't forget that.

And then there's the search time, to get the corresponding pixels for that texel. Increases with texture size.

And it's not quite "a few". Go look at screenshots of P.U.R.E.- that's not "a few", it's at least into the hundreds, if not thousands, per character.

And then there's the multiple passes, for each shader step.

[SpliFF]

That's a whole new topic.

For this discussion my conclusions to date are to use

Convienience / Development / Original file:
PNG or TGA

Units with teamcolor:
DDS(DXT3) with auto mipmaps (unless teamcolor is graduated, then DXT5)

Features / Maps / Units with no teamcolor:
DDS(DXT1) with auto mipmaps

Specular / Glow Map / Transparency:
DDS(DXT1) with auto mipmaps

I'll use a batch conversion tool like The Compressonator to generate the DDS files prior to packaging for releases.

I believe this covers everything I need except in some fringe cases like particles / sprites etc where DDS is incompatible or mipmaps overkill.

[jK]

What settings? Also you do realise there is no actual tradeoff? With 4:1 compression you can increase the size of your texture to offset the (minor) loss of color fidelity.

LOL! If it was only that simple

Fillrate becomes a problem ...

erm what? (did you even read your own link?)
Fillrate as it already says is the limit of WRITTEN bytes/pixels. Textures get FETCHED.
The impact of textures on the performance is just limited by number of texture fetches (# of used texture bindings) per written pixel, bandwidth and texture cache. So the larger a texture is the more data needs to be transfered between vram -> GPU, but if those samples follow a pattern the GPU can cache the data and reduce the readbacks a lot. And in the case of compressed textures just the compressed data is transfered and then decompressed in the texture cache. So what Spiff says is 100% true.

EDIT: PNG is not lossless in Spring - we were talking about it's nature as a file format. Talking about lossless formats in Spring is meaningless because they are being compressed and resized internally.

CompressTextures is still off by default.

And then there's the search time, to get the corresponding pixels for that texel. Increases with texture size.

ermmm computers aren't humans! computers don't `search`! lockup time is always static!!!

[Argh]

erm what? (did you even read your own link?)
Fillrate as it already says is the limit of WRITTEN bytes/pixels. Textures get FETCHED.
The impact of textures on the performance is just limited by number of texture fetches (# of used texture bindings) per written pixel, bandwidth and texture cache. So the larger a texture is the more data needs to be transfered between vram -> GPU, but if those samples follow a pattern the GPU can cache the data and reduce the readbacks a lot. And in the case of compressed textures just the compressed data is transfered and then decompressed in the texture cache. So what Spiff says is 100% true.

I think you'd better test that, first, it doesn't actually work like that- there's a reason why most of the spammed stuff in World Builder like plants have such small texture sizes, and it's not because I love pixel-painting

Basically, you're advocating the same stuff Caydr did, and he was wrong... and you're wrong, too. If you're going to see multiple textures, it gets even worse than just repeating the same guy 100 times. Try 5 or so, to see the impact a little more clearly. Make sure to use texture sizes that aren't considered reasonable, like 2048s vs 1024s, for maximum understanding. There's a serious cost for fillrate, man. And there are certainly limits, no matter how good the compression of the texture is in VRAM.

[jK]

and again you didn't read ...

[Argh]

So the larger a texture is the more data needs to be transfered between vram -> GPU, but if those samples follow a pattern the GPU can cache the data and reduce the readbacks a lot. And in the case of compressed textures just the compressed data is transfered and then decompressed in the texture cache. So what Spiff says is 100% true.

I read that, guy. Spliff's trying to peddle the idea that compression means you can have double texture resolution with no performance hit, which is wrong. There are reasons why we keep textures as small as we can, and it's not about VRAM, guys.

[SpliFF]

Argh, textures are arrays. You don't have to fetch the WHOLE texture from VRAM for every triangle painting operation because you know the texture coords (and by extension the array indexes) in advance. I serious doubt any modern GPU would fetch an entire 4M texture from VRAM when it only intends to display a few pixels of it.

At any rate you're just arguing for the sake of it. Nvidia, S3, AMD and Id say to use texture compression, so I will. I'm not going to trust you and your "fuzzy logic" over the developers of the technology in question.

For the record DDR4/5 on 256bit buses has throughput measured in 10's of Gigabytes per second. Combined with caching I still fail to see how texture fetch from VRAM will have any noticeable impact on Springs performance short of doing something really over the top (like going over the 2048x2048 'barrier').

[SwiftSpear]

fundamentally speaking... pulling an arrayed section of a texture that has doubled texture resolution is still pulling what is effectively 4 times the amount of raw data for the renderer, that's going to be more expensive.

My triangle UV'd space will contain a certain number of pixels, and on a higher resolution texture that number of pixels will be significantly larger per triangle.

Weather or not that is a bottleneck in any way shape or form to common modern video card... If it's not, probably not worth worrying about, if it is, then terrifyingly Argh would be right.

I get the sense he's chasing down all the loose tails with the hope that one of the ones he pulls will be the one that squeezes out that extra 10 FPS the players like so much. You can't really blame him for that, but if you can prove him wrong and save him some time, I'm all for it. Keep it civil though.

[SpliFF]

Oh, I'm all about civil.

Really I'm just upset that this thread turned into a discussion when I clearly asked people to provide facts. There are a bunch of previous threads full of assumptions, misinformation and guesses. I wanted to get information that fits the standard for scientific enquiry, namely:

observable
repeatable
unambiguous
understandable
measurable
backed by data

I'm seeing very little data, very little measurement, very little clear explanation. Argh isn't the only one, but invalid assumptions put forward should be examined or this whole exercise is pointless.

Argh, isn't wrong in saying there are more pixels to deal with. He MAY be wrong in saying it even matters. As far as I can tell most GPUs employ a 16k cache line when pulling texture segments so if the number of pixels doubles from 8k of data to 16k of data on the cache fetch then it's still a 16k fetch, and hence no measurable difference. It's all about knowing where to optimise.

[rattle]

I don't really understand what the problem is.


If you don't like artifacts, TGA or DDS 8888
If you don't use PS, then PNG as well.
If you don't mind artifacts, DXT3/DXT5 and DXT1

I'd never let some automated process do the conversion as you don't know what you will end up with, but I guess everything comes out as DXT5.


Either way you could read up on how other games, commercial or not, do it.

[SwiftSpear]

SpiFF: I can appreciate your frustrations. Ultimately however, you posted this thread in Art & Modelling, you're hitting alot more people who's best experience on the topic is experimentation with the engine that led to vague assumptions than you are people with any qualification in authoritatively commenting on the interaction between OpenGL and Video hardware within the context of Spring.

[SpliFF]

Fair call. Of course the issue with those assumptions is that they may be out of date, or only valid under a specific set of of conditions. Feedback from experience only goes so far, considering the variations in spring versions, hardware, unit detail, unit counts, texture type, etc, etc..

This thread did solve my problem though, and I learnt a lot more about the engine in the process.