Sign in to follow this  
Alundra

Cubemap asset : .dds is the best option ?

Recommended Posts

Hi,
I always see .dds used to import cubemap asset.
Is it the best choice for artists or using a particular layout and import .tga or other classical format is better ?
I think to generate a .dds file artists has to use the nvidia plugin for photoshop, I don't know if it's very appreciate.
Using .dds you have all the mipmaps stored, using a .tga maybe it can be an issue.
Using .tga you need one .tga for each mipmap, the .dds has all in one.
Thanks

Edited by Alundra

Share this post


Link to post
Share on other sites

If you load a "classical" format, you need to load six of them (plus mipmaps if applicable) and reassemble them into a cubemap at runtime. You also don't get the option of using a compression scheme supported by the GPU. So yes, DDS is the best option.

Share this post


Link to post
Share on other sites

You generally shouldn't use regular image formats like TGA anyway.

TGA files take up a massive amount of disk space. JPEG files have lossy quality and no alpha support. PNG files do silly things with alpha=0 pixels. JPEG and PNG have to be decoded. None of them support mipmaps. None of them support GPU-compression.

On the other hand, game textures should support optional alpha values (without losing RGB information in alpha=0 areas), should support mipmaps, and should almost always be GPU-compressed.

If you use traditional image formats, this means that when you load them, you have to decompress them, generate mipmaps, recompress them to the GPU formats (e.g. DXT5/BC3, etc) and then load them into D3D/GL/etc... which is a huge waste of time.

Your game engine's tool set should let the artists author textures in whatever formats they like (such as TGA), and automatically convent the artist's files into game-ready files, such as compressed DDS format.

Share this post


Link to post
Share on other sites

Your game engine's tool set should let the artists author textures in whatever formats they like (such as TGA), and automatically convent the artist's files into game-ready files, such as compressed DDS format.
 
I completely agree and it's what I do, the question is really about import process.
But also if we say that we also have to say : the build has to convert to another format, so the uncompressed has to be stored during the dev process.

Share this post


Link to post
Share on other sites

But also if we say that we also have to say : the build has to convert to another format, so the uncompressed has to be stored during the dev process.

Doesn't matter; the conversion is offline and the source images are not shipped with the game.


L. Spiro

Share this post


Link to post
Share on other sites

True, the issue is if you store the compressed image then you have to decompress and compress again which is a kill on the quality.

I don't know why you would do that. When you're working on the game, you either export the correct format from Photoshop, or you use a conversion step in your build that assembles the files. Sometimes people will include the ability to load generic image formats in the engine as a quick/easy testing option. When the actual game is being packaged though, you would convert everything.

Share this post


Link to post
Share on other sites

True, the issue is if you store the compressed image then you have to decompress and compress again which is a kill on the quality.

You don't "store" the compressed image.  Artists work with the source image, which may be a Photoshop .PSD, and overwrite the game assets.  In a normal pipeline you never uncompress the .DDS image except for diagnostic reasons, and this is still offline, and it does not affect the final quality.  Additionally, compressing an image to a BC* format, decompressing it, and then compressing it back to the same BC* format should always result in the same exact image as the original compression.  Once it is compressed the first time, that is the same result that any further decompressions/re-compressions should get.  It doesn't degrade the quality each time.


L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites

the question is really about import process. But also if we say that we also have to say : the build has to convert to another format, so the uncompressed has to be stored during the dev process.

So in my engine, everyone has the engine tools running on their dev PC. Artists work with files in the 'content' directory, the tool reads these files, and produces new files in the 'data' directory. The game only reads data from the data directory.
e.g.
artists ---> ./content/blah.png ---> engine tool ---> ./data/blah.dds   ---> game
You can either run the tool in manual mode, where the user has to click on a 'Compile' button in order for the content files to be compiled into data files, or, they can run it in automatic mode, where the tools will subscribe to filesystem notification events so that every time you create/modify a file, the tool will automatically compile it into the data version in the background.
Artists don't have to know that the DDS files even exist. All they need to know is -- leave the tool running in automatic mode, or, if using manual mode then click the Compile button before launching the game.

Edited by Hodgman

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