Speaking of 24-bit textures... I've got a working version of the program. It's not quite ready to post though, maybe tommorow. Right now it's too restrictive into what it will accept as input, and is making some assumptions that have to be detected rather than assumed. I'll post a few screenshots before I post the program, though, I think.
you wanted 24bit color textures in the HL engine and the detail textures are 24bit color?! then why not use the detail textures only then and forget the base textures, or swap the roles of the detail and base textures.
<!--QuoteBegin-ViPr+Apr 18 2004, 09:22 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ViPr @ Apr 18 2004, 09:22 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> you wanted 24bit color textures in the HL engine and the detail textures are 24bit color?! then why not use the detail textures only then and forget the base textures, or swap the roles of the detail and base textures. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> what will the people with med to low graphics cards see?
<!--QuoteBegin-ViPr+Apr 18 2004, 10:22 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ViPr @ Apr 18 2004, 10:22 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> you wanted 24bit color textures in the HL engine and the detail textures are 24bit color?! then why not use the detail textures only then and forget the base textures, or swap the roles of the detail and base textures. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> This is impossible, there is no way given to do this. And even if there were, that wouldn't allow high-res textures to be used.
The beauty of this method is that people with old videocard see regular textures, those who have relatively modern ones simply change a single cvar and they see high-depth high-res textures. IE, totally backwards compatible.
actually it wouldn't work coz the radiosity calculations use the base texture colors don't they? and also, the res of the lightmaps is affected by the loopage of the base textures isn't it?
bah, it's so annoying that they won't allow true-color base textures. i'm gonna write my own game engine for NS, then we won't have any of these restrictions.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Actually I hadn't planned on integrating WAD support. I haven't seen any detail texture packs yet that use WAD files, so I was simply going to spit out TGA files. Though I guess, if it's supported and desired I might end up doing it, though I have no knowledge of the WAD file format (I'm sure it's documented somewhere).<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Actually, by 'detail/.wad editor' I meant something like Wally, that could have a directory of high-resolution files loaded, and would automatically generate a .wad and a directory of .tga files for the detail textures.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->The idea was to support bulk conversions, to do an entire map in short order. Of course, maps tend to store all their textures in WAD files... I might have to extract them I suppose.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Not really, as you can't go from just the Half-Life texture to the high-res or a true 'detail' texture to improve the texture to 24-bit even. The information you're trying to add simply isn't there to extract in the first place. It was lost when the Half-Life texture was scaled down and converted to an 8-bit image.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Speaking of downscaling, I'm not sure where that comes in. We take the original texture and upscale it, and then produce the output... where am I supposed to be downscaling?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
From the high-resolution 'original' texture down to the Half-Life texture. Then reduce the Half-Life texture to 8-bit mode. Then make a COPY that is converted back to 24-bit mode. Then upscale that copy back to the original size. Then create the 'detail' texture by comparing that upscaled version and the original texture.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Unless there are any hitches, I should have a prototype version that does one texture at a time up sometime today.
EDIT: Damn, it's so hard to find an image to work on while poking around in my pictures folder <!--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 have to photoshop up a texture that mimmicks a highres/halflife pair.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Check <a href='http://www.evillair.net' target='_blank'>EvilLair.net</a> for a good source of high-res textures to work with, possibly.
<!--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-->Not really, as you can't go from just the Half-Life texture to the high-res or a true 'detail' texture to improve the texture to 24-bit even. The information you're trying to add simply isn't there to extract in the first place. It was lost when the Half-Life texture was scaled down and converted to an 8-bit image.
From the high-resolution 'original' texture down to the Half-Life texture. Then reduce the Half-Life texture to 8-bit mode. Then make a COPY that is converted back to 24-bit mode. Then upscale that copy back to the original size. Then create the 'detail' texture by comparing that upscaled version and the original texture.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You misunderstand me. I'm taking two sources, the Half-Life texture, and the high-res 24-bit version of that texture, converting and scaling up the Half-Life texture, and then producing the detailed texture.
I'm talking about converting EXISTING Half-Life textures by getting the original high-res versions from Squeal-Like-A-Pig.
I emailed him last night about sending me the high-res original version of floor_diamond, hopefully by the time I'm ready to start testing in-game he'll have sent it to me.
Right now I have it producing TGA outputs, the two things left to a working protype are converting the input to the expected format, and then some cleaning up to handle various exceptions that might occure. It's so easy to break the program now by providing non-expected input <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
<!--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--> Actually, by 'detail/.wad editor' I meant something like Wally, that could have a directory of high-resolution files loaded, and would automatically generate a .wad and a directory of .tga files for the detail textures.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> I'm aiming to convert existing Half-Life textures that we have access to the 24-bit source, since my eventual goal is to use the program to create detailed textures for all the in-game NS textures. A requirement of that is to NOT modify the existing 8-bit textures.
It would be trivial, though, due to my use of ImageMagick, to add support for only one input image, the 24-bit image, and then to produce two TGAs, one in-game version, and one detail version. But that's not really the focus of this program.
It occures to me that it's possible to specify ANY high-res texture to be applied on top of the half-life texture. Theoretically, if you don't have a high-res version of an in-game texture, you can just make one.
Yes, by being a different texture, you'd have a lot less accurate output (Harder to get exactly to the desired channel values), but it'd probably work pretty good. I'll run some tests.
<!--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-->Check EvilLair.net for a good source of high-res textures to work with, possibly.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> I ended up taking the standard 24-bit Lena image (convieniently 512x512), and to simulate the Half-Life texture, converted it to a 64-color (To increase the banding to make it more apparent) 256x256. The output looks pretty much what it should be, I'm at school now but when I get home I'll post an image.
<!--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-->I emailed him last night about sending me the high-res original version of floor_diamond, hopefully by the time I'm ready to start testing in-game he'll have sent it to me. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Thank You! My problem was that I didn't/couldn't make a higher res version. I mean, I can do things with filters but with floor diamond it didn't look good and getting it to tile with anything but 1:1 never worked quite right (due to color changes across the texture, a little bit of shading).
I did a bit of experimenting on using completely different low-res and high-res textures for the detail texture. Using the Lena image as a low-res base, and one of EvilLair's mostly gray textures.
Simulating the in-game texture, it looked mostly good, except for patches of purple that snuck in where the color difference was too great.
I think, however, that two completely different, yet similarly coloured textures, could work. This way, if there isn't a high-res version available, the artist can create a new high-res texture from scratch, so long as it uses similar colours in similar places. I'll do some testing on similar textures now.
Sigh, I'm a bloody moron. I've removed this post to re-write it.
I have successfully tested this in-game, it works.
Previously Half-Life downscaled my detailed textures to 256x256, so I assumed it would never work. However, I then thought, what if there was a max texture size. There is.
In addition to enabling detailed textures, you must change gl_max_size to 512. Then it works wonders.
I'm going to post some screenshots in a few minutes, I'd appreciate it if you guys can take a look and tell me if my program is making any mistakes.
You're about to see the first ever screenshots of honest-to-goodness 512x512x24 textures in Half-Life <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
EDIT: Here are screenshots: <a href='http://ded.novasearch.net/guspaz/HLTex/' target='_blank'>http://ded.novasearch.net/guspaz/HLTex/</a> <b>56k beware! Some images are over 1MB in size, since they're 24-bit PNG!</b>
EDIT2: I've credited the NS community, rather than myself or WolfWings or SoylentGreen, because everybody contributed, and I would like people to associate NS with this technique <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
<!--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-->commander, permission to initiate Operation Wet Ponce?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> thats kinda what i was thinkin
**edit** I like how theres like, 4 people refreshing this thread to wait for the pics <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
They're up in my post on page 27 <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
EDIT: Sorry guys, didn't realize it had gone onto the next page, just head to page 27 for the URL <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
whats up with the 5fps BOOST from r_detailedtextures? <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
The average framerates are the same, but it jitters about, even not moving. It was just random luck that it was 5FPS higher with the detailed textures.
For that, we need SquealLikeAPig to reply to my email and send me the original version of floor_diamond.
Once he does that, I'll test this thing on a REAL NS map for the first time, rather than my current test level (A cube).
If all goes well, and he doesn't tell me he doesn't have the texture sources, then I'll start full-scale conversions of all textures.
EDIT: A repost of the URL for anybody who doesn't want to bother going back a page: <a href='http://ded.novasearch.net/guspaz/HLTex/' target='_blank'>http://ded.novasearch.net/guspaz/HLTex/</a> Again, be warned, large image files, some over a meg, they're 24-bit PNG.
EDIT2: Should we start a new thread for this seperate topic (High-res texture simulation)?
Unless gl_round_down is 0, textures are downfiltered in each dimension to the nearest 2^n, gl_round_down is not 0 by default, assume people are not using it.
I'm to lazy to check, but it would be interesting to know if detail textures are rounded down in the same way or if they are kept at their current size even if they don't have a size of the type 2^nx2^m. You could probably find out if you made a 1 pixel, black and white checkers pattern, 240x240 detail texture. It should look allmost unoticable if it has been filtered down and obvious if it hasn't(it is filtered down in mip-maps so be close to the surface.).
Unless gl_round_down is 0, textures are downfiltered in each dimension to the nearest 2^n, gl_round_down is not 0 by default, assume people are not using it.
I'm to lazy to check, but it would be interesting to know if detail textures are rounded down in the same way or if they are kept at their current size even if they don't have a size of the type 2^nx2^m. You could probably find out if you made a 1 pixel, black and white checkers pattern, 240x240 detail texture. It should look allmost unoticable if it has been filtered down and obvious if it hasn't(it is filtered down in mip-maps so be close to the surface.). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> There is no physical way for a detail texture to not be subject to the same rounding that normal textures are. If anything, I would expect them to perhaps have loading errors, and/or not load at all if not a power-of-2 size.
OpenGL, without special extensions, doesn't support non-power-of-2 textures. And even with those extensions, on those video cards that support them, the rendering time worsens <b>visibly</b> in most cases.
<!--QuoteBegin-Guspaz+Apr 19 2004, 04:56 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 19 2004, 04:56 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> EDIT2: I've credited the NS community, rather than myself or WolfWings or SoylentGreen, because everybody contributed, and I would like people to associate NS with this technique <!--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--> Just to mention something...
I approve. This is my desired method of credit, especially regarding this technique. It's almost entirely a cummulative joining of knowledge by multiple parties that is making this possible. Soylent did his part, I clarified him and explained the steps to create these in detail, and Guspaz did most of the heavy lifting.
But in the end, all of us are part of the NS community, even if some of us (like myself) are mostly inactive these days. And, much like the 'plane optimization' technique, this is a trick we, the NS folks, from trying to push the Half-Life engine far beyond where anyone expected, discovered and worked out the details of.
So stand up proud, folks. <span style='color:white'><b>We did this.</b></span>
EDIT: By the way, Guspaz? Could you re-do that test at different scales? I.E. Show how well (or poorly) it works resizing a 512x512 texture to 128x128 and 64x64 as well as to 256x256? If it works (and I think it would) it would allow NS mappers to have even larger amounts of texture memory, while still staying 'within the limits' for mortal video cards. In fact, if 64x64->512x512 worked, NS mappers would have a rather whopping 256MB of texture memory to work with. =O.o= Even 128x128->512x512 would give them 64MB, which when you include the original 4MB of textures and other textures that might get loaded, will fit nicely in most 'mainstream' 128MB video cards that detail textures work on in the first place.
<!--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-->There is no physical way for a detail texture to not be subject to the same rounding that normal textures are. If anything, I would expect them to perhaps have loading errors, and/or not load at all if not a power-of-2 size.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Oh they work, but I haven't tried to see if they are rounded down to nearest power of 2 but yeah it's reasonable that they are treated exactly the same way as normal HL textures...
edit: giving everyone credit is like a group hug <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->.
<!--QuoteBegin-WolfWings+Apr 20 2004, 05:37 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Apr 20 2004, 05:37 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> EDIT: By the way, Guspaz? Could you re-do that test at different scales? I.E. Show how well (or poorly) it works resizing a 512x512 texture to 128x128 and 64x64 as well as to 256x256? If it works (and I think it would) it would allow NS mappers to have even larger amounts of texture memory, while still staying 'within the limits' for mortal video cards. In fact, if 64x64->512x512 worked, NS mappers would have a rather whopping 256MB of texture memory to work with. =O.o= Even 128x128->512x512 would give them 64MB, which when you include the original 4MB of textures and other textures that might get loaded, will fit nicely in most 'mainstream' 128MB video cards that detail textures work on in the first place. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Sure, but the lower the original texture, the further away it is from the desired output, and the less accurate the output will be... Already I can see difference between the actual and simulated high-res textures. Not big enough to matter, just some of the finer details are a bit darker, but noticeable.
Also, keep in mind, by reducing the resolution of the base textures so much, we're compromising texture quality on lower-end cards, while raising the bar for what you need to turn them on. And I doubt Half-Life has good video memory management. Does it even support AGP texture swapping?
Also, we have yet to see the speed impact of applying a different detailed texture to every texture in a level, that'll come further down the line when (if?) I get copies of the original NS textures.
EDIT: Don't forget, you have to change gl_max_size from 256 to 512. But that's just a cvar change, just like turning on detailed textures, doesn't affect backwards compatibilty. If you don't use them, you can leave it at 256, and play with a Voodoo 3 for all the game cares.
Comments
what will the people with med to low graphics cards see?
This is impossible, there is no way given to do this. And even if there were, that wouldn't allow high-res textures to be used.
The beauty of this method is that people with old videocard see regular textures, those who have relatively modern ones simply change a single cvar and they see high-depth high-res textures. IE, totally backwards compatible.
bah, it's so annoying that they won't allow true-color base textures. i'm gonna write my own game engine for NS, then we won't have any of these restrictions.
Actually, by 'detail/.wad editor' I meant something like Wally, that could have a directory of high-resolution files loaded, and would automatically generate a .wad and a directory of .tga files for the detail textures.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->The idea was to support bulk conversions, to do an entire map in short order. Of course, maps tend to store all their textures in WAD files... I might have to extract them I suppose.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Not really, as you can't go from just the Half-Life texture to the high-res or a true 'detail' texture to improve the texture to 24-bit even. The information you're trying to add simply isn't there to extract in the first place. It was lost when the Half-Life texture was scaled down and converted to an 8-bit image.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Speaking of downscaling, I'm not sure where that comes in. We take the original texture and upscale it, and then produce the output... where am I supposed to be downscaling?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
From the high-resolution 'original' texture down to the Half-Life texture.
Then reduce the Half-Life texture to 8-bit mode.
Then make a COPY that is converted back to 24-bit mode.
Then upscale that copy back to the original size.
Then create the 'detail' texture by comparing that upscaled version and the original texture.
<!--QuoteBegin-Guspaz+Apr 18 2004, 08:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 18 2004, 08:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Unless there are any hitches, I should have a prototype version that does one texture at a time up sometime today.
EDIT: Damn, it's so hard to find an image to work on while poking around in my pictures folder <!--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 have to photoshop up a texture that mimmicks a highres/halflife pair.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Check <a href='http://www.evillair.net' target='_blank'>EvilLair.net</a> for a good source of high-res textures to work with, possibly.
From the high-resolution 'original' texture down to the Half-Life texture.
Then reduce the Half-Life texture to 8-bit mode.
Then make a COPY that is converted back to 24-bit mode.
Then upscale that copy back to the original size.
Then create the 'detail' texture by comparing that upscaled version and the original texture.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You misunderstand me. I'm taking two sources, the Half-Life texture, and the high-res 24-bit version of that texture, converting and scaling up the Half-Life texture, and then producing the detailed texture.
I'm talking about converting EXISTING Half-Life textures by getting the original high-res versions from Squeal-Like-A-Pig.
I emailed him last night about sending me the high-res original version of floor_diamond, hopefully by the time I'm ready to start testing in-game he'll have sent it to me.
Right now I have it producing TGA outputs, the two things left to a working protype are converting the input to the expected format, and then some cleaning up to handle various exceptions that might occure. It's so easy to break the program now by providing non-expected input <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
<!--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-->
Actually, by 'detail/.wad editor' I meant something like Wally, that could have a directory of high-resolution files loaded, and would automatically generate a .wad and a directory of .tga files for the detail textures.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I'm aiming to convert existing Half-Life textures that we have access to the 24-bit source, since my eventual goal is to use the program to create detailed textures for all the in-game NS textures. A requirement of that is to NOT modify the existing 8-bit textures.
It would be trivial, though, due to my use of ImageMagick, to add support for only one input image, the 24-bit image, and then to produce two TGAs, one in-game version, and one detail version. But that's not really the focus of this program.
It occures to me that it's possible to specify ANY high-res texture to be applied on top of the half-life texture. Theoretically, if you don't have a high-res version of an in-game texture, you can just make one.
Yes, by being a different texture, you'd have a lot less accurate output (Harder to get exactly to the desired channel values), but it'd probably work pretty good. I'll run some tests.
<!--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-->Check EvilLair.net for a good source of high-res textures to work with, possibly.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I ended up taking the standard 24-bit Lena image (convieniently 512x512), and to simulate the Half-Life texture, converted it to a 64-color (To increase the banding to make it more apparent) 256x256. The output looks pretty much what it should be, I'm at school now but when I get home I'll post an image.
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Thank You! My problem was that I didn't/couldn't make a higher res version. I mean, I can do things with filters but with floor diamond it didn't look good and getting it to tile with anything but 1:1 never worked quite right (due to color changes across the texture, a little bit of shading).
Simulating the in-game texture, it looked mostly good, except for patches of purple that snuck in where the color difference was too great.
I think, however, that two completely different, yet similarly coloured textures, could work. This way, if there isn't a high-res version available, the artist can create a new high-res texture from scratch, so long as it uses similar colours in similar places. I'll do some testing on similar textures now.
I have successfully tested this in-game, it works.
Previously Half-Life downscaled my detailed textures to 256x256, so I assumed it would never work. However, I then thought, what if there was a max texture size. There is.
In addition to enabling detailed textures, you must change gl_max_size to 512. Then it works wonders.
I'm going to post some screenshots in a few minutes, I'd appreciate it if you guys can take a look and tell me if my program is making any mistakes.
You're about to see the first ever screenshots of honest-to-goodness 512x512x24 textures in Half-Life <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
EDIT: Here are screenshots: <a href='http://ded.novasearch.net/guspaz/HLTex/' target='_blank'>http://ded.novasearch.net/guspaz/HLTex/</a>
<b>56k beware! Some images are over 1MB in size, since they're 24-bit PNG!</b>
EDIT2: I've credited the NS community, rather than myself or WolfWings or SoylentGreen, because everybody contributed, and I would like people to associate NS with this technique <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
**edit** me too, hi guys!
**edit** I like how theres like, 4 people refreshing this thread to wait for the pics <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
EDIT: Sorry guys, didn't realize it had gone onto the next page, just head to page 27 for the URL <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Awesome stuff. Can't wait till it gets applied to whole ns levels <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Once he does that, I'll test this thing on a REAL NS map for the first time, rather than my current test level (A cube).
If all goes well, and he doesn't tell me he doesn't have the texture sources, then I'll start full-scale conversions of all textures.
EDIT: A repost of the URL for anybody who doesn't want to bother going back a page: <a href='http://ded.novasearch.net/guspaz/HLTex/' target='_blank'>http://ded.novasearch.net/guspaz/HLTex/</a>
Again, be warned, large image files, some over a meg, they're 24-bit PNG.
EDIT2: Should we start a new thread for this seperate topic (High-res texture simulation)?
That is NICE.
Unless gl_round_down is 0, textures are downfiltered in each dimension to the nearest 2^n, gl_round_down is not 0 by default, assume people are not using it.
I'm to lazy to check, but it would be interesting to know if detail textures are rounded down in the same way or if they are kept at their current size even if they don't have a size of the type 2^nx2^m. You could probably find out if you made a 1 pixel, black and white checkers pattern, 240x240 detail texture. It should look allmost unoticable if it has been filtered down and obvious if it hasn't(it is filtered down in mip-maps so be close to the surface.).
Unless gl_round_down is 0, textures are downfiltered in each dimension to the nearest 2^n, gl_round_down is not 0 by default, assume people are not using it.
I'm to lazy to check, but it would be interesting to know if detail textures are rounded down in the same way or if they are kept at their current size even if they don't have a size of the type 2^nx2^m. You could probably find out if you made a 1 pixel, black and white checkers pattern, 240x240 detail texture. It should look allmost unoticable if it has been filtered down and obvious if it hasn't(it is filtered down in mip-maps so be close to the surface.). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
There is no physical way for a detail texture to not be subject to the same rounding that normal textures are. If anything, I would expect them to perhaps have loading errors, and/or not load at all if not a power-of-2 size.
OpenGL, without special extensions, doesn't support non-power-of-2 textures. And even with those extensions, on those video cards that support them, the rendering time worsens <b>visibly</b> in most cases.
Just to mention something...
I approve. This is my desired method of credit, especially regarding this technique. It's almost entirely a cummulative joining of knowledge by multiple parties that is making this possible. Soylent did his part, I clarified him and explained the steps to create these in detail, and Guspaz did most of the heavy lifting.
But in the end, all of us are part of the NS community, even if some of us (like myself) are mostly inactive these days. And, much like the 'plane optimization' technique, this is a trick we, the NS folks, from trying to push the Half-Life engine far beyond where anyone expected, discovered and worked out the details of.
So stand up proud, folks. <span style='color:white'><b>We did this.</b></span>
EDIT: By the way, Guspaz? Could you re-do that test at different scales? I.E. Show how well (or poorly) it works resizing a 512x512 texture to 128x128 and 64x64 as well as to 256x256? If it works (and I think it would) it would allow NS mappers to have even larger amounts of texture memory, while still staying 'within the limits' for mortal video cards. In fact, if 64x64->512x512 worked, NS mappers would have a rather whopping 256MB of texture memory to work with. =O.o= Even 128x128->512x512 would give them 64MB, which when you include the original 4MB of textures and other textures that might get loaded, will fit nicely in most 'mainstream' 128MB video cards that detail textures work on in the first place.
Oh they work, but I haven't tried to see if they are rounded down to nearest power of 2 but yeah it's reasonable that they are treated exactly the same way as normal HL textures...
edit: giving everyone credit is like a group hug <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->.
Sure, but the lower the original texture, the further away it is from the desired output, and the less accurate the output will be... Already I can see difference between the actual and simulated high-res textures. Not big enough to matter, just some of the finer details are a bit darker, but noticeable.
Also, keep in mind, by reducing the resolution of the base textures so much, we're compromising texture quality on lower-end cards, while raising the bar for what you need to turn them on. And I doubt Half-Life has good video memory management. Does it even support AGP texture swapping?
Also, we have yet to see the speed impact of applying a different detailed texture to every texture in a level, that'll come further down the line when (if?) I get copies of the original NS textures.
EDIT: Don't forget, you have to change gl_max_size from 256 to 512. But that's just a cvar change, just like turning on detailed textures, doesn't affect backwards compatibilty. If you don't use them, you can leave it at 256, and play with a Voodoo 3 for all the game cares.