Darkradiant Dds Support

[greebo]

Currently, RXGB compressed normalmaps are not supported. The warning Orbweaver has implemented works fine, so DarkRadiant at least knows what it encountered.

 

I've searched a bit on the web and found that the DevIL library is capable of loading RXGB normals, so I downloaded the source and took a brief look. There is a lot of bit-shifting going on, but I think that I can wrap my head around it if I bite into that.

 

Question is: should we extract the relevant part from the DevIL sources (given that is possible) and move them into our codebase or should we link against the DevIL libraries themselves and incorporate the headers into DarkRadiant? I don't know how platform-independent DevIL is, so we would have to check that.

 

Opinions?

[OrbWeaver]

The best thing to do is to use the DevIL library as a source of the format information, then document this and re-implement it in the existing libdds library if possible. The coding is not the difficult part, it is figuring out how the format needs to be processed -- once this is done, the transformation into code is pretty easy (even if it is C rather than C++).

 

Fortunately it appears that DevIL is also (L)GPL, so if it does become necessary to lift source code this should be legal.

[greebo]

Ok, I'll try to extract the relevant information then. It's not so much different to DXT5, the two colour fields have to be preprocessed a bit, as far as I can see now.

 

I'll post back here what I find.

[sparhawk]

DevIL is platform independent IMO, and considering that we already use it for the main mod as well, why would you reimplement the same code again? Anybody who has the mode, you can be sure that DevIL is already installed, so you can be sure that DR would work with it.

[OrbWeaver]

DevIL is platform independent IMO, and considering that we already use it for the main mod as well, why would you reimplement the same code again?

 

Because there is already a DDS library which has a switch statement to deal with the existing formats, and adding a new function to cope with RXGB is easier than trying to farm out that one format to yet another library, dealing with all of the linker and interface issues that would arise.

 

Of course it might be possible to completely replace the DDS library with calls to DevIL, but it isn't broken so fixing it is hardly a priority.

[Crispy]

It may be less work (and cause less disruption) than ripping out libdds and replacing it with DevIL. You could just add DevIL without replacing libdds and use it for the RXGB format only, but having two image-loading libraries co-existing seems a bit messy and redundant.

 

On the other hand, I guess DevIL loads more image formats than libdds does, so maybe it would be nice to have it... but on the other other hand, Doom 3 doesn't necessarily support all those formats and there's not much point having the level editor able to support a format when the game doesn't.

 

It sounds like it shouldn't be too hard to re-implement anyway - it's just fiddling with the layout of the colour values, right?

 

Edit: Orb beat me to it.

[greebo]

Heh, that's nice: compare this comment in ddslib.c (DarkRadiant):

/* four-color block: derive the other two colors.	
  00 = color 0, 01 = color 1, 10 = color 2, 11 = color 3
  these two bit codes correspond to the 2-bit fields 
  stored in the 64-bit block. */

to this one (DevIL):

// Four-color block: derive the other two colors.	
// 00 = color_0, 01 = color_1, 10 = color_2, 11 = color_3
// These 2-bit codes correspond to the 2-bit fields 
// stored in the 64-bit block.

[sparhawk]

Seems there was already somebody doing this. Anyway, you can also use DevIL to convert between image formats, so even if D3 would not support something DR could with this lib.

[greebo]

From what I can say so far, DarkRadiant's ddslib is a bit better structured than the DevIL source. And I think I found a bug in the Radiant's ordinary DXT5 decompression code as well (could stem from copy&paste from what it looks), although I don't know if it's noticeable as it would only affect one single bit.

[New Horizon]

Just to chime in. It's definitely better for DR to process this info on its own...without having to install the DevIL. Dark Radiant has the potential to be used for straight out doom 3 mapping, so it wouldn't be good to require the Devil.dll library.

[greebo]

Ok, I think I figured it out, but I need to test it. From viewing at the texture (I used the normalmap as diffusemap to inspect the result) it seems to be ok.

 

This is what DarkRadiant "saw" before:

 

And this after my changes:

 

So far I tested it just with one single DDS encoded with ATI's compressonator (R:0 G: 0.5, B: 0.5, the usual procedure).

[OrbWeaver]

That looks about right. I suggest creating some RXGB images with just 100% red, 100% green and 100% blue and making sure they come out OK. If so, you are probably reading the correct bit patterns.

[New Horizon]

Word. Looks promising.

[greebo]

Just tested it and took two identical screenshots, one with TGA one with DDS:

 

DDS:

 

TGA:

 

And I substracted the DDS shot from the TGA shot and this what comes out:

 

Looks good.

[OrbWeaver]

Looks good -- if you want to be really thorough, try a colour wheel or gradient (you will of course get compression artefacts).

[SneaksieDave]

It sounds like this is well on it's way to being implemented (woot). I'm not sure if it's a matter of hours or weeks though, so a question - until it is fully implemented, is there currently a way to tell DR *not* to attempt to use DDRs at all? I don't know what if anything has changed recently (and fully expect to be called crazy for this) but suddenly I notice that textures I've used over the past months (e.g., masonry_brick_001) - in DR, without problem, in render mode - suddenly (I don't know 'as of when' exactly, but it worked when I was texturing my map with the new DR texture tools) have no/broken normals in DR. As soon as I delete the DDR files, they look fine again (because then DR goes to the TGAs instead).

 

Since updating SVN will keep giving me the DDS' back, this isn't really a great option though, so I'm wondering if I can tell DR to just not use DDS at all, for now. If on the other hand, this is working as fast as it looks like it is, nevermind!

[greebo]

At the moment I think I'm finished with the DDS stuff, as it seems to work. Regular use will show if there are any issues left.

 

It is theoretically possible to force DarkRadiant not to use DDS textures, but what's the point if Doom3 is loading the textures anyway?

[SneaksieDave]

Right, it was just for the presumed interim. Now that I have SVN, I have all the DDS files (I used to delete/not get them on CVS), so I'm seeing this problem. Took me a while to figure that minor mystery out.

 

If your fixes for DDS support are already in and coming soon, then this isn't an issue (hoping it works for me, of course).