Using High-res Textures In Half-life
Guspaz
Join Date: 2002-11-01 Member: 2862Members, Constellation
Join Date: 2002-11-01 Member: 2862Members, Constellation
<div class="IPBDescription">by calculating detailed textures</div> I'm trying to fork off from the general Detailed Texture thread, because it's become long, and I can't update anything remotely close to the first topic. We'll continue our discussion/work on this technique here. Just pick up from where we left off in the old thread.
<b>A quick description of the technique:</b>
There are two applications. In the first, we take a low-res Half-Life texture (The NS textures for example), and the high-res version of that same texture. We then scale the Half-Life texture up to match the size of the high-res texture, and basically reverse the method that Half-Life uses to apply detailed textures, to calculate the detailed texture, that if applied, will turn the low-res texture, into the high-res texture. In game, if your videocard doesn't support detailed textures, you don't enable them. If it does, you can set r_detailedtextures 1 and gl_max_size 512 to use the high-res textures. Hence it's completely backwards compatible.
The second application is similar to the first, except instead of using two source textures, we take a high-res texture, and calculate the low-res Half-Life texture from that. The rest is the same, except we are not using an existing half-life texture, we've generated one ourselves.
<b>Program</b>
Here it is, the first alpha version of HLTex.
To use:
Drag the low-res file into the first box, and drag the high res file into the second box. Then hit Compute. The program will then calculate a detailed texture and save the file as "output.tga" in the same folder as the application. The application saves output.tga in the format used by Half-Life for detailed textures; it's ready to use.
Notes:
The picture boxes the program displays the textures in will tile the images. Ignore it, these are purely cosmetic. All the calculations are done in memory, the entire UI is just so you know what's going on.
The program supports pretty much any input image format for the high-res texture. For the low res texture, it should support most, but it doesn't like JPEG. Since the low-res texture should be TGA, I probably won't be fixing that any time soon. It has to do with the what format the program converts the input image into for reading.
The program requires the Microsoft .NET Framework 1.1. It will not run without it. It is available through Windows Update. The package is compressed in the RAR format. Many programs can open RAR files, including WinRAR.
Please let me know of any bugs as soon as you find them by posting here. The URL is in the URL section below.
<b>URLs:</b>
<a href='http://ded.novasearch.net/guspaz/HLTex/' target='_blank'>Images of examples, and screenshots of high-res textures in-game</a>
<a href='http://www.unknownworlds.com/forums/index.php?showtopic=62384&st=0' target='_blank'>Original thread</a> Note: Our discussion is mixed in with the one on general detailed texture use
<a href='http://ded.novasearch.net/guspaz/HLTex/HLTex_1.0.rar' target='_blank'>Download HLTex 1.0</a>
<b>A quick description of the technique:</b>
There are two applications. In the first, we take a low-res Half-Life texture (The NS textures for example), and the high-res version of that same texture. We then scale the Half-Life texture up to match the size of the high-res texture, and basically reverse the method that Half-Life uses to apply detailed textures, to calculate the detailed texture, that if applied, will turn the low-res texture, into the high-res texture. In game, if your videocard doesn't support detailed textures, you don't enable them. If it does, you can set r_detailedtextures 1 and gl_max_size 512 to use the high-res textures. Hence it's completely backwards compatible.
The second application is similar to the first, except instead of using two source textures, we take a high-res texture, and calculate the low-res Half-Life texture from that. The rest is the same, except we are not using an existing half-life texture, we've generated one ourselves.
<b>Program</b>
Here it is, the first alpha version of HLTex.
To use:
Drag the low-res file into the first box, and drag the high res file into the second box. Then hit Compute. The program will then calculate a detailed texture and save the file as "output.tga" in the same folder as the application. The application saves output.tga in the format used by Half-Life for detailed textures; it's ready to use.
Notes:
The picture boxes the program displays the textures in will tile the images. Ignore it, these are purely cosmetic. All the calculations are done in memory, the entire UI is just so you know what's going on.
The program supports pretty much any input image format for the high-res texture. For the low res texture, it should support most, but it doesn't like JPEG. Since the low-res texture should be TGA, I probably won't be fixing that any time soon. It has to do with the what format the program converts the input image into for reading.
The program requires the Microsoft .NET Framework 1.1. It will not run without it. It is available through Windows Update. The package is compressed in the RAR format. Many programs can open RAR files, including WinRAR.
Please let me know of any bugs as soon as you find them by posting here. The URL is in the URL section below.
<b>URLs:</b>
<a href='http://ded.novasearch.net/guspaz/HLTex/' target='_blank'>Images of examples, and screenshots of high-res textures in-game</a>
<a href='http://www.unknownworlds.com/forums/index.php?showtopic=62384&st=0' target='_blank'>Original thread</a> Note: Our discussion is mixed in with the one on general detailed texture use
<a href='http://ded.novasearch.net/guspaz/HLTex/HLTex_1.0.rar' target='_blank'>Download HLTex 1.0</a>
Comments
People have successfully tested with more than 22 detailed textures. When we get this done, I intend to replace each and every texture on the maps, at least every texture that detailed textures can be applied to.
There's not that big an advantage to applying a 256x256 detailed texture to a 256x256 texture. Best you can do is use the technique we're working on to simulate a 24-bit texture (Half-Life uses 8-bit indexed textures). The real benefit comes from increasing the resolution.
Yes, we're really going to be taking advantage of extra texture memory. If every texture is doubled in verticle and horizontal resolution, we'll be seeing something like 70MB texture usage on top of the existing 4MB of textures. WolfWings said that compression will nail that down up to 4:1 though... but then again, on some of the smaller textures, nothing stopping us from doing more than 2x each axis resolution.....
why can't we just ask Valve to add a 24bit texture mode that when activated substitutes all the 8bit low res textures with 24bit high res versions.
btw i heard a long time ago that the X-box version of Condition Zero uses truecolor textures while the PC version does not. most probably coz of one of those dirty deals like with Halo.
Whining about it isn't going to fix it, instead we've chosen to do something about it.
Applying 512x512 'detail' textures to 256x256 textures only gives <b>four</b> times the pixel-count. So 4MB of textures is only raised to 16MB of detail textures, or 20MB total. This is why I've been asking for you to try applying a 512x512 'detail' to a 128x128 texture, as that would increase the pixel-count of the texture by <b><i>sixteen</i></b>, allowing for full use of video cards with 128MB or more of memory.
My thought, and what I originally posted with my example images, was to apply 512x512 'details' to 128x128 textures, so there would be two 'levels' of improved detail.
One, for 32-64MB cards, would only turn on detail textures, leaving the maximum texture size at 256x256, quadrupling the texture usage by the level on top of the original texture usage of the level to approximately 20MB, not counting models and so-forth.
The 'best' setting, increasing gl_max_size to 512, would increase texture usage to a nicely-large 68MB (64MB detail+4MB base) for the level itself, approximately. Again, this does not include texture usage by models and so-forth. This would suit the 128-256MB cards, or the 32-64MB cards with 4:1 texture compression enabled.
Also, a bit more detail on texture compression... NVidia has a very poor implementation of DXT1, which is why they so badly blunder on, for instance, Q3A's skies when it's enabled. Other cards running in the same mode, like my Kyro, or an original S3 card, or ATI cards, perform DXT1 with more accuracy, resulting in a far less 'banded' sky than NVidia's DXT1 implementation.
Yes, the post by ViPr has annoyed me. And yes, I expect this to annoy ViPr most likely, but I need to correct these outlandish errors and incorrect facts.
<!--QuoteBegin-ViPr+Apr 20 2004, 05:04 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ViPr @ Apr 20 2004, 05:04 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->hahaha this is so retarded that we have to use this technique that uses more memory and is slower and harder to do when Valve could just change one little thing in their code to do all this the proper way.
why can't we just ask Valve to add a 24bit texture mode that when activated substitutes all the 8bit low res textures with 24bit high res versions.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
No, Valve could not just 'enable' 24bit textures, as that would break the software-mode rendering, which Half-Life still supports after all these years. No, they can't break that support, there are still people that rely on it, and play the game with it. And on top of that, they'd have to change the format textures are stored in, and the texture loading and management code to deal with the new memory requirements for textures of different types even more, etc, etc. It's a <b>lot</b> more than 'one little thing in their code' they'd have to change, ViPr.
<!--QuoteBegin-ViPr+Apr 20 2004, 05:04 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ViPr @ Apr 20 2004, 05:04 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->btw i heard a long time ago that the X-box version of Condition Zero uses truecolor textures while the PC version does not. most probably coz of one of those dirty deals like with Halo.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
No, it's no kind of 'dirty deal' like with Halo, ViPr. They don't have to worry about backwards compatability with older versions, or even support for existing and well-liked modifications to the game with the XBox version. In fact, they don't even have to worry about custom maps, so they don't have to worry about keeping the same textures as before.
So, they took the original 24-bit source textures they made the Half-Life textures from in the first place, and used those directly instead of being stuck with 8-bit palletized textures and all the chaos that entails. Because they don't have, or need to support, a software renderer on XBox.
And that concludes this <i>exciting</i> episode of 'Interview with Captain Obvious' folks! Tune in next time! <!--emo&::marine::--><img src='http://www.unknownworlds.com/forums/html//emoticons/marine.gif' border='0' style='vertical-align:middle' alt='marine.gif' /><!--endemo-->
Guspaz has shown us that this detail system works but what does that mean for the rest of us?
Do the NS and NS2 wads need to be reworked?
Do we convince some lucky individuals to go through those wad files and create detail textures for each?
Will mappers need to do anything extraordinary to utilize this system?
Are the mentioned config file changes/additions the only adjustments that clients need to make?
And, of course, how long until I'll be playing NS using this detail system?
So pretty much all that needs to happen is for Guspaz to get his hands on the original textures <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Applying 512x512 'detail' textures to 256x256 textures only gives four times the pixel-count. So 4MB of textures is only raised to 16MB of detail textures, or 20MB total.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Don't forget that they have 3 times the bit depth and that they have a series of mip maps so that would be a fair bit more than 20 MB.
Certainly, for small and important textures you should probably use 512x512.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Do the NS and NS2 wads need to be reworked?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->No, but they need to be worked OVER. The WAD files will not change, but we will need to extract the textures from them for processing.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Do we convince some lucky individuals to go through those wad files and create detail textures for each?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->Yep. Once I get the originals from somebody I'll do them all. Right now I've only requested one of the originals for testing, if all goes well I'll request them all.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Will mappers need to do anything extraordinary to utilize this system?
Are the mentioned config file changes/additions the only adjustments that clients need to make?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->If they're using their own textures, they'll have to convert them to the detailed textures. Right now the program's prototype is drag-and-drop. Drag on the Half-Life texture, drag on the high-res texture, hit "Compute", and it spits out a detailed texture. If they're using only NS.WAD or NS2.WAD textures, hopefully all they'd have to do is make a ns_mapname_detail.txt file containing the names of textures to apply detailed textures to. Somebody will probably make a program to do this eventually.
As for clients PLAYING, they need to do two things. Copy the new files (see SoylentGreen's detailed texture pack for an example of installing them.) That's drag-and-drop. And then yes, two cvars change, you set gl_max_size 512 and r_detailedtextures 1.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->And, of course, how long until I'll be playing NS using this detail system?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->Some time after I get all the detailed textures and convert them all, and then package an add-on and post it. Ideally, I'd get all the high-res textures, convert them all, make the add-on, and then Flayra The Almighty will decide to include it with NS as standard <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
That's more or less the plan, convert the two main WAD files. I don't intend to pester every single official mapper for their custom texture sources.
Still no response from SquealLikeAPig, time to email Flayra.
A quick update on the program. After messing around trying to fix (Get around) a single bug in the .NET framework on loading images for 2 hours, I managed to get around it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
The program now pretty much supports any image format as input, though TGA is expected to be the low-res source. But the high-res can be anything, basically.
Odd-shaped textures (128x256?) should work now, though I haven't tested yet.
In other words, bugs nonwithstanding, I have a working prototype, that with a bit of testing tonight, may get posted, unless a bug crops up. The posted version is sure to be buggy as hell, but hey, that's what public beta testing is for <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
We need the original textures from the creators because they are the high-res version?
And the existing .wad textures (NS and NS2) are the low-res textures?
Then this program combines the 2 for a detail texture which will get packaged and assigned with a detail.txt file?
Just trying to put this all in dunder-head language <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
We need the original textures from the creators because they are the high-res version?
And the existing .wad textures (NS and NS2) are the low-res textures?
Then this program combines the 2 for a detail texture which will get packaged and assigned with a detail.txt file?
Just trying to put this all in dunder-head language <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Got it in one, ya' dunderhead. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
In short, bingo, you're right, nailed it on the head, drove it home with one punch, zeroed in on the truth... you are officially... <b>C</b>aptain <b>O</b>bvious now. <!--emo&::marine::--><img src='http://www.unknownworlds.com/forums/html//emoticons/marine.gif' border='0' style='vertical-align:middle' alt='marine.gif' /><!--endemo--> Wear the badge with pride, as it's honestly a compliment. =^.^=
Applying 512x512 'detail' textures to 256x256 textures only gives four times the pixel-count. So 4MB of textures is only raised to 16MB of detail textures, or 20MB total.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->Don't forget that they have 3 times the bit depth and that they have a series of mip maps so that would be a fair bit more than 20 MB.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The thing is... the <b>existing</b> textures also get converted to the same mode as the new 'detail' textures on most modern video cards, because most modern video cards don't bother with palletized (8-bit) texture support.
So a 256x256x8-bit texture ends up taking the same amount of memory on the video-card as a 256x256x32-bit texture, generally speaking, so you can ignore the bit-depth of a texture entirely.
There are some exceptions with older cards, but with the 'newer' cards that would support detail textures anyways, they usually just support 'true colour' textures and automatically convert older 'palletized' textures to 'true colour' textures in the driver on uploading the texture to the video card.
You are right about one thing though, my math is a little off. '4MB' of textures is actually '16MB' of textures for the video-card to deal with, or '8MB' if the video card stores everything in 16-bit mode. (Which many can do as an option.) 20MB of textures is actually 80MB of textures (uncompressed size), or 40MB in 16-bit mode. And 68MB of textures is actually 272MB of textuers, or 136MB in 16-bit mode.
Amusingly, if you enable texture compression, my original size-quotes are accurate, however. So, my original estimates are still valid, but with texture compression enabled. An oversight on my part, though the original 'size comparison' was still valid. 256x256->512x512 textures only quadruples (4x) the pixel count, while 128x128->512x512 sextentuples (16x) the pixel count, raising the 'effective' texture-data limit in a level to 16MB for the 4x case, or 64MB for the 16x case.
The advantage of going with the 16x case, is that that case can be 'converted down' to the 4x case by only enabling detail textures without enabling the highest-resolution detail textures, so it's the best of both worlds. :-)
Back to the issue at hand, I've received a response from Flayra. He said he thinks that Cory created the textures at the final res, but he was CCing my message to him in case this isn't the case. So it looks like the existing NS maps may be stuck at low-res.
If this is in fact the case, the technique will still be usefull for mappers who do some of their own textures, or for new mods that haven't done their art yet.
And who knows, maybe there'll be an NS3.wad one day <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
I'll quote Flayra's whole mail here:
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Hey Adam,
Wow, that looks fantastic. Unfortunately, I don't think Cory made the
textures at high-resolution, he authored them at the desired resolution.
I'm CCing Cory on this to be sure, but I'd be surprised otherwise. You
just lose too much control when you scale images down, so I'm sure he
believes he can get better results when working at the desired
resolution.
Does that leave you out of luck? If you get your work to the point
where players can just install new .wads and turn on a variable, I'd be
happy to look into including it in the installer as an option.
Charlie Cleveland
Game designer and programmer
Unknown Worlds Entertainment
<a href='http://www.unknownworlds.com' target='_blank'>http://www.unknownworlds.com</a><!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Painful, manual labour. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
There's still a way to do this. It's just going to take a *LOT* more work.
You can actually hand-edit a 'detail' texture, it's just rather complicated.
Specifically, you can set up a stack of layers in PhotoShop or equivilant to let you 'create' a detail texture manually. If we can't get high-res 'source' textures (which would honestly surprise me, from what I've heard most artists work at 2x2 up to 8x8 the 'final' resolution, then downscale, especially for models and the like), the detail textures would have to be hand-created using the following technique:
Load the texture to improve into PhotoShop/GIMP.
Upscale it, as for normal 'detail texture' creation.
Create a new layer at the top of the stack. Fill it with 50% grey, and set it to Multiply.
Create a new layer at the top of the stack. Set it to Multiply. This is the 'detail' layer.
Create a new layer at the top of the stack. Fill it with 50% grey, and set it to Divide.
Now, edit the 'detail' layer all you want, until the image with all bits turned on looks right, and you have your 'detail' texture. But, as you can tell... this would take forever compared to just having the high-res textures and being able to just re-use them.
I got a response from Cory. He did all the textures at their final res.
I'll email him back requesting that he consider us if he ever does an NS3.wad. In the mean time, let's continue developping this technique for use in future NS maps that have custom textures, and other mods entirely. Don't let this get you down, while we won't be seeing high-res NS, there's just as much promise for this technique as there was before.
I'd say the easiest way now to get high-res textures into NS is for somebody to make maps using entirely custom/premade textures. There are a LOT of free high-res textures out there, such as the one I used to demo this, from evillair (I think WolfWings gave me the URL for that... evillair.net or something?). IANAM (I Am Not A Mapper), but if somebody is starting a new map altogether, it's something to consider.
I had no time to work on the program today. Tommorow I hope to do some testing and post an alpha/beta version.
If I had been five minutes earlier.....
Sure, I'd love to be part of the team.