Eh, that just makes it well...solid <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
Use the additive rendering method but instead of using 255 as the value, use something else like 90 and you get a very much tranparent glass. It then whon't look like it glows in the dark. The solid rendering mode is only for stuff where you want parts of the texture to be invisible and others rendered normally.
Thanks, but that gives me the same result as texture-fullbright. It's a cool effect, but not in the situations I'm looking for. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
What about using the texture rendermode? I find that a renderamt of about 75 makes for nice (non-fullbright) glass. Additive is only really useful for computer screens/holograms, while solid is supposed to be used for gratings/railings.
Maybe it's the compile tools or a setting I've missed? For as long as I've mapped, every func_wall that I've given a texture value to has been fullbright if the fx amount's less than 255. It just hasn't really bugged me until now. I don't know how to keep the damn thing from "glowing in the dark".
<!--QuoteBegin--curlydave+Dec 17 2003, 06:23 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (curlydave @ Dec 17 2003, 06:23 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Maybe it's the compile tools or a setting I've missed? For as long as I've mapped, every func_wall that I've given a texture value to has been fullbright if the fx amount's less than 255. It just hasn't really bugged me until now. I don't know how to keep the damn thing from "glowing in the dark". <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Additive and texture render modes ignore light data on the partically transparent surfaces they describe -- it's a limitation of the engine, and it's actually the reason the valve .wads have glass textures labeled "light", "medium", and "dark"; those glass textures were meant to be used in rooms whose light conditions matched the texture. There isn't anything you can do to fix the problem short of changing the engine, which isn't practical (EDIT: unless you're valve <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->).
If you really need to have darker glass, you can follow valve's lead and manually edit the texture in wally to make a dark copy that doesn't stick out in your dark room. Certainly not ideal, but unfortunately as good as it gets with the HL engine.
Thanks cagey for the detailed explanation! I think I might as well just scrap the room, because it looks terrible as it is, and it ruins the effect. With the gamma ramp I'm putting in the map, (it wouldn't really be NS without it) the glass is extremely bright, and I'm not sure that a dark texture would fix it.
I was under the impression that it was an engine limit too---that is until I saw transparent, yet not fullbright aliens in NS. How is it that aliens can be transparent withought full brightness (cloakcing from an aliens, and to a much lesser extent marines), yet not brushes?
<!--QuoteBegin--curlydave+Dec 17 2003, 06:55 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (curlydave @ Dec 17 2003, 06:55 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Thanks cagey for the detailed explanation! I think I might as well just scrap the room, because it looks terrible as it is, and it ruins the effect. With the gamma ramp I'm putting in the map, (it wouldn't really be NS without it) the glass is extremely bright, and I'm not sure that a dark texture would fix it.
I was under the impression that it was an engine limit too---that is until I saw transparent, yet not fullbright aliens in NS. How is it that aliens can be transparent withought full brightness (cloakcing from an aliens, and to a much lesser extent marines), yet not brushes?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> They pass through a different render path <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
This has several different side effects:<ul><li>model polygons (e_poly) render faster than brush polygons (w_poly)<li>until DoD was released, models couldn't have alpha test transparency (equivalent to solid render mode on brushes)<li>the entire model is lit with a single light factor (if the knees of the model are dark, the head must be too; models can't process any sort of directional light under the Half-Life engine), but brush faces obviously can hold multiple light values</ul>Lighting a Half-Life engine model only requires a single constant brightness value for every poly in the model, so there's almost no overhead; just take the light factor between 0 and 1 for red, green, and blue and set it as the color multiple in your rendering API, which should multiply model textures by the constant light color for you.
In the case of brushes, lightmaps require much more overhead to draw; that may be why they can't be combined with transparency.
Or if you're really in trouble, just tweak the overall lighting of the room to match the glass so it doesn't stand out.
I had the same problem a while ago on my map NS_Democles (which is currently going nowhere and i'm thinking of turning it into a CO_ map instead <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> ). The overall lighting of the room was dark red with some white lights coming from the ceiling down to the floor, yet the glass was on the wall in a U shape not unlike the NS_Hera outside walkway. It really killed the room. So i moved the lights from the ceiling, down to the floor at a 45? angle shining TOWARDS the window.
Solved my problem, AND made the walkway even sexier! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
<!--QuoteBegin--XP-Cagey+Dec 17 2003, 09:09 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Dec 17 2003, 09:09 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> In the case of brushes, lightmaps require much more overhead to draw; that may be why they can't be combined with transparency. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Thought here -- tool plugin for the as-yet-unannounced-last-I-looked-XP-Cagey plugin architecture:
preprocessing: add a func_wall exactly where translucent entities occur (shaded by non-shadowing) postprocessing: create custom texture for translucent entity by multiplying lightmap on func wall and original glass texture. Remove func_wall
If I could finally figure out how the heck the lightmap data is encoded in the BSP this would take a few minutes to write up. Would look a little weird for some things until the translucent-object-RAD recognizes textures (hint hint <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->...
Comments
The solid rendering mode is only for stuff where you want parts of the texture to be invisible and others rendered normally.
Additive and texture render modes ignore light data on the partically transparent surfaces they describe -- it's a limitation of the engine, and it's actually the reason the valve .wads have glass textures labeled "light", "medium", and "dark"; those glass textures were meant to be used in rooms whose light conditions matched the texture. There isn't anything you can do to fix the problem short of changing the engine, which isn't practical (EDIT: unless you're valve <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->).
If you really need to have darker glass, you can follow valve's lead and manually edit the texture in wally to make a dark copy that doesn't stick out in your dark room. Certainly not ideal, but unfortunately as good as it gets with the HL engine.
I was under the impression that it was an engine limit too---that is until I saw transparent, yet not fullbright aliens in NS. How is it that aliens can be transparent withought full brightness (cloakcing from an aliens, and to a much lesser extent marines), yet not brushes?
I was under the impression that it was an engine limit too---that is until I saw transparent, yet not fullbright aliens in NS. How is it that aliens can be transparent withought full brightness (cloakcing from an aliens, and to a much lesser extent marines), yet not brushes?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
They pass through a different render path <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
This has several different side effects:<ul><li>model polygons (e_poly) render faster than brush polygons (w_poly)<li>until DoD was released, models couldn't have alpha test transparency (equivalent to solid render mode on brushes)<li>the entire model is lit with a single light factor (if the knees of the model are dark, the head must be too; models can't process any sort of directional light under the Half-Life engine), but brush faces obviously can hold multiple light values</ul>Lighting a Half-Life engine model only requires a single constant brightness value for every poly in the model, so there's almost no overhead; just take the light factor between 0 and 1 for red, green, and blue and set it as the color multiple in your rendering API, which should multiply model textures by the constant light color for you.
In the case of brushes, lightmaps require much more overhead to draw; that may be why they can't be combined with transparency.
I had the same problem a while ago on my map NS_Democles (which is currently going nowhere and i'm thinking of turning it into a CO_ map instead <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> ). The overall lighting of the room was dark red with some white lights coming from the ceiling down to the floor, yet the glass was on the wall in a U shape not unlike the NS_Hera outside walkway.
It really killed the room.
So i moved the lights from the ceiling, down to the floor at a 45? angle shining TOWARDS the window.
Solved my problem, AND made the walkway even sexier! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Thought here -- tool plugin for the as-yet-unannounced-last-I-looked-XP-Cagey plugin architecture:
preprocessing: add a func_wall exactly where translucent entities occur (shaded by non-shadowing)
postprocessing: create custom texture for translucent entity by multiplying lightmap on func wall and original glass texture. Remove func_wall
If I could finally figure out how the heck the lightmap data is encoded in the BSP this would take a few minutes to write up. Would look a little weird for some things until the translucent-object-RAD recognizes textures (hint hint <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->...