<!--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-->That's not a problem, that's a benefit, and the best way that detail textures work. If you -can- see the detail textures from far away, you're going to see the blatant tiling. Even the oft-praised HI shots show this. Detail textures only should be notably visible at close range, as that's when they make the most benefit and are the most needed. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
None the less it is a problem with his idea which is what I commented on, and of course it isn't a problem in general, if you could see detail textures from afar you would NOT see the blatant tiling, you would see weird pixel poping. You know like doom 1/2 where textures far enough away just look like a flickering mess, or the water effect in halo, or any kind of large model in NS viewed from far enough away.
Updated the detail texture pack. Let me know if there are any obvious problems. I know there are a few things that aren't exactly beutiful on nancy but damn near everything has a detail texture on it(e.g. some inventive re-use of textures for making chairs leaves the chairs in marine start looking like they're made from concrete and scratchy metal and stuff <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->).
edit: wanna see what the worst pointfile ever is?(managed to find the leak quickly with big box method, but I did take a look at this thing and collapsed in laughter.)
The only problem I see is that it looks like you didn't update the less bumpy set. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
Now that this 22-texture limit is gone, it seems that it's now possible to use a detailed texture for every texture in a map... Which means that you should be able to use detailed texture on every texture on the map to make it (appear as) a 24-bit texture...
I'm seriously considering writing that app I mentioned to take a 24-bit texture, and the 8-bit in-game version, and calculate a detailed texture that, in-game, will make the 8-bit texture appear exactly like the 24-bit original. It should be easy to do, and the best part of this is that it's completely backwards compatible. On old cards, or with detailed textures turned off, you see 8-bit textures. With new cards and detailed textures on, you see 24-bit textures.
What's holding me back? Three things:
1) Photoshop crashes on my machine like nobody's business. I can work in it for a few minutes, but then KABLOOIE. I've recently switched videocards from my Radeon 9700 Pro to my GeForce 3 to fix crashes in Half-Life and UT2K4 (Radeon is defective), so I'll see if this fixes the reboot problem with photoshop.
2) I don't have access to any of the original versions of the NS textures. I'm sure the artists drew the textures as higher-res 24-bit textures, and then scaled them down and dithered them for the final version. But I don't have any of them. So when writing the program, all my testing would have to be on custom textures, which for me would probably mean replacing a wall texture in a map with a photograph <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
3) Time. I mean, I don't really have it. Maybe I can find it. I hope so, because I think this technique holds a lot of promise. Just imagine, NS with 24-bit textures!
<!--QuoteBegin-Guspaz+Mar 28 2004, 05:35 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Mar 28 2004, 05:35 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> 2) I don't have access to any of the original versions of the NS textures. I'm sure the artists drew the textures as higher-res 24-bit textures, and then scaled them down and dithered them for the final version. But I don't have any of them. So when writing the program, all my testing would have to be on custom textures, which for me would probably mean replacing a wall texture in a map with a photograph <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> PM/e-mail Squeal like a Pig, hes the guy who drew all the NS textures. Im sure he'll be interested in having all his textures in pseudo-24bit glory <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
That would quadrupel texture usage if you enable detail textures(assuming you don't jack up the res on the detail textures). Can HL take that without crashing?(is there a hard limit HL won't surpass because it is old and they didn't think people would do weird stunts like that anyway?)
<!--QuoteBegin-Soylent green+Mar 28 2004, 09:04 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Soylent green @ Mar 28 2004, 09:04 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> It can handle it, it's just that VALVe chose to implement detail textures in a way that your card can't handle.
also there is a MOD for quake 1 called tenebrae that your card can't handle either(but in this case it's not just cause of lazy developers). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Errr, my GF4MX can run Tenebrae. Slowly, of course.
<!--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-->Errr, my GF4MX can run Tenebrae. Slowly, of course. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
But... doesn't it use some ps features not supported on older cards(e.g. turned off when using older cards) besides the stencil shadows which are just slow but work on old cards?(e.g. specular maps, bump maps(not all types of bump mapping work on old cards. edit: tenebrae supports normal maps, commonly implemented as a pixelshader) and such).
<!--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-->Is the updated pack always in your sig? I don't know now if I'm just downloading an old version I might already have... <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Yes, but I haven't updated the less "bumpy-looking" set in a while.
Making a detail texture for every regular texture seems like foolishness that runs contrary to what a detail texture is supposed to be. UT2K3, UT2K4 and AVP2 all use detail textures to overcome the pixellation of a close surface and only need between 5 - 15 different detail textures per level to achieve this.
We're talking about Half-Life here, an engine that is so ancient it uses 256 colour textures... I think we could/should exploit every single possible method of increasing the game's quality. Using detailed textures for other than what they're intended, stuff like this has been done since the age of DooM when people exploited mapping oddities to get all sorts of neat stuff like kind of 3D bridges and stuff.
NS itself goes way beyond what HL is designed to do; there were never supposed to be so many entities used in the game.
Guspaz is right. These detailed textures can really help boost the visual quallity of HL. Though with every texture being detaitailed, it will take alot of memory, its an optional feature for those with high end machines.
NS has been built on improvisation of many people, using things in ways they were never designed to. Thats how such a quality game came out of the HL engine.
<!--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--> Using detailed textures for other than what they're intended, stuff like this has been done since the age of DooM when people exploited mapping oddities to get all sorts of neat stuff like kind of 3D bridges and stuff.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You could play sampled sounds on the commodore 64 by exploiting a bug that made a very short "click" with the sound card(the infamous sid(Sound Interface Device <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->) chip). Sure it sounded like crap but...
Also you could remove the frame around the screen(unused are of the screen) and use it for whatever purpose you wished by precisely counting clock cycles for commands and using NOPs for padding to exploit a bug that if timed right will allow drawing in the area where the frames are. Many games used this in at least one dimension(e.g. remove the part of the frame to the side and not at the top).
<!--QuoteBegin-Guspaz+Mar 31 2004, 12:46 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Mar 31 2004, 12:46 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> We're talking about Half-Life here, an engine that is so ancient it uses 256 colour textures... I think we could/should exploit every single possible method of increasing the game's quality. Using detailed textures for other than what they're intended, stuff like this has been done since the age of DooM when people exploited mapping oddities to get all sorts of neat stuff like kind of 3D bridges and stuff.
NS itself goes way beyond what HL is designed to do; there were never supposed to be so many entities used in the game. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> You're missing the point.
A detail texture is not intended for ramping up the contrast, that's what a bump map is for, and making a detail texture do what a bump map does is just not visually convincing.
Also keep in mind that the contrast of the detail texture determines how far away it's rendered, so making them act like bumpmaps is going to result in scenes where you can see horribly tiled detail textures at great distances.
I PMed Lito on IRC and he said that that's Uranium's map. I in turn PMed him. Here's my IRC log.
<!--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--> <u235> What? <Casper> hey about your map. <u235> Um, desolate? Yeah? <Casper> how are u doing your detail texture <u235> Oh <u235> Hang on <Casper> k <u235> All the textures, every texture, is going to use a higher resolution overlay to sharpen the edges and smooth it <u235> like <u235> it'll make circles more circular, and I found that with a bit of photoshop hackery, I can get metals to look shinier. <u235> then over the top I'll probably plop an actual texture of some sort. Scratches, bumps <u235> I dunno, some guy made an assload of detail textures for NS, I've been using those. <Casper> how big are they? <u235> Well I'm doing this so I can actually get around the 4 meg texture limit in half-life <u235> I can use lower-end .wads nad like... use 4x as many textures, then simply detail them up with a higher resolution one, with sharper colors. <u235> like <u235> <a href='http://uranium235.thezazi.net/DetailVs2.jpg' target='_blank'>http://uranium235.thezazi.net/DetailVs2.jpg</a> <u235> see the floors? Especially in the bunk room <u235> I've got two different resolution, quality, and color textures on there, one is the detail and ones the regular <Casper> looks cool, i like it <u235|Away> thanks. I've still got more textures to do too... <u235|Away> I gotta get to the store now, later <Casper> later<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
If you go through the desolate thread you can see all the metal textures have a sharper, colder 'bite' to them.
<!--QuoteBegin-Yamazaki+Mar 31 2004, 12:46 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Yamazaki @ Mar 31 2004, 12:46 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin-Guspaz+Mar 31 2004, 12:46 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Mar 31 2004, 12:46 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> We're talking about Half-Life here, an engine that is so ancient it uses 256 colour textures... I think we could/should exploit every single possible method of increasing the game's quality. Using detailed textures for other than what they're intended, stuff like this has been done since the age of DooM when people exploited mapping oddities to get all sorts of neat stuff like kind of 3D bridges and stuff.
NS itself goes way beyond what HL is designed to do; there were never supposed to be so many entities used in the game. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> You're missing the point.
A detail texture is not intended for ramping up the contrast, that's what a bump map is for, and making a detail texture do what a bump map does is just not visually convincing.
Also keep in mind that the contrast of the detail texture determines how far away it's rendered, so making them act like bumpmaps is going to result in scenes where you can see horribly tiled detail textures at great distances. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Actually, I think you're missing the point <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
I've been discussing using detailed textures to simulate 24-bit textures, not treating them like bumpmaps.
My idea is to take the original 24-bit texture, and 8-bit in-game texture, and calculate the detail texture that must be applied to make the in-game effect look exactly like the 24-bit original texture. Machines without detailed textures off see 8-bit textures, turn it on and you see 24-bit textures.
Well if that's what you're doing, then all good. However, most people were talking about just trying to add noise to a larger version of the same texture, and that doesn't end up working all that well (i tried). If you have a 24-bit version of the texture or a higher-res version of the texture, than by all means, give it a shot.
EEK, he means taking a highly detailed and 24-bit version and "separating" into a detail texture and a 8-bit version so that you can have higher resolution textures with higher bit depth and still have it translucent so that it is off if your computer can't handle detail textures or that much memory usage.
Don't think anyone has attempted this idea but it's been suggested in this thread.
We would need to know how detail textures are applied in game but it should'nt be impossible with trial and error. Right know we know 127 127 127 (or 128 128 128?) will not make any difference, darker gray will make the texture darker using some calculation(looks like calculating a factor for each colour channel with the detail texture, possibly 0 0 0 gives the factor 0 for all colour channels, 127 127 127 gives 1 and 255 255 255 2 or something?).
It actually gets more complicated when you add colour. I've done a bit of experimenting with this , and the colour detailed texture seems to act like a simple overlay. It's also visible at any angle and distance.
It's possible they could be doing something as simple as doing a simple translucency calculation on the two textures. That'd be the easiest thing to work with, though a bit of trial and error would be required to find out what relative translucencies they're using. Maybe I should email VALVe.
I think I'm going to ask Squeal Like a Pig for the original version of an in-game texture to experiment with, and then try to get this figured out. Then maybe I'll actually try to code something.
I should note that people seem a bit confused about this idea; it's not for putting higher resolution textures in-game, though that might be possible if detailed textures allow a 512x512 res (Though then the math would be a nightmare for me trying to keep per-pixel accuracy when bilinear, trilinear, and anisotropic filtering set in). My idea is strictly for getting high-colour textures in-game.
Also, Soylent Green, that's almost it, but I won't be generating the 8-bit version, only the detailed texture. If this all works out, you wouldn't have to touch the map's built-in textures.
<!--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 should note that people seem a bit confused about this idea; it's not for putting higher resolution textures in-game, though that might be possible if detailed textures allow a 512x512 res (Though then the math would be a nightmare for me trying to keep per-pixel accuracy when bilinear, trilinear, and anisotropic filtering set in). My idea is strictly for getting high-colour textures in-game.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You don't have to care about trilinear and least of all anisotropic, only bilinear.
For those who don't know, bilinear filtering refers to interpolating the colour between texels(pixels in a texture) to find an intermideate, and this is done in the simplest possible manner, 2 linear interpolations using the 4 closest texels to the point you wan't to sample.
Mipmapping is the process of pre-computing a series of smaller versions of the original texture. These are not for performance economy saving, they are for picture quality. If the largest texture was allways used you would get lots of weird pixel popping because on objects and walls far away from you each pixel corresponds to many texels, which texels it chooses to represent that pixel will then appear allmost random and pixels will flicker. By avaraging texels when creating mipmaps you can choose a mipmap such that a pixel on the screen of the object being rendered corresponds to roughly one texel and no aliasing will occur.
Trilinear filtering is the process of taking a bilinear colour sample from the 2 best mipmaps for that distance and then doing a (distance based) linear filtering between these 2 colour samples. Why would you wan't to do this then? If you don't you will see an artifact often refered to as mipmap line, this is where the graphics card changes from using one mipmap to another. When using a mipmap that is to large you get more aliasing and a sharper looking texture, when using a mipmap that is too small you get no aliasing and a more blurry looking texture. Thus when you change between 2 mipmaps you will visible see a line where the texture appears to turn blurry(try alternating between gl_texturemode gl_linear_mipmap_linear (this is trilinear) and gl_linear_mipmap_nearest (this is bilinear) to see the difference). (LOD(level of detail) bias is a shift in the distance where mipmaps are changed, this is used by some games and usually called something like texture sharpening, higher LOD is blurier and lower is sharper but more aliased, 0 is the default and should result in minimal aliasing and minimal blurring, but some like their textures sharper(negative LOD)).
Anisotropic filtering is an angle dependant filtering to keep textures from getting blurry when their normal is allmost perpendicular to the screen(extra texture samples are taken in the depth direction along the texture in different patterns on different cards), it will only make a difference when you are looking at a wall that is not facing straight at you(graphics cards save resources by not applying it unless they think it's nessecary, e.g. not on walls facing you and more and more as you increase the angle between surface normal and screen).
If you want to use a detail texture to simulate a higher resolution texture you would have to care that the game uses bilinear filtering when creating your detail texture, but you won't have to care about the linear filtering inbetween mipmaps when trilinear is turned on because it IS applied automatically to detail textures and textures alike if you are using gl_texturemode gl_linear_mipmap_linear. You won't have to care about anisotropic filtering because you cannot do this, it is applied to normal textures at weird angles if and only if the user has it turned on(most don't I would guess) and the game will use differing amounts of anisotropic filtering for different angles dynamically. Anisotropic might be applied to detail textures if turned on allready, that depends on how VALVe made their implementation of detail textures. Besides, the only problem that can occur because you cannot adjust your texture somehow for anisotropic filtering is that the detail texture itself gets blurry at odd angles.
The problem is only to account for bilinear filtering. If you take the texture and export it to a bmp and open it in photoshop, convert it to 32 bpp then use the image size tool and select bilinear you and scale it up to the size of your orignal 32-bit texture(the one you hopefully could get from Merkaba) you will have 2 images to make your detail texture from and you can apply the same method as when making a detail texture to convert an 8-bit texture to 32-bit as discussed earlier.
Sounds good, I wasn't sure if higher level filtering was applied the same to detailed and normal textures. Since they are, everything is much simpler...
Not sure about using photoshop to do the bilinear filtering for the comparison though, that'd require a third texture, and a lot more work when you're converting many of them.
Though, when I think about it, once the program has internally taken the 8-bit texture, and scaled it up to the high-res with bilinear filtering, it's the EXACT same next step as without trying for higher res; calculate the differences between the two images the detailed texture would need to be.
The next question; what resolution do detailed textures max out at? If it's 240x240 or 256x256 like regular textures, then it won't matter since the detailed texture can't be higher res. On the other hand, if it's higher... well I don't think I'd even try to fake a resolution higher than 512x512, I don't want NS to require a 256MB video card with the "enhanced" mode on <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
Bad news, VALVe's official article on this states: <!--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-->Detail textures should be a power of two in size, as 256x256 is the maximum size Half-Life will load.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> The author then goes on to say that he's found that 128x128 works well for most detailed textures. However, for our purposes here, we're going to have detailed textures that are exactly the same dimensions as the original textures, up to 256x256 (240x240).
So, no high-res fakery here, best we can do is high-depth fakery. Still, this has the potential to make the game look a WHOLE lot better.
Once I finish this bloody chemistry project, I'm going to look into this more. I'll start with finding a texture that REALLY shows that it's 8-bit (Feel free to suggest one, a 256x256 texture would be best for testing purposes). Once that's done, I'll request the original from the NS art people. If they send it along, I'll be able to start coding...
Comments
None the less it is a problem with his idea which is what I commented on, and of course it isn't a problem in general, if you could see detail textures from afar you would NOT see the blatant tiling, you would see weird pixel poping. You know like doom 1/2 where textures far enough away just look like a flickering mess, or the water effect in halo, or any kind of large model in NS viewed from far enough away.
edit: wanna see what the worst pointfile ever is?(managed to find the leak quickly with big box method, but I did take a look at this thing and collapsed in laughter.)
I'm seriously considering writing that app I mentioned to take a 24-bit texture, and the 8-bit in-game version, and calculate a detailed texture that, in-game, will make the 8-bit texture appear exactly like the 24-bit original. It should be easy to do, and the best part of this is that it's completely backwards compatible. On old cards, or with detailed textures turned off, you see 8-bit textures. With new cards and detailed textures on, you see 24-bit textures.
What's holding me back? Three things:
1) Photoshop crashes on my machine like nobody's business. I can work in it for a few minutes, but then KABLOOIE. I've recently switched videocards from my Radeon 9700 Pro to my GeForce 3 to fix crashes in Half-Life and UT2K4 (Radeon is defective), so I'll see if this fixes the reboot problem with photoshop.
2) I don't have access to any of the original versions of the NS textures. I'm sure the artists drew the textures as higher-res 24-bit textures, and then scaled them down and dithered them for the final version. But I don't have any of them. So when writing the program, all my testing would have to be on custom textures, which for me would probably mean replacing a wall texture in a map with a photograph <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
3) Time. I mean, I don't really have it. Maybe I can find it. I hope so, because I think this technique holds a lot of promise. Just imagine, NS with 24-bit textures!
PM/e-mail Squeal like a Pig, hes the guy who drew all the NS textures. Im sure he'll be interested in having all his textures in pseudo-24bit glory <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I guesse its time for me to upgrade when a 6 year old engine cando things my card cant handle.
also there is a MOD for quake 1 called tenebrae that your card can't handle either(but in this case it's not just cause of lazy developers).
also there is a MOD for quake 1 called tenebrae that your card can't handle either(but in this case it's not just cause of lazy developers). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Errr, my GF4MX can run Tenebrae. Slowly, of course.
But... doesn't it use some ps features not supported on older cards(e.g. turned off when using older cards) besides the stencil shadows which are just slow but work on old cards?(e.g. specular maps, bump maps(not all types of bump mapping work on old cards. edit: tenebrae supports normal maps, commonly implemented as a pixelshader) and such).
Yes, but I haven't updated the less "bumpy-looking" set in a while.
NS itself goes way beyond what HL is designed to do; there were never supposed to be so many entities used in the game.
NS has been built on improvisation of many people, using things in ways they were never designed to. Thats how such a quality game came out of the HL engine.
You could play sampled sounds on the commodore 64 by exploiting a bug that made a very short "click" with the sound card(the infamous sid(Sound Interface Device <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->) chip). Sure it sounded like crap but...
Also you could remove the frame around the screen(unused are of the screen) and use it for whatever purpose you wished by precisely counting clock cycles for commands and using NOPs for padding to exploit a bug that if timed right will allow drawing in the area where the frames are. Many games used this in at least one dimension(e.g. remove the part of the frame to the side and not at the top).
NS itself goes way beyond what HL is designed to do; there were never supposed to be so many entities used in the game. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
You're missing the point.
A detail texture is not intended for ramping up the contrast, that's what a bump map is for, and making a detail texture do what a bump map does is just not visually convincing.
Also keep in mind that the contrast of the detail texture determines how far away it's rendered, so making them act like bumpmaps is going to result in scenes where you can see horribly tiled detail textures at great distances.
I PMed Lito on IRC and he said that that's Uranium's map. I in turn PMed him. Here's my IRC log.
<!--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-->
<u235> What?
<Casper> hey about your map.
<u235> Um, desolate? Yeah?
<Casper> how are u doing your detail texture
<u235> Oh
<u235> Hang on
<Casper> k
<u235> All the textures, every texture, is going to use a higher resolution overlay to sharpen the edges and smooth it
<u235> like
<u235> it'll make circles more circular, and I found that with a bit of photoshop hackery, I can get metals to look shinier.
<u235> then over the top I'll probably plop an actual texture of some sort. Scratches, bumps
<u235> I dunno, some guy made an assload of detail textures for NS, I've been using those.
<Casper> how big are they?
<u235> Well I'm doing this so I can actually get around the 4 meg texture limit in half-life
<u235> I can use lower-end .wads nad like... use 4x as many textures, then simply detail them up with a higher resolution one, with sharper colors.
<u235> like
<u235> <a href='http://uranium235.thezazi.net/DetailVs2.jpg' target='_blank'>http://uranium235.thezazi.net/DetailVs2.jpg</a>
<u235> see the floors? Especially in the bunk room
<u235> I've got two different resolution, quality, and color textures on there, one is the detail and ones the regular
<Casper> looks cool, i like it
<u235|Away> thanks. I've still got more textures to do too...
<u235|Away> I gotta get to the store now, later
<Casper> later<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
If you go through the desolate thread you can see all the metal textures have a sharper, colder 'bite' to them.
And my 'Tab' key appears to be broken.
NS itself goes way beyond what HL is designed to do; there were never supposed to be so many entities used in the game. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You're missing the point.
A detail texture is not intended for ramping up the contrast, that's what a bump map is for, and making a detail texture do what a bump map does is just not visually convincing.
Also keep in mind that the contrast of the detail texture determines how far away it's rendered, so making them act like bumpmaps is going to result in scenes where you can see horribly tiled detail textures at great distances. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Actually, I think you're missing the point <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
I've been discussing using detailed textures to simulate 24-bit textures, not treating them like bumpmaps.
My idea is to take the original 24-bit texture, and 8-bit in-game texture, and calculate the detail texture that must be applied to make the in-game effect look exactly like the 24-bit original texture. Machines without detailed textures off see 8-bit textures, turn it on and you see 24-bit textures.
Don't think anyone has attempted this idea but it's been suggested in this thread.
We would need to know how detail textures are applied in game but it should'nt be impossible with trial and error. Right know we know 127 127 127 (or 128 128 128?) will not make any difference, darker gray will make the texture darker using some calculation(looks like calculating a factor for each colour channel with the detail texture, possibly 0 0 0 gives the factor 0 for all colour channels, 127 127 127 gives 1 and 255 255 255 2 or something?).
It's possible they could be doing something as simple as doing a simple translucency calculation on the two textures. That'd be the easiest thing to work with, though a bit of trial and error would be required to find out what relative translucencies they're using. Maybe I should email VALVe.
I think I'm going to ask Squeal Like a Pig for the original version of an in-game texture to experiment with, and then try to get this figured out. Then maybe I'll actually try to code something.
I should note that people seem a bit confused about this idea; it's not for putting higher resolution textures in-game, though that might be possible if detailed textures allow a 512x512 res (Though then the math would be a nightmare for me trying to keep per-pixel accuracy when bilinear, trilinear, and anisotropic filtering set in). My idea is strictly for getting high-colour textures in-game.
Also, Soylent Green, that's almost it, but I won't be generating the 8-bit version, only the detailed texture. If this all works out, you wouldn't have to touch the map's built-in textures.
You don't have to care about trilinear and least of all anisotropic, only bilinear.
For those who don't know, bilinear filtering refers to interpolating the colour between texels(pixels in a texture) to find an intermideate, and this is done in the simplest possible manner, 2 linear interpolations using the 4 closest texels to the point you wan't to sample.
Mipmapping is the process of pre-computing a series of smaller versions of the original texture. These are not for performance economy saving, they are for picture quality. If the largest texture was allways used you would get lots of weird pixel popping because on objects and walls far away from you each pixel corresponds to many texels, which texels it chooses to represent that pixel will then appear allmost random and pixels will flicker. By avaraging texels when creating mipmaps you can choose a mipmap such that a pixel on the screen of the object being rendered corresponds to roughly one texel and no aliasing will occur.
Trilinear filtering is the process of taking a bilinear colour sample from the 2 best mipmaps for that distance and then doing a (distance based) linear filtering between these 2 colour samples. Why would you wan't to do this then? If you don't you will see an artifact often refered to as mipmap line, this is where the graphics card changes from using one mipmap to another. When using a mipmap that is to large you get more aliasing and a sharper looking texture, when using a mipmap that is too small you get no aliasing and a more blurry looking texture. Thus when you change between 2 mipmaps you will visible see a line where the texture appears to turn blurry(try alternating between gl_texturemode gl_linear_mipmap_linear (this is trilinear) and gl_linear_mipmap_nearest (this is bilinear) to see the difference). (LOD(level of detail) bias is a shift in the distance where mipmaps are changed, this is used by some games and usually called something like texture sharpening, higher LOD is blurier and lower is sharper but more aliased, 0 is the default and should result in minimal aliasing and minimal blurring, but some like their textures sharper(negative LOD)).
Anisotropic filtering is an angle dependant filtering to keep textures from getting blurry when their normal is allmost perpendicular to the screen(extra texture samples are taken in the depth direction along the texture in different patterns on different cards), it will only make a difference when you are looking at a wall that is not facing straight at you(graphics cards save resources by not applying it unless they think it's nessecary, e.g. not on walls facing you and more and more as you increase the angle between surface normal and screen).
If you want to use a detail texture to simulate a higher resolution texture you would have to care that the game uses bilinear filtering when creating your detail texture, but you won't have to care about the linear filtering inbetween mipmaps when trilinear is turned on because it IS applied automatically to detail textures and textures alike if you are using gl_texturemode gl_linear_mipmap_linear. You won't have to care about anisotropic filtering because you cannot do this, it is applied to normal textures at weird angles if and only if the user has it turned on(most don't I would guess) and the game will use differing amounts of anisotropic filtering for different angles dynamically. Anisotropic might be applied to detail textures if turned on allready, that depends on how VALVe made their implementation of detail textures. Besides, the only problem that can occur because you cannot adjust your texture somehow for anisotropic filtering is that the detail texture itself gets blurry at odd angles.
The problem is only to account for bilinear filtering. If you take the texture and export it to a bmp and open it in photoshop, convert it to 32 bpp then use the image size tool and select bilinear you and scale it up to the size of your orignal 32-bit texture(the one you hopefully could get from Merkaba) you will have 2 images to make your detail texture from and you can apply the same method as when making a detail texture to convert an 8-bit texture to 32-bit as discussed earlier.
Not sure about using photoshop to do the bilinear filtering for the comparison though, that'd require a third texture, and a lot more work when you're converting many of them.
Though, when I think about it, once the program has internally taken the 8-bit texture, and scaled it up to the high-res with bilinear filtering, it's the EXACT same next step as without trying for higher res; calculate the differences between the two images the detailed texture would need to be.
The next question; what resolution do detailed textures max out at? If it's 240x240 or 256x256 like regular textures, then it won't matter since the detailed texture can't be higher res. On the other hand, if it's higher... well I don't think I'd even try to fake a resolution higher than 512x512, I don't want NS to require a 256MB video card with the "enhanced" mode on <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
The author then goes on to say that he's found that 128x128 works well for most detailed textures. However, for our purposes here, we're going to have detailed textures that are exactly the same dimensions as the original textures, up to 256x256 (240x240).
So, no high-res fakery here, best we can do is high-depth fakery. Still, this has the potential to make the game look a WHOLE lot better.
Once I finish this bloody chemistry project, I'm going to look into this more. I'll start with finding a texture that REALLY shows that it's 8-bit (Feel free to suggest one, a 256x256 texture would be best for testing purposes). Once that's done, I'll request the original from the NS art people. If they send it along, I'll be able to start coding...