Sign in to follow this  
EmptyVoid

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

Recommended Posts

Yann L    1802
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.

Share this post


Link to post
Share on other sites
Numsgil    501
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.

Share this post


Link to post
Share on other sites
frob    44916
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.

Share this post


Link to post
Share on other sites
Numsgil    501
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.

Share this post


Link to post
Share on other sites
Yann L    1802
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]

Share this post


Link to post
Share on other sites
OrangyTang    1298
Quote:
Original post by Zipster
I don't know if I'd trust a full-blown artist to write shaders though. Shaders can truly be time-critical code if you're GPU-bound, and in my experience artists will use every single feature they possibly can to achieve a better visual effect unless you pull back on the reins a bit.

There was a presentation from Epic a while back which included how they let artists create custom shaders via a gui tool to wire together prefabbed shader fragments. This gives them a heap of flexibility without having to pester a programmer for every little change. Nearer to the end of development when the look and effects are nailed down they go back and have programmers hand-optimise any generated shaders that are too slow. This seems like a nice trade-off between artist control and performance to me (although there's obviously a big chunk of work in creating the tool for the artists in the first place).

Share this post


Link to post
Share on other sites
EmptyVoid    102
Quote:
Original post by Yann L
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]


Hey I'll have you know I'm a programmer and I know a lot about Maya. Your probably working with those kinda artist who are really stupid but are good at what they do. If your company would hire all around acknowledgeable people this would not be a issue but I guess they don't...

Share this post


Link to post
Share on other sites
frob    44916
Quote:
Original post by Numsgil
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.)
It isn't that bad.

You don't need to interpret the entire PSD file, just the parts you need. Extracting images based on layer names isn't *THAT* hard. Time consuming to write for the first time, yes, but once you've got the basic psd reading done, it's a very simple process.

Share this post


Link to post
Share on other sites
Numsgil    501
Quote:
Original post by Yann L
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.


Heh, that's... not the way things are where I work :) Not that all our artists are all that technically minded, of course, but generally they're the ones deciding on compression and resolution.

Yeah, I guess if you're insulating your artists entirely from all technical considerations, DXT compression would be included in that.

Quote:

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...


Yes, I'm familiar with this phenomenon. The trick we use here is to pull up perfhud, check which draw commands are taking too long, and ream the artist(s) responsible. It's usually the same one or two artists, and they (slowly) learn their lessons and don't do that again.

But we're a small company. In a larger project, I'm sure it quickly gets out of hand. If only the demand for artists wasn't higher than the supply, and we could afford to be picky and only pick artists with some basic technical understanding. I mean, these are real time programs. They have technical limitations. It's different from working for Pixar or doing graphic design.

Ultimately the best pipeline is where artists don't make the mistakes in the first place. Whether because they can't (but then you have to burn programmer time (which is more expensive than artist time) setting texture resolutions and shaders. And then the artists come whining to you when their model doesn't look the same in the game as it does in Max.), or because they're just smart enough not to (hard to find artists like this).

Quote:
Original post by frob
You don't need to interpret the entire PSD file, just the parts you need. Extracting images based on layer names isn't *THAT* hard. Time consuming to write for the first time, yes, but once you've got the basic psd reading done, it's a very simple process.


The problem is that most PSD readers I've seen never quite read the PSD the same way that photoshop does. Opening a PSD in Gimp, for instance, is always a pain. There's always some layer or effect that gets gimped (pun intended).

Is there a way to automate Photoshop on the command line? I could see doing something like: photoshop -convert someFile.PSD someFile.PNG

Share this post


Link to post
Share on other sites
Kylotan    9872
Quote:
Original post by EmptyVoid
Hey I'll have you know I'm a programmer and I know a lot about Maya. Your probably working with those kinda artist who are really stupid but are good at what they do. If your company would hire all around acknowledgeable people this would not be a issue but I guess they don't...

There aren't an infinite supply of people to hire, you know. ;)

Share this post


Link to post
Share on other sites
Zipster    2359
Quote:
Original post by OrangyTang
There was a presentation from Epic a while back which included how they let artists create custom shaders via a gui tool to wire together prefabbed shader fragments. This gives them a heap of flexibility without having to pester a programmer for every little change. Nearer to the end of development when the look and effects are nailed down they go back and have programmers hand-optimise any generated shaders that are too slow. This seems like a nice trade-off between artist control and performance to me (although there's obviously a big chunk of work in creating the tool for the artists in the first place).

I said I'd never let them write shaders (ala HLSL/Cg code), but I'd certainly let them design shaders using a tool similar to UE3's material editor [smile] At least that way we'd have control over the final code an be able to write optimization algorithms and hand-tweak them afterward. We almost went down that route, but like you said there's an initial cost in creating the tool that we didn't deem worth the effort. We already had all our effects from our last game and the artists were completely happy with them. Any tweaks they needed could be done in under an hour by one of the graphics programmers.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this