Jump to content
The Dark Mod Forums

Do _editor versions really help?


Recommended Posts

So far in the effort to get all materials using _ed(itor) versions, I've done the files and folders relating to stone/brick, stone/cobblestones, wood/boards, and wood/panels. I've also done some before/after comparisons using saintlucia. I have to admit at this point, I can't see any real proof that any of this makes a difference. Is there a more definitive way (than watching task manager memory, which doesn't help much as it fluctuates based on need, and even per-application doesn't give reliable numbers if things start paging) to determine if this is really helping at all?

 

Of course, there's the issue of size/resolution. Editor versions are typically at most half-size, meaning 1/4 the area. That's an obvious savings, and there's no doubting that. But what I am getting at specifically here is, is there any difference between having a 256^2 TGA, or DDS, or JPG? Such a TGA will occupy 192kb of memory, and 192kb of HD space. Such a JPG will occupy only around 10-50kb of HD space, but still the same 192kb of memory (since it's compressed); at least, according to photoshop. DDS are assumed to be the same as JPG, just a bit better looking.

 

So does switching from TGA -> JPG (or DDS) help memory at all? Or is it just HD savings (which is good of course)? But this also comes at a quality price. Or is the only way all of this effort is going to help is:

1.) to save some HD space (over TGA), and,

2.) in the case where no current _ed version exists?

:unsure:

Link to comment
Share on other sites

As for DarkRadiant, the editor versions will help reducing the amount of graphics card memory being used for the non-lighting render mode (because they're smaller, not because of JPG vs. TGA, which is the same in memory as you pointed out). It won't make a difference for loading times, that's for sure.

 

I'd still say this work has value, because we are consistent with our texture guidelines and using less HD space.

Link to comment
Share on other sites

Sorry, I meant specifically the memory used; I assumed the loading times might even increase (due to decompression). My concern basically comes down to: in memory, a 256^2 TGA = a 256^2 JPG, correct? Because the JPG is simply compressed on HD, and then decompressed in memory; same footprint in use. Then again, maybe I still am not understanding, because then why do DDS files save Doom3's memory, when they are also just decompressed for use? And if they do help, why don't we use DDS _ed versions? :wacko:

 

Anyway, I still agree it's worth it, and I'm going forward with it. There sure are enough _ed versions missing to warrant it (please, texture artists, always include a medium quality JPG _ed version), and I like saving HD space. ;)

 

Edit: Oh I see your edit. That clears it up. Doh. :( (though DDS still confuses me... maybe I'll try some DDS _eds and see what happens)

Link to comment
Share on other sites

DarkRadiant is still passing the uncompressed bitmap data to the graphics card driver, which (I assume) is converting them to DDS, creating mipmaps and pushing it into VRAM. After this step, the memory used by the raw bitmap data is freed by DarkRadiant, and only the memory held by the graphcis card driver remains.

Link to comment
Share on other sites

in memory, a 256^2 TGA = a 256^2 JPG, correct? Because the JPG is simply compressed on HD, and then decompressed in memory; same footprint in use.

Correct.

 

Edit: Oh I see your edit. That clears it up. Doh. :( (though DDS still confuses me... maybe I'll try some DDS _eds and see what happens)

DDS files are special; they can be delivered directly to the video card as-is, without decompression. The video card decompresses them on the fly as it renders. That's the reason the format was invented in the first place.

 

Whether DarkRadiant actually uses this feature of DDS, I don't know (though I suspect maybe not); they have to be loaded in a different way to other textures (there's an OpenGL extension for it, I believe) as opposed to being decompressed in memory and delivered as raw bitmap data.

 

Doom 3 itself does load DDS properly, of course. (It can also convert non-DDS textures to DDS as part of the level load phase; note that this is Doom 3 doing the compression in memory. The graphics driver has nothing to do with the process.)

 

DarkRadiant is still passing the uncompressed bitmap data to the graphics card driver, which (I assume) is converting them to DDS, creating mipmaps and pushing it into VRAM.

The drivers don't convert textures to DDS automatically. That's why you can see a slight quality difference between raw bitmap textures (such as TGAs, or decompressed-in-memory JPGs) and DDS textures; if the former were converted to DDS automatically, then you'd see the same artefacts in either case.

 

Mipmaps typically aren't created unless you specifically ask for them, either.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Whether DarkRadiant actually uses this feature of DDS, I don't know (though I suspect maybe not);

DarkRadiant decompresses the DDS textures just as any other format, so in fact DR doesn't take advantage of the "faster" DDS loading.

 

The drivers don't convert textures to DDS automatically. That's why you can see a slight quality difference between raw bitmap textures (such as TGAs, or decompressed-in-memory JPGs) and DDS textures; if the former were converted to DDS automatically, then you'd see the same artefacts in either case.

Ah, ok. I thought the graphics cards internally operate with DDS only, and I figured the drivers convert everything to DDS therefore.

 

So, I gather that loading DDS textures actually uses less VRAM than loading TGA textures?

 

Mipmaps typically aren't created unless you specifically ask for them, either.

DarkRadiant requests the mipmap creation from the drivers, it is using the gluBuildMipMaps2D() function (or something like that, can't remember the exact name). There was a homegrown algorithm in GtkRadiant which did the same thing, but I replaced that with that specific function.

Link to comment
Share on other sites

DarkRadiant decompresses the DDS textures just as any other format, so in fact DR doesn't take advantage of the "faster" DDS loading.

Ah, ok. I thought the graphics cards internally operate with DDS only, and I figured the drivers convert everything to DDS therefore.

 

So, I gather that loading DDS textures actually uses less VRAM than loading TGA textures?

 

Yes, but only if you do pass the DDS directly to the driver - if you first uncompress the image and then move it to the driver, it eats as much as TGA :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Ok, I guess I'll look into that task sometime, so that DarkRadiant can take advantage of the DDS diffusemaps and localmaps. I've found a useful PDF describing the OpenGL routines. One needs to use the glCompressedTexImage2D to directly push DDS stuff into OpenGL instead of glTexImage2D or gluBuildMipmaps2D.

 

http://www.oldunreal.com/editing/s3tc/ARB_...compression.pdf

Link to comment
Share on other sites

Ok, I guess I'll look into that task sometime, so that DarkRadiant can take advantage of the DDS diffusemaps and localmaps. I've found a useful PDF describing the OpenGL routines. One needs to use the glCompressedTexImage2D to directly push DDS stuff into OpenGL instead of glTexImage2D or gluBuildMipmaps2D.

 

http://www.oldunreal.com/editing/s3tc/ARB_...compression.pdf

 

I guess this will make rendering in DR much faster for people with little RAM or VRAM :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Not immediately. Most editor images are still JPG, so we might actually consider to switch the _ed versions to DDS too if this is really such a performance/ram boost. Hm. SneaksieDave's recent efforts could help here to make the DDS conversion easier (via mass conversion by script). Editor images would always use DXT1, no other compression would apply for these.

Link to comment
Share on other sites

So, I gather that loading DDS textures actually uses less VRAM than loading TGA textures?
Yes, but only if you do pass the DDS directly to the driver - if you first uncompress the image and then move it to the driver, it eats as much as TGA :)

Tels is correct.

 

As a little side note, all textures in VRAM are also stored in RAM by the graphics driver, since it may become necessary to swap textures in and out of VRAM (and copying them back and forth would be slow). So a VRAM saving translates not only to potentially higher rendering performance (because you avoid thrashing), but also less system memory usage.

 

DarkRadiant requests the mipmap creation from the drivers, it is using the gluBuildMipMaps2D() function (or something like that, can't remember the exact name).

OK then. :)

 

(FYI, technically it's the GLU library which is creating the mipmaps (i.e. downsizing the big texture to various levels) in that case, before passing them on to the core OpenGL implementation. Not that it matters for application development purposes.)

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

As a little side note, all textures in VRAM are also stored in RAM by the graphics driver, since it may become necessary to swap textures in and out of VRAM (and copying them back and forth would be slow). So a VRAM saving translates not only to potentially higher rendering performance (because you avoid thrashing), but also less system memory usage.

Cool. This seems like a worthy thing to look into then.

 

(FYI, technically it's the GLU library which is creating the mipmaps (i.e. downsizing the big texture to various levels) in that case, before passing them on to the core OpenGL implementation. Not that it matters for application development purposes.)

I know, bad wording on my behalf. I was using "drivers" where I should have said "whatever bunch of OpenGL-implementing software is called on invoking the gl* methods".

Link to comment
Share on other sites

Not immediately. Most editor images are still JPG, so we might actually consider to switch the _ed versions to DDS too if this is really such a performance/ram boost. Hm. SneaksieDave's recent efforts could help here to make the DDS conversion easier (via mass conversion by script). Editor images would always use DXT1, no other compression would apply for these.

Let me understand: so my conversions to JPG right now are not wasted, because if we ever do get support to switch _ed versions to DDS, it'll just be a batch script?

 

Cool. This seems like a worthy thing to look into then.

I could make a tracker entry, if you wish?............. just so it's not overlooked...... ;)

Link to comment
Share on other sites

Let me understand: so my conversions to JPG right now are not wasted, because if we ever do get support to switch _ed versions to DDS, it'll just be a batch script?

Yes, more or less. The script could search for _ed versions and replace them with .DDS editor images.

 

But wait, we have to check one thing before going down that road: is DoomEdit able to handle DDS editor images? I faintly recall reading something about this, but I might be wrong of course.

 

I could make a tracker entry, if you wish?............. just so it's not overlooked...... ;)

Darn, I thought I could get away this time.

Link to comment
Share on other sites

:laugh:

 

But wait, we have to check one thing before going down that road: is DoomEdit able to handle DDS editor images? I faintly recall reading something about this, but I might be wrong of course.

Hm. Wasn't it that DR couldn't handle them, till you added support? I'd hope and imagine DoomEd could handle anything the game engine can.

Link to comment
Share on other sites

I guess I should still go forward with JPG versions though, since we don't know how or when DDS changes to DR will go... correct?

 

On that note, I'm actually a little excited about all of this. So far I guess it's doing little, only helping (memory) when no _ed versions existed at all previously, but I'm realizing how much entities (models and such) are a major hit to memory. Once they also use editor versions (currently, none of them do! I think) that will hopefully make a big difference. :)

Link to comment
Share on other sites

I guess I should still go forward with JPG versions though, since we don't know how or when DDS changes to DR will go... correct?

 

I'd say yes, esp. once they are defined, we can script a conversion to DDS.

 

On that note, I'm actually a little excited about all of this. So far I guess it's doing little, only helping (memory) when no _ed versions existed at all previously, but I'm realizing how much entities (models and such) are a major hit to memory. Once they also use editor versions (currently, none of them do! I think) that will hopefully make a big difference. :)

 

I am not too excited about the editor textures as most are so blurry it becomes very hard to judge the final level quality - but I guess it helps faster editing on machines with less memory, so it is nec.

 

Maybe we could add a switch "High quality textures on rendering"? Paging greebo :D

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

If you want to see the real textures, you can always switch to Lighting Mode. This will give you full diffuse, specular and normals, but of course this will be some serious impact for any system on a map like Saint Lucia.

Link to comment
Share on other sites

If you want to see the real textures, you can always switch to Lighting Mode. This will give you full diffuse, specular and normals, but of course this will be some serious impact for any system on a map like Saint Lucia.

 

Ah ok good to know. But I don't think even my system could handle SL. (Not to mention, I can't compile DR on any of my systems anymore, so editing is not possible)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Of interest, but not really surprising I guess (like repeatedly zipping a zip file): a DDS created from a 256X256 JPG is actually larger (on disk, about 2X for the one I tried) than the source JPG. So while a switch to _ed.DDS should improve performance, it might be at a small disk size cost.

 

Re: rendered mode: yep, was thinking about that (blurry textures) when trying to decide on a compression level (I went with Photoshop's definition of "medium" quality/compression). Figured it was okay because as greebo said, they have rendered mode, and, if someone has a low end system but needs the benefit of the full textures and rendered mode, they need only set up a region to work with. :) Only the full textures within that region will be loaded (please correct me if I'm wrong; this is a given, and vital for regions, and I do think it works...).

Link to comment
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.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 3 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...