Compile Tool Suggestion (hlrad)
venomus
Join Date: 2002-11-16 Member: 8951Members
Join Date: 2002-11-16 Member: 8951Members
<div class="IPBDescription">Cagey?</div> At the moment, mappers use overlays to get better effects with texlights etc (see <a href='http://www.snarkpit.com/tutorials.php?usertut=1&tut=98' target='_blank'>here</a>). This is not without its disadvantages (increased entity counts, r_speeds etc), surely there could be a better way of doing it? Here is what I propose:
1.) A switch to stop texlights being automatically fullbright (should be trivial?)
2.) The ability to specify a 'brightness map' for any texture. A brightness map would be a greyscale image, of the same dimensions of its corresponding texture in the wad. The value of each pixel in the brightness map represents the minimum value the corresponding pixel in the texture can be lit at (where black is no light at all and pure white is fullbright). So by default, all textures have what equates to a pure black brightness map.
The way I suggest implementing this system is as follows: HLRAD can be given the parameter -brightmap xxx.txt (path/file name etc, the file extension is irrelevant as long as the file contains text). This specifies a brightness map 'manager file'. The manager file is filled with lines like this:
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
atexture bmaps\atexture_bmap.bmp
anothertexture bmaps\anothertexture_bmap.bmp
bluetexlight bmaps\bluetexlight_bmap.bmp
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
The references on the left are of textures (does this remind you of a rad file?). On the right are the path and filename of their corresponding brightness maps (which have been placed in their own folder just to keep things tidy). Of course, not every texture needs to have a reference in this file. It would however be useful for three things that I can think of. Firstly for overlays on texlights (used in conjunction with the no fullbright switch). Secondly to create glowing LEDs and small effects on any texture, that dont actually emit light but glow in the dark in a cool fashion. Thirdly to make any texture fullbright without having to actually make it light emitting. These points are pretty similar, but there u go <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> .
But here comes the big question: IS IT POSSIBLE???
1.) A switch to stop texlights being automatically fullbright (should be trivial?)
2.) The ability to specify a 'brightness map' for any texture. A brightness map would be a greyscale image, of the same dimensions of its corresponding texture in the wad. The value of each pixel in the brightness map represents the minimum value the corresponding pixel in the texture can be lit at (where black is no light at all and pure white is fullbright). So by default, all textures have what equates to a pure black brightness map.
The way I suggest implementing this system is as follows: HLRAD can be given the parameter -brightmap xxx.txt (path/file name etc, the file extension is irrelevant as long as the file contains text). This specifies a brightness map 'manager file'. The manager file is filled with lines like this:
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
atexture bmaps\atexture_bmap.bmp
anothertexture bmaps\anothertexture_bmap.bmp
bluetexlight bmaps\bluetexlight_bmap.bmp
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
The references on the left are of textures (does this remind you of a rad file?). On the right are the path and filename of their corresponding brightness maps (which have been placed in their own folder just to keep things tidy). Of course, not every texture needs to have a reference in this file. It would however be useful for three things that I can think of. Firstly for overlays on texlights (used in conjunction with the no fullbright switch). Secondly to create glowing LEDs and small effects on any texture, that dont actually emit light but glow in the dark in a cool fashion. Thirdly to make any texture fullbright without having to actually make it light emitting. These points are pretty similar, but there u go <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> .
But here comes the big question: IS IT POSSIBLE???
Comments
I was keeping it under wraps as it's not <i>quite</i> fully functional, but this tool is in development and mostly functional at this time. There's still an issue with the lightmaps that needs to be resolve that's rather critical to the success of the tool, but once that's resolved (if it can), the tool will be released publicly.
The actual function and implementation is somewhat different, but there'll be full documentation available if/when the tool is fully functional. There's another fun toy coming with it, based on an old recommendation for HLRad, but let's worry about that when the full tool works. <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Yeah, this project is Zipster's right now -- I saw some in-game screens about 2 weeks ago and it looks like he's made some good progress with it. As a mapper, I've got my fingers crossed hoping he'll get the kinks out. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I took a long look at RAD over a week or so and decided that I didn't want dive into it at the moment--I'd personally be more tempted to rewrite an optimized version from scratch than have yet another set of options to define in the preprocessor. I might optimize some of HLRAD's inner loop functions for speed (someone didn't simplify their equations when they wrote functions like <i>PointInPlane</i>, so there are extra multiplies and adds being executed a few million times when maps have a large number of faces...), but the bulk of the speed problem seems to be from virtual memory chugging people's HDs rather than CPU load, so I'm not sure if the effort is worth it.
Well, in my case it's purely a matter of CPU load limiting compile times for myself, even on a 2x1.4Ghz Athlon machine. Mind you, that's a little above what most mappers have, but folks are memory-limeted when 512MB of memory costs all of $50-$60 at the local CompUSA store?!? Gah, c'mon, some new video games cost more than that, skip the next installation of MechWarrior and boost your RAM. =^.^=
Athlon 1.3 Ghz with 512MB Ram, etc.. My compile times with this original rig weren't half bad, much better than the P1 166 w/ 24MB of Ram that I had started with. When RAM prices took a dive, I picked up another stick of 512MB of Ram, and lost on average about 5 minutes from RAD. I then bought another stick later on, and put me up to 1.5GB of Ram, and let me tell you, my computer has never run better. I can compile a map with nothing but texture based lighting, and func_illusionary galore in under 10 minutes. The culprit to RAD <i>is</i> the SwapFile. Now if I could only get a better processor to speed up VIS. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
I ran the modified CSG and HLRad on the Veil ready room after I copied in a computer panel from the main level for additional testing. (That computer texture and overlay, btw, is one of a pair that Squeal put together for Veil and both should be in the next publicly released .wad file for NS.) You can see the main issue with the function right now - it can't use overlays over lightmaps. It does, however, allow for setting the base brightness of the original face, which is why the base light and the base computer panel are both dark and fairly flat (much more noticeable on the panel).
It's interesting to note that not a single entity is visible in this shot. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> In addition to notably reducing entity counts in maps that use them, I do believe that Zipster's method currently may also allow for decreased texture memory relative to having to include both the texture and the overlay within the 4 megs for the level. It'll be interesting to see how that turns out. The process actually creates a new texture combining the original texture and the overlay - it retains the name of the original, so any lights.rad settings on the original will continue to work. It's possible that using overlays with this tool may not increase texture memory in maps at all beyond the original textures being used. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> Here's hoping that does work as planned.
Personnally, i would like to HL RAD modified so that textures can behave like light_spot entities and their direction, pitch, angle is determined by their position in the level, which would result in very realistic lighting.
Venomus sure has some good ideas, although specifiying a light level for every texture isn't the best way to go imho, Since surely, you will use the textures in your maps in more places then 1, and thus, each area has their own lighiting effect/color/strength.
I hate using up entities for effects like light overlays, especially since the effect isn't perfect as you'll sometimes notice the glow is raised 1 unit off the surface. Also the overlay glow can cause the colours to be washed out, or have weird edges where it ends.
Specifying the face brightness is bad, yes, and that's why this tool hasn't been released yet - Currently lightmaps also affect the overlays, so the only way to make them visible is to disable the lightmaps on the face and manually set the texture brightness. This actually works quite well on light fixtures where the light takes up most of the texture, but is completely unacceptable for faces where the glows are more sporadic.
For the overlays themselves, it's completely reasonable to expect that they'd be the same brightness in each instance of the texture being displayed. You don't, for example, worry about the same texture emitting different levels of brightness in lights.rad - Along those same lines, I use uniform settings for each overlay texture I use in a map. Each light value uses a consistent value, each monitor overlay uses a consistent value, etc.
I haven't talked to Zipster in a week or so, and the progress here is also a few weeks old. I can't remember how long ago I took that shot of the test map. :X Hopefully he's made some progress, and I know he's talked to other people in looking for ways to get around that evil lightmap issue.
or should i just shut up?
"Donnie you're out of your element! You have no frame of reference here, Donny. You're like a child who wanders into the middle of a movie..."
light bias 100%:
<img src='http://silencegreys.com/sa/wall_lab5.gif' border='0' alt='user posted image'>
light bias 50%:
<img src='http://silencegreys.com/sa/wall_lab5_bias.gif' border='0' alt='user posted image'>
Notice that the biased texture is artificially lit at 50% except for the blue part which is lit at 100%. If hlrad were to take the bias into account, then in-game, the wall would look normally lit except for the blue which would appear brighter than the nominal light level.
Of course, this is not accurate but it might look fine in practice and it would be very simple to implement.
Anyway, the overlay additions sounds marvelous for what it's worth, I hope the kinks are worked out post-haste.
At the very least the tool could generate the func_illusionary overlays automatically, saving mappers some work.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This is a debugging option, which will cause all black pixels in any lightmap to be set to a random fullbright color. It only looks at the direct lighting to make this determination, and ignores any bounced radiosity data for making this determination.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I haven't tried this out to see what it really looks like, but from the description it sounds as if individual pixels are having their color manipulated. If this is true, surely it would be possible to specify the pixels you want (ie, those which are part of an overlay) to be fullbright? Maybe Zoner meant patches instead of pixels?
Dang.
/me goes back to work <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This is a debugging option, which will cause all black pixels in any lightmap to be set to a random fullbright color. It only looks at the direct lighting to make this determination, and ignores any bounced radiosity data for making this determination.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I haven't tried this out to see what it really looks like, but from the description it sounds as if individual pixels are having their color manipulated. If this is true, surely it would be possible to specify the pixels you want (ie, those which are part of an overlay) to be fullbright? Maybe Zoner meant patches instead of pixels? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Unfortunately the lightmap texels are considerably bigger than typical texture texels so this wouldn't work.