Jump to content
The Dark Mod Forums
Sign in to follow this  
peter_spy

My first map – questions & work in progress

Recommended Posts

Why?

So you don't have the big task of converting all the diffuse/Specular's to .DDS before you release the map..? On a small map I agree not worth it, but surely its a good idea to get into the habit...

Share this post


Link to post
Share on other sites

Working with .dds is highly annoying since you can't preview them, can't use them in modeling programs, and can't reload them while TDM is running. Not only that, but the compression degrades the original colors every time you modify them. Converting .tga files at the end is a minor hassle by comparison.

 

There's also no rule that says you have to convert textures to .dds before releasing your mission. It's a good idea, but not a mandatory one, any more than using LOD is mandatory.

  • Like 1

Share this post


Link to post
Share on other sites

  • Working with .dds is highly annoying since you can't preview them,

Not only that, but the compression degrades the original colors every time you modify them. Converting .tga files at the end is a minor hassle by comparison.

Share this post


Link to post
Share on other sites

As Bikerdude said there are ways to preview dds on Windows and as for the modelling editors, they work in Blender at least. If I'm not mistaken using dds should improve loading times.


It's only a model... /// My channel on YouTube

Share this post


Link to post
Share on other sites

I'm actually pretty anal when it comes to my textures and materials, I do most things from scratch (no photo bases), and you can be sure that I will tweak every goddamn specular until it looks like I want it to :P

I always have large (2048) .xcf source files, at least for diffuse, and if the greyscale version doesn't translate to proper normals and spec, I keep separate files for it too, etc. etc. I don't like .dds because of the compression, because I have to choose compression according to texture type, and because Gimp is pretty slow with the compression, especially with larger files. They would probably be easier to use without compression, at least in the prototyping stage, but in my T3Ed days I had to compress them, otherwise there was nothing in the texture browser.

  • Like 2

Share this post


Link to post
Share on other sites

 

 

 

Ok, fine, you can't preview them without downloading extra software then. That doesn't change the overall point. It's irritating to work with them, and there is no positive reason to do so until the very end (if even then).

  • Like 2

Share this post


Link to post
Share on other sites

That doesn't change the overall point. It's irritating to work with them, and there is no positive reason to do so until the very end (if even then).

Which is why I said I wish we have a better image format.

Share this post


Link to post
Share on other sites

In modern editors you import images to the project and compression is done automatically.

At this point would it be even possible for this sort of function to be added/implemented in DR I wonder..

Share this post


Link to post
Share on other sites

We'd probably have to switch to map file / resource package file workflow, not sure there's any reason for that. We compress the final package anyway.

 

I'm not sure how exactly the compression (or lack thereof) influences the loading time and performance in-game, but there's only a slight difference between the DDS image with DXT1 compression, and the same image with no DXT compression zipped with LZMA method. For 1024 textures it's a difference between ~520 kb and ~660 kb.

 

So maybe we can skip the DDS compression entirely and let the pk4 packages (and the game) do the work?

Share this post


Link to post
Share on other sites

From my own experience, converting to .DDS halves the size of the FM - which I why I think why we do it.

 

We have started using .JPG for the editor images, and I wondering if we can use .JPGs for any of the others images. As its stand we have the following structure (someone correct me if I am wrong) -

 

/dds/textures/darkmod/<then a number of sub folders> and this contains the following -

  • diffuse - .DDS
  • specular - .DDS

/textures/darkmod/<then a number of sub folders> and this contains the following -

  • _ed - .JPG
  • local (bump) - .TGA
  • specular - .TGA

Typically a .DDS is a half the size or smaller than a .TGA, as the engine and DR support .JPG for the '_ed' files, is there any reason we cant us it for the others..?

Share this post


Link to post
Share on other sites

Serpentine was planning on doing something to automate compression in-engine. It seems that he hasn't had time to work on the project

in over 2 years now unfortunately.

 

Still, if the goal is to keep mission sizes down, there is no solution to the problem described here except some sort of "lossless compression".

No GPU vendor has invented such a thing so textures must remain uncompressed until they are "done" and we need to keep

the uncompressed versions around for authors who wish to make customizations.


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

DDS is smaller because TGA only has RLE compression, which is way less aggressive than DXT and doesn't have different modes for different image types. But, players download only the compressed pk4 packages and don't need to unpack them. So, the uncompressed DDS images have impact only on our hard drives, not theirs, am I right?

Edited by Judith

Share this post


Link to post
Share on other sites

As I understand it, the engine uncompresses the textures for use during play, so converting to .dds can affect the amount of visual memory needed (and possibly load times?). I've never confirmed this myself, but that seems to be the conventional wisdom.

Share this post


Link to post
Share on other sites

DDS isn't just helpful for package size. It affects how much Video RAM a mission consumes. So it is preferable that missions with custom textures

include DDS versions. Obviously you can stay uncompressed until you pack the mission.

 

Edit: Ninja'ed (sorta)

 

(Well, new AMD and Nvidia GPU's internally compress texture data so if you don't care about end-users with hardware over 1yr old you

could just ignore this issue... :D )

  • Like 2

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

As I understand it, the engine uncompresses the textures for use during play, so converting to .dds can affect the amount of visual memory needed (and possibly load times?). I've never confirmed this myself, but that seems to be the conventional wisdom.

 

I just did a quick research, actually it looks like compressed DDS textures can be handled by graphic cards in their compressed form. I've been working with this format for so long, and I didn't know that... PNGs, JPEGs and other formats need to be decompressed to their full size after being loaded in-game, obviously increasing loading times, memory usage, and demand for processing power. So, no easy way out here :)

 

Edit:

(Well, new AMD and Nvidia GPU's internally compress texture data so if you don't care about end-users with hardware over 1yr old you

could just ignore this issue... [:D] )

Yeah, on TTLG I've been harassing guys like SoulTear over how disrespectful it is to the audience, to release missions in such unoptimized state – certainly it would be a great display of me practicing what I preach ;)

Edited by Judith
  • Like 2

Share this post


Link to post
Share on other sites

At this point would it be even possible for this sort of function to be added/implemented in DR I wonder..

 

IMO no need to make DR view dds textures directly, why, IMO you should always work with the high quality .tga's on it and only at export time, to the final user, should you use .dds compression, if wanted or needed, in this way you don't destroy the original texture quality, you don't force onto others your particular .dds compression quality, some could want to use more or less compression and you could also, release the .tga's later if you want, to those that can render it fine or have the ability to download bigger files of course (like me ;) ) , plus idtech4 supports tga RLE compression, afaik at lest on textures with no alpha channel.

 

IMO what i recommend greebo or any coder willing to help him, is, include a button on DR, where you just click and it does the conversion automagically ( to cut corners could use a recommended free third party tool and you would just make a special shortcut for it on DR), it would search the game/mission texture folder find the .tga textures/folder tree, detect what type of texture it is, by using a mixture of the texture naming tag for example, _d , _s, _local, _bump and if it has alpha or not, then convert to dds using the correct dxt compression option to the particular type of texture, in the end, put them inside a dds folder respecting the original folder tree\naming.

Edited by HMart

Share this post


Link to post
Share on other sites

Even with super awesome engines like UE3 or 4 you have to choose the image / compression type for every texture you import to your package, so it's probably not so easy to make this stuff automatic.

 

On a positive note, it's either the GIMP dds plugin version (gimp-dds-win64-3.0.1) or the card drivers, because now compressing 2048 px textures is as quick and painless as with 512 and 1024 px. It took much longer on my PC when I last tried it. I might have used mipmap generation though, as default mipmapping in TDS was awful and couldn't be changed.

Edited by Judith

Share this post


Link to post
Share on other sites

Automating it would be great because I recall the converter I used had like 4 or 5 different DDS formats (I still don't really understand), and I was never sure which ones didn't work because they were the wrong format vs. the right format but, e.g., I just botched the alpha channel.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

My general approach:

 

DXT1 – RGB with 1-bit alpha, so no smooth transparency, only fence textures and the like (I often used DXT3 anyway, because the result sucked)

DXT3 – RGBA, but gradients are a big no

DXT5 – RGBA with gradients, linear and radial gradients will look fine. Irregular shapes are problematic.

DXT5n – it should be for normals, but it never worked for me. Maybe it was for ATI cards only.

Edited by Judith

Share this post


Link to post
Share on other sites

@biker

 

I did some tests with jpeg way back in the early days. The jpegs created graphic issues...I recall banding, and maybe some bad noise on the textures. The game just didn't like them. :(

Share this post


Link to post
Share on other sites

On a positive note, it's either the GIMP dds plugin version (gimp-dds-win64-3.0.1) or the card drivers,

I personally don't recommend the .DDS plugin for gimp, its created borked .DDS files or more than one occasion.

Share this post


Link to post
Share on other sites
  • DXT1 – RGB with 1-bit alpha, so no smooth transparency, only fence textures and the like (I often used DXT3 anyway, because the result sucked)
  • DXT3 – RGBA, but gradients are a big no
  • DXT5n – it should be for normals, but it never worked for me. Maybe it was for ATI cards only.
  • A lot of our decals use this, but I have never managed to get feather edges-to-alpha channel with it.
  • Almost all of our .DDS files use this.
  • Hmmm, if we could use this, and it gave a noticable reduction in size it would reduce the foot-print of the core mod nicely...

I did some tests with jpeg way back in the early days. The jpegs created graphic issues...I recall banding, and maybe some bad noise on the textures. The game just didn't like them. :(

Ah fair enough, that would explain it. I wonder if its just a coding issue though...

Share this post


Link to post
Share on other sites

I can't check whether the DX5nm compression works, because somehow DDS textures don't show when I test the map. I see them in the lightning preview in DR, but not in game. What is even more weird, when I use TGA textures for custom materials and test them in game, there's a warning in the log: "couldn't load the image", but it actually is loaded and visible.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...