Why do game companies use custom texture formats instead of the DDS format?

Started by
84 comments, last by Zipster 15 years, 7 months ago
Quote:Original post by Numsgil
Hmm, interesting. Are there any utilities floating around the intraweb that do this (that is, plug in a texture in PNG or something and a desired compression, and get back some sort of score for quality)? Or is this the sort of thing that everyone rolls their own for?
There is an astounding body of research on the subject, but actual tools seem in short supply. The only one I am aware of is for video.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement
Quote:Original post by swiftcoder
Quote:Original post by Numsgil
Hmm, interesting. Are there any utilities floating around the intraweb that do this (that is, plug in a texture in PNG or something and a desired compression, and get back some sort of score for quality)? Or is this the sort of thing that everyone rolls their own for?
There is an astounding body of research on the subject, but actual tools seem in short supply.
A few high-end numeric algorithms libraries, many computer vision libraries, and most commercial image processing toolkits all include image fidelity computations.

I don't know of any that are free, but I know of an in-house version that works well for us. A quick Google search shows quite a few commercial libraries, and looking at a few shows them around $500 per license, or "call for details" pricing. If you are interested in doing this, finding a professional computer vision or image processing library shouldn't be too hard.

Even if you do use some of the computer vision or image processing libraries, image fidelity metrics are not a single number, nor are they generic "plug in your image files engine and get a magical number" systems. They require actual work on your own tool using your own knowledge of what heuristics to use and how to intelligently compare the fidelity metrics.
Quote:Original post by frob
I don't know of any that are free, but I know of an in-house version that works well for us. A quick Google search shows quite a few commercial libraries, and looking at a few shows them around $500 per license, or "call for details" pricing. If you are interested in doing this, finding a professional computer vision or image processing library shouldn't be too hard.

Even if you do use some of the computer vision or image processing libraries, image fidelity metrics are not a single number, nor are they generic "plug in your image files engine and get a magical number" systems. They require actual work on your own tool using your own knowledge of what heuristics to use and how to intelligently compare the fidelity metrics.


Right now our artists export images from photoshop using a free DDS plugin from NVidia, choosing what format to use (DXT1, 3, 5 or uncompressed mostly). If there was a way to have a tool decide intelligently when to compress and when not to, that'd free up some work for our artists. Which would be a good thing. Not something I think we'd want to spend a lot of money on, though.

But, back to this whole coddling artist issue, at some point it would need to come down to a magic number. And they'd still have to be able to add information like "this is far away, so quality doesn't matter" and "this is close up so quality matters" and "this is a cutout where the alpha is very important", etc. So if there is a pre-existing tool that aided the artists in choosing a format (or even was smart enough to really decide entirely by itself), I'd give it a spin. Not something I'm going to want to make myself though.

I'd also like to point out that when people say things like "don't let your artists decide, make the tools decide automatically", well, if you're tools just make everything a DXT5 because more complex analysis costs $500 plus a month of programmer labor, how's that better?
[size=2]Darwinbots - [size=2]Artificial life simulation
Quote:Original post by Numsgil
I'd also like to point out that when people say things like "don't let your artists decide, make the tools decide automatically", well, if you're tools just make everything a DXT5 because more complex analysis costs $500 plus a month of programmer labor, how's that better?

Well, you just invest the 500 and the man hours to get it up and running. This is a one time cost. The time you'll lose with artists deciding (and correcting potential errors later due to incorrect decisions) are recurring costs. And if we're talking about a commercial game title here, then $500 for a license is pocket change.
Quote:Original post by Yann L
Quote:Original post by Numsgil
I'd also like to point out that when people say things like "don't let your artists decide, make the tools decide automatically", well, if you're tools just make everything a DXT5 because more complex analysis costs $500 plus a month of programmer labor, how's that better?

Well, you just invest the 500 and the man hours to get it up and running. This is a one time cost. The time you'll lose with artists deciding (and correcting potential errors later due to incorrect decisions) are recurring costs. And if we're talking about a commercial game title here, then $500 for a license is pocket change.


I was thinking more the one programmer man month spent tweaking the heuristic. That's closer to several thousand dollars in time. For an artist, choosing which compression to use is as simple as choosing an item from a drop down box. That's an extra 5 seconds. The item chosen will be remembered for the next round of saving, so let's say something on the order of 20 seconds per texture over the project lifetime. Assuming something on the order of 2000 textures, you're talking maybe 12 hours of work over the lifetime of the project. Even adding in extra time for things like an artist figuring out that normal maps can't be DXT, it just doesn't add up as cost effective.

If there was an existing tool, I'd use it. But I can't see anyone justifying the expense of building such a tool compared with just having an artist save the file as a DDS and load it up in something like DX Texture Tool when they have problems.
[size=2]Darwinbots - [size=2]Artificial life simulation
Quote:Original post by Numsgil
I was thinking more the one programmer man month spent tweaking the heuristic. That's closer to several thousand dollars in time. For an artist, choosing which compression to use is as simple as choosing an item from a drop down box.

Well, it's not - that was the whole point. The problem is not so much selecting the option, but deciding which option to select. Many, and from personal experience I'd almost say most artists are technically unable to make such decisions without extensive technical training. Furthermore, even if they have the training, they will always decide based on personal subjective parameters and 'instict' (they're artists after all ;), which can be entirely wrong. Detecting and correcting such errors can be very time consuming and expensive.

So you can have the artists do the selection, and basically pay a dedicated technician to double check every decision they make, over the entire duration of the project. Or you assign a single developer during a few weeks on an automated system, and you're done with it. Or just outsource it to a Chinese or Indian freelancer to cut the costs.
Quote:Original post by Yann L
Quote:Original post by Numsgil
I was thinking more the one programmer man month spent tweaking the heuristic. That's closer to several thousand dollars in time. For an artist, choosing which compression to use is as simple as choosing an item from a drop down box.

Well, it's not - that was the whole point. The problem is not so much selecting the option, but deciding which option to select. Many, and from personal experience I'd almost say most artists are technically unable to make such decisions without extensive technical training. Furthermore, even if they have the training, they will always decide based on personal subjective parameters and 'instict' (they're artists after all ;), which can be entirely wrong. Detecting and correcting such errors can be very time consuming and expensive.

So you can have the artists do the selection, and basically pay a dedicated technician to double check every decision they make, over the entire duration of the project. Or you assign a single developer during a few weeks on an automated system, and you're done with it. Or just outsource it to a Chinese or Indian freelancer to cut the costs.


Well, they can't screw up the decision too bad, right? The difference between DXT1 and full 32 bits is a factor of 8. Just having the artist decide between 128x128 and 512x512 is twice that. Do your artists create their art in huge canvases of 8192x8192, feed it in to your pipeline, and have your pipeline set a more sane resolution?

And back on the DXT thing, it's pretty easy to hand wave explain it to an artist: 32 bit is normal, DXT5 is 1/4 the size with some compression artifacts (which are easy to demonstrate with actual examples), and DXT1 is half the size of DXT5 without an alpha channel. It's not a full explanation, of course, but that right there would get you correct results 80% of the time.
[size=2]Darwinbots - [size=2]Artificial life simulation
Even if the default is right 80% of the time, you could just have them export the default format. Your tool chain could simply include a list of exceptions to the default format.

This avoids the cost of developing a tool with heuristics for visual fidelity, it saves the artist some brainpower and clicking every time they manipulate an image, and it lets you make smarter choices for the 20% exceptions. If an image is too large or some other obvious issue exists, the tool could abort with an error that breaks the art build.

With that you're still allowing a human to decide the format, you're getting a mostly good default, but you'll be taking advantage of the tool to reduce the human cost and human mistakes.
Quote:Original post by frob
Even if the default is right 80% of the time, you could just have them export the default format. Your tool chain could simply include a list of exceptions to the default format.

This avoids the cost of developing a tool with heuristics for visual fidelity, it saves the artist some brainpower and clicking every time they manipulate an image, and it lets you make smarter choices for the 20% exceptions. If an image is too large or some other obvious issue exists, the tool could abort with an error that breaks the art build.

With that you're still allowing a human to decide the format, you're getting a mostly good default, but you'll be taking advantage of the tool to reduce the human cost and human mistakes.


I mean using that simple heuristic I outlined you'll get the artist to export in the right format 80% of the time. Artists can understand when something doesn't need an alpha channel and so DXT1 will work, for instance. Or when the artifacts are too much and they need a full 32 bit texture.

It's not a decision they'll have to remake every time the texture is changed. If it was DXT5 before it should probably still be DXT5. And the artists are going to save their PSDs separate from their textures for the pipeline anyway. Unless your pipeline can accept PSD files (and if it can, serious kudos to you. I looked in to it briefly but there didn't seem an easy way to do it.)

So without DDSs, the workflow looks like this: open the PSD. edit the PSD. Save as Copy-> PNG. Rename from "Copy of XXX" to "XXX". Click ok. Use a lean tool to view the final image to make sure it was saved properly (optional). Load in to game and look at it to make sure it works in the engine.

Expecting the artists to save DDS looks like this: open the PSD. edit the PSD. Save as Copy-> DDS. Rename from "Copy of XXX" to "XXX". Choose from 5 different DXT formats, or full 32 bits. Click ok. Use a lean tool to view the final image to make sure it was saved properly (optional). Load in to game and look at it to make sure it works in the engine.

So you add one extra step, which should be a trivial step. The compression was probably decided when the artist first thought about the texture. Something like: this is for grass, I can use DXT5 to keep a clean alpha, and get some memory savings. Maybe the naming convention for textures even bakes the compression right in to the name (not what I'd recommend but it'd probably work. More for Hungarian artists :) ). When she comes back to edit the texture, she hovers her mouse over the DDS next to the PSD in the appropriate levels folder and sees that it's stored as DXT5. She moves her mouse 1 inch and opens the PSD file and remembers to save it out as a DXT5. Or she forgets and a minor harm is committed.

You could store the compression method in an options file that every texture has, (or maybe a global options file where every texture is listed), but aside from being a pain for the artists, who have to make a new options file or entry every time they make a new texture, no one gets to see the compression artifacts until they're in the game. Being able to look at a texture in something like DX Texture Viewer and say "the texture is fuzzy, it's not what I'm doing with it" is so much nicer than guessing.

Now, if we could take PSD files and feed those in to the pipeline, I would be more convinced to let the tool decide on compression. Maintaining a PSD file AND a DDS file is a pain. If I could chop out that middle step of saving a copy to a DDS (or PNG or whatever) I'd accept all sorts of automation and heuristics. But as long as the artists have to save their PSD into an open format, it might as well be DDS and they might as well decide on the compression while they're at it, since that screen pops up anyway.
[size=2]Darwinbots - [size=2]Artificial life simulation
Quote:Original post by Numsgil
Do your artists create their art in huge canvases of 8192x8192, feed it in to your pipeline, and have your pipeline set a more sane resolution?

Yes, pretty much. Not 8k, but usually around 4k, and never below 2k. Our artists are not allowed to make any decision for the final texture resolution used in the 3D scene. The technical team does that.

Seriously, I don't trust an artist to do any kind of technical decision anymore. Their job is to do *artwork*. Involving them into technical issues is like letting your programmers mess around the 3D designs in Maya. I've seen senior artists using a 1024*1024 texture that had the same constant green colour in every pixel. Another one downsampled our customers coporate logo, which was given to us in 16384 resolution (!) to a 128*32 texture. He thought that the huge corporate name display above the building entrance was 'not too important'...

And it gets worse if you let them mess around with shaders. Never let your artists mess with actual shader code. Artists do not understand if you tell them 'look, we have these great new curved local reflections ! But they're quite heavy on the pipeline, so please use them sparingly and only where they're really well visible !'. Yeah, right... After two minutes, every single object in your 3D scene uses blurred curved reflections, because the artists thought they'd look better than glossy speculars...

Artists are a bit like women - they behave in strange and seemingly irrational ways, but we just can't live without them [grin]

This topic is closed to new replies.

Advertisement