Jump to content


Photo

My first map questions & work in progress

newbiequestions duh

264 replies to this topic

#51 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 11 January 2017 - 02:19 PM

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



#52 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 36372 posts

Posted 11 January 2017 - 02:51 PM

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.


  • Judith likes this

#53 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 11 January 2017 - 03:14 PM

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


#54 Arcturus

Arcturus

    Advanced Member

  • Development Role
  • PipPipPip
  • 1577 posts

Posted 11 January 2017 - 03:46 PM

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 /// CGtrader , Turbosquid


#55 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 11 January 2017 - 03:48 PM

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.


  • Bikerdude and Anderson like this

#56 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 36372 posts

Posted 11 January 2017 - 04:34 PM

 

 

 

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


  • HMart and The Outsider like this

#57 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 11 January 2017 - 06:27 PM

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.



#58 Arcturus

Arcturus

    Advanced Member

  • Development Role
  • PipPipPip
  • 1577 posts

Posted 12 January 2017 - 07:08 AM

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


  • Bikerdude likes this

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


#59 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 12 January 2017 - 07:10 AM

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



#60 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 12 January 2017 - 08:52 AM

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?



#61 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 12 January 2017 - 09:10 AM

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



#62 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7646 posts

Posted 12 January 2017 - 09:12 AM

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.c...ds/the-dark-mod

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

#63 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 12 January 2017 - 09:33 AM

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, 12 January 2017 - 09:34 AM.


#64 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 36372 posts

Posted 12 January 2017 - 09:38 AM

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.



#65 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7646 posts

Posted 12 January 2017 - 09:47 AM

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  )


  • Judith and HMart like this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#66 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 12 January 2017 - 09:55 AM

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, 12 January 2017 - 10:25 AM.

  • Bikerdude and nbohr1more like this

#67 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 532 posts

Posted 12 January 2017 - 07:52 PM

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, 12 January 2017 - 07:53 PM.


#68 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 13 January 2017 - 06:59 AM

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, 13 January 2017 - 06:59 AM.


#69 demagogue

demagogue

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 5187 posts

Posted 13 January 2017 - 09:15 AM

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

#70 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 13 January 2017 - 09:58 AM

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, 13 January 2017 - 10:38 AM.


#71 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13754 posts

Posted 13 January 2017 - 10:52 AM

@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. :(



#72 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 13 January 2017 - 12:24 PM

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.



#73 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18536 posts

Posted 13 January 2017 - 12:28 PM

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



#74 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 14 January 2017 - 04:50 AM

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.



#75 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 555 posts

Posted 14 January 2017 - 02:54 PM

I must say I'm impressed, in T3Ed one light hitting that many objects (not to mention shadow-casting) would easily bring down the framerate by half.

 

tut_2017_01_14_21_00_21.jpg


  • Springheel, Bikerdude, Anderson and 1 other like this



Reply to this topic



  


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users