KungFuSquirrelBasher of MuttonsJoin Date: 2002-01-26Member: 103Members, NS1 Playtester, Contributor
<!--QuoteBegin-Guspaz+Apr 4 2004, 08:15 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 4 2004, 08:15 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Bad news, VALVe's official article on this states: <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> There is <b>no official Valve article</b>, and on top of that 256x256 is not the max size of textures allowed in a .wad. Even some (well, at least 1) standard HL texture violates this. 512x512 textures work even in a regular .wad; it is probably safe to assume they will on detail textures as well. HL models can technically handle 1024x1024 resolution according to the Modeling for HL doc in the SDK, though I wouldn't recommend trying it <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
A question.. I use GeForce 4 MX460 and the r_detailtextures don't work. If I type "r_de" into the console the little autocomplete box don't have "r_detailtextures 0" and "r_detailtexturessupported 1" in it. Also i don't wanna spend my pocket money to buy a new graphic card. Because i am poor. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> Can i solve that problem withour buying a supported graphic card?
guspaz, 1024x1024 crashes NS. 512x512 would probably work(edit: yepp, works, tried with a simple 512x512 checkered pattern and it ran just fine). Steam has probably had a couple of updates since then(whenever it was mentioned 256x256 was the max res in that verc thread). Which also may explain why I was unable to use more than 22 detail textures including spaces and even when reordering or adding spaces in the detail texture list file a long while back.
P-Assaulter, not to mention that buying a new graphics card just for detail textures would be kind of silly.
KungFuSquirrelBasher of MuttonsJoin Date: 2002-01-26Member: 103Members, NS1 Playtester, Contributor
<!--QuoteBegin-Soylent green+Apr 5 2004, 01:17 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Soylent green @ Apr 5 2004, 01:17 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Steam has probably had a couple of updates since then(whenever it was mentioned 256x256 was the max res in that verc thread). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I interpreted that as having just been written under the assumption that Half-Life won't load any texture over 256x256, detail or not, which is not the case.
I highly doubt such a minor feature as this (especially one used so poorly in CZ and then nowhere else) would have any weight in being updated via Steam since its inception.
<!--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 highly doubt such a minor feature as this (especially one used so poorly in CZ and then nowhere else) would have any weight in being updated via Steam since its inception. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Perhaps they noticed that some of the various MOD communities have looked a bit at detail textures and what they can do and decided it was worth 20 minutes of their time to fix annoying issues with their usage?`
<!--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-->HL models can technically handle 1024x1024 resolution according to the Modeling for HL doc in the SDK, though I wouldn't recommend trying it<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Sounds interesting actually, but surely the normal NS models would lose their texture alignment if you just decompiled them and used a larger texture, it would be a hell to fix it if you decided to try and make larger textures for them. And you would probably have to put the texture in a separate mdl file and stuff right?
On second thought, it wouldn't really help that much either sadly. Since no mip-maping is applied to models you might start to see aliasing at even shorter distances and it would only look better at very short distances.
KungFuSquirrelBasher of MuttonsJoin Date: 2002-01-26Member: 103Members, NS1 Playtester, Contributor
They're not touching <i>anything</i> they don't have to for their own uses. Valve may be "Mr. Nice Helpful to the Community," but I recently spoke with their community liason, who stated something along the lines of he would be shot if he even <i>thought</i> about asking for some sort of HL or HL editing related work at this point in time.
<!--QuoteBegin-KungFuSquirrel+Apr 5 2004, 08:14 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (KungFuSquirrel @ Apr 5 2004, 08:14 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> They're not touching <i>anything</i> they don't have to for their own uses. Valve may be "Mr. Nice Helpful to the Community," but I recently spoke with their community liason, who stated something along the lines of he would be shot if he even <i>thought</i> about asking for some sort of HL or HL editing related work at this point in time. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Yeah, I thought as much. All their eggs are in the HL2/TFC2/CS2 (and so on) basket.
Good news, Soylant and KFS. I guess VERC should update that article.
Well, when I start work on this in a few days, then, I'll go for both simulating higher res, and higher depth. They both follow. The trick will be figuring out exactly what method is used to apply detailed textures; since nobody on the VERC forums has replied to my post last I checked, it will be trial and error, unless I contact VALVe directly.
Anybody know who I should contact (Specific email address) for information on exactly how detailed textures are applied? I'm talking the math behind them. If they're done using pixel shaders (which seems possible since they only work on PS supporting cards), then the code to that shader would work. Hey, they've released pages and pages of sourcecode to the Half-Life 2 lighting shaders via ATI's dev site <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
I would start with the assumption that detail textures are as linear as possible, and hey if it looks good it doesn't matter if there is an assumption that is just very slightly wrong.
0 means multiply that colour component with 0, 127 means multiply the corresponding colour component with 1 and all values outside can be derived linearly from these. i.e. z = x*y/127 where z is the final colour(disregarding the light map) x is the texture colour and y the detail texture colour.
(a detail texture of 255 255 255 does not unconditionally make textures white, it makes them appear to be saturated in spots, like you just multiplied the colour with ~2).
edit: if things are as easy as they possibly can be all you strictly have to do to make the suggested program is to make a program that reads 2 equal sized 24-bit .tga's and writes a new one. Better yet, all you need to be able to get out of header portion of the file is the size of the image and the length of the header before the data chunk, then you can just copy the whole header and hope it works(it does indeed for .bmp's, but it would be important to find the bit depth so you can warn if the user tries to put in 8, 16 or 32-bit images(and images of different size)). (btw beware of the big-endian/small-endian stuff. Sometimes files contain big-endian and small-endian within the same damn chunk(e.g. image x and y size might be big-endian, but just to annoy you data chunk size is small endian)).
You also need the user to be able to type in 2 textures and that's about it really. Converting an indexed texture to 24-bit then filtering it up to the size of the source texture used to create it and with bilinear can easily be done in photoshop instead of you coding for it.
<!--QuoteBegin-Guspaz+Apr 5 2004, 09:11 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 5 2004, 09:11 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> If they're done using pixel shaders (which seems possible since they only work on PS supporting cards) <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> False. r_detailedtextures work on my card, and I dont remember being told that my Radeon VE can do pixel shaders. IIRC, pixel shaders are for R8500 and up.
<!--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-->False. r_detailedtextures work on my card, and I dont remember being told that my Radeon VE can do pixel shaders. IIRC, pixel shaders are for R8500 and up. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
edit: It has software support for it(urgh), if your not taking a pretty sizeable performance hit with detail textures I guess their made using some open gl extension that was introduced at the time around radeon 7000/geforce 3. This means that anisotropic filtering should work for detail textures which is nice...
Actually, I've been planning on writing this app in one of three languages:
1) C# 2) VB# 3) PHP
All three languages have built-in graphics handling, so it should be quite simple to do scaling and such. Yes, I could write this in C++ and read some docs on the TGA format, but I'm lazy and I'm going for RAD here, especially with what would appear to be on the surface such a simple program. I've considered PHP as an option because it's underestimated as a desktop development platform, and a while back I wrote an application to encapsulate a PHP script inside a single EXE along with the interpreter. Probably I'll choose C# or VB# though.
Until I get working on the res/depth technique, your textures are king Soylent, and they sure look nice in-game <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Things that tile really really well sure are easy to work with(allmost nothing in ns does, and that floor_diamond is evil, it looks like it just might tile but it has a prime number of "bumps" and you can only use the whole texture as a detail texture or (1/11th?) of it, and some bumps are even out of alignment so it still doesn't tile <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->)
Looks really nice, but when you start doing stuff like that, there's no reason you can't do the same thing with the in-map texture by showing it at a lower scale <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
Yes there is. Just imagine the number of face cuts made at each (texture scale*240) units. Plus, small differences in the original texture will make repetition of the detail texture less obvious.
Bah, I got to start checking these things <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->.
The only thing I can think of is that I for some inane reason didn't choose overwrite when I uploaded it.
Yep, and I just realized, that since detailed textures can be 512x512, you really CAN'T do that exactly with the original texture.
Damn valve for forcing us to take measures we dwouldn't have to if they'd just take 5 minutes and change the constant that says "256" and "8" to "512" and "24"!
OK, so it's more complicated than that, but it's still a rediculously easy thing to change.
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
Looks great, just one suggestion. It looks like in the original texture the bars that go across the grain are slightly raised, but in the detail texture that effect is lost.
Here's another one for you. I'm not big on the carved texture. I think it makes it look like the texture is made of cake frosting. So, I made a modified version of it. Enjoy.
I might try to just make some different details for this kind of metal,but I dunno what to try to apply to it. I mean, even with the degraded one i made, it still seems pretty rugged and although the metal is supposed to look old, worn, and/or rusted, i'm not sure if this is the right effect.
ssjyodaJoin Date: 2002-03-05Member: 274Members, Squad Five Blue
wow, ive ignored this topic for far too long. I had no idea you guys were exploring detail textures and making some. I think this should become mandatory in all ns maps, which, damnit, means I have to go back to my map and pop some in. hehe.
Comments
There is <b>no official Valve article</b>, and on top of that 256x256 is not the max size of textures allowed in a .wad. Even some (well, at least 1) standard HL texture violates this. 512x512 textures work even in a regular .wad; it is probably safe to assume they will on detail textures as well. HL models can technically handle 1024x1024 resolution according to the Modeling for HL doc in the SDK, though I wouldn't recommend trying it <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
I use GeForce 4 MX460 and the r_detailtextures don't work. If I type "r_de" into the console the little autocomplete box don't have "r_detailtextures 0" and "r_detailtexturessupported 1" in it.
Also i don't wanna spend my pocket money to buy a new graphic card. Because i am poor. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> Can i solve that problem withour buying a supported graphic card?
P-Assaulter, not to mention that buying a new graphics card just for detail textures would be kind of silly.
I interpreted that as having just been written under the assumption that Half-Life won't load any texture over 256x256, detail or not, which is not the case.
I highly doubt such a minor feature as this (especially one used so poorly in CZ and then nowhere else) would have any weight in being updated via Steam since its inception.
Perhaps they noticed that some of the various MOD communities have looked a bit at detail textures and what they can do and decided it was worth 20 minutes of their time to fix annoying issues with their usage?`
<!--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-->HL models can technically handle 1024x1024 resolution according to the Modeling for HL doc in the SDK, though I wouldn't recommend trying it<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Sounds interesting actually, but surely the normal NS models would lose their texture alignment if you just decompiled them and used a larger texture, it would be a hell to fix it if you decided to try and make larger textures for them. And you would probably have to put the texture in a separate mdl file and stuff right?
On second thought, it wouldn't really help that much either sadly. Since no mip-maping is applied to models you might start to see aliasing at even shorter distances and it would only look better at very short distances.
Yeah, I thought as much. All their eggs are in the HL2/TFC2/CS2 (and so on) basket.
Well, when I start work on this in a few days, then, I'll go for both simulating higher res, and higher depth. They both follow. The trick will be figuring out exactly what method is used to apply detailed textures; since nobody on the VERC forums has replied to my post last I checked, it will be trial and error, unless I contact VALVe directly.
Anybody know who I should contact (Specific email address) for information on exactly how detailed textures are applied? I'm talking the math behind them. If they're done using pixel shaders (which seems possible since they only work on PS supporting cards), then the code to that shader would work. Hey, they've released pages and pages of sourcecode to the Half-Life 2 lighting shaders via ATI's dev site <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
0 means multiply that colour component with 0, 127 means multiply the corresponding colour component with 1 and all values outside can be derived linearly from these. i.e. z = x*y/127 where z is the final colour(disregarding the light map) x is the texture colour and y the detail texture colour.
(a detail texture of 255 255 255 does not unconditionally make textures white, it makes them appear to be saturated in spots, like you just multiplied the colour with ~2).
edit: if things are as easy as they possibly can be all you strictly have to do to make the suggested program is to make a program that reads 2 equal sized 24-bit .tga's and writes a new one. Better yet, all you need to be able to get out of header portion of the file is the size of the image and the length of the header before the data chunk, then you can just copy the whole header and hope it works(it does indeed for .bmp's, but it would be important to find the bit depth so you can warn if the user tries to put in 8, 16 or 32-bit images(and images of different size)). (btw beware of the big-endian/small-endian stuff. Sometimes files contain big-endian and small-endian within the same damn chunk(e.g. image x and y size might be big-endian, but just to annoy you data chunk size is small endian)).
You also need the user to be able to type in 2 textures and that's about it really. Converting an indexed texture to 24-bit then filtering it up to the size of the source texture used to create it and with bilinear can easily be done in photoshop instead of you coding for it.
False. r_detailedtextures work on my card, and I dont remember being told that my Radeon VE can do pixel shaders. IIRC, pixel shaders are for R8500 and up.
edit: It has software support for it(urgh), if your not taking a pretty sizeable performance hit with detail textures I guess their made using some open gl extension that was introduced at the time around radeon 7000/geforce 3. This means that anisotropic filtering should work for detail textures which is nice...
Performance hit of roughly <5fps. So it may be what you said.
1) C#
2) VB#
3) PHP
All three languages have built-in graphics handling, so it should be quite simple to do scaling and such. Yes, I could write this in C++ and read some docs on the TGA format, but I'm lazy and I'm going for RAD here, especially with what would appear to be on the surface such a simple program. I've considered PHP as an option because it's underestimated as a desktop development platform, and a while back I wrote an application to encapsulate a PHP script inside a single EXE along with the interpreter. Probably I'll choose C# or VB# though.
Added (very much experimental at best, haven't even looked at all the maps in action myself) detail texture lists for co_ maps.
Made a larger infested detail texture, it should be pretty darned difficult to spot the tiling with this now.
("less bumpy" set not updated)
/me goes to download
Until I get working on the res/depth technique, your textures are king Soylent, and they sure look nice in-game <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Plus, small differences in the original texture will make repetition of the detail texture less obvious.
The only thing I can think of is that I for some inane reason didn't choose overwrite when I uploaded it.
Damn valve for forcing us to take measures we dwouldn't have to if they'd just take 5 minutes and change the constant that says "256" and "8" to "512" and "24"!
OK, so it's more complicated than that, but it's still a rediculously easy thing to change.
<img src='http://www.llamalicious.com/images/carved.jpg' border='0' alt='user posted image' />
* this is of the metal texture that is primarly used in ns_mineshaft. It gets stretched pretty wide in mineshaft and it looks, well, pretty terrible.
<img src='http://www.llamalicious.com/images/mineshaft.jpg' border='0' alt='user posted image' />
I might try to just make some different details for this kind of metal,but I dunno what to try to apply to it. I mean, even with the degraded one i made, it still seems pretty rugged and although the metal is supposed to look old, worn, and/or rusted, i'm not sure if this is the right effect.