Opaque Don't Work?
Revenant
Join Date: 2003-01-13 Member: 12249Members
Join Date: 2003-01-13 Member: 12249Members
<div class="IPBDescription">Opaque Don't Work?</div> Opaque Don't Work? well thats what my map shows, I'm using the FGD supplied by eldritch which supports the opaque feature. Texture lighting and light_spot and light will not block the light being emitted through my light bars. Anyone got any ideas?
Comments
Try giving your opaque entitiy a name ond make its rendermode solid.
Set up for a basic func_illusionary/func_wall with transparency...
Render Mode = Additve for Black, Solid for Blue
FX Amount (1 - 255) = 255
Light Flags (Zhlt 2.2+) = Opague (Blocks Light)
Using the <i>Opague</i> feature will in fact block light...for the whole texture. Not just the transparent part.
If you want "bars" to cast shadows you will need to build them out of solid brushes. Then set a light source behind them.
FYI: I know for a fact that these light flags work using my .fgd, I've been working on maps all day. <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
[Center] Light Flags (Zhlt 2.2+) = Opague (Blocks Light).
[Right] Light Flags (Zhlt 2.2+) = Normal (Light shines through).
Brilliant! Thats a mappers dream come true!
I'd be really interested to know how this is even possible in the HL engine. As far as I know, light maps are built into the bsp during the rad compile phase, and can't really be altered in game in any truly meaningful manner (flashlights aren't particularly well suited to a purpose such as this, I would imagine).
And also, since textures can be changed and replaced without needing to update the bsp, would this be reflected by the code in the game? I mean, is this a compile code change, that takes into account the texture during the compile phase, or is it some kind of voodoo magic which determines lightmaps on the fly in game?
Either way, this sounds a little too good to be true. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I want to see that RAD that shines through blue parts of a Texture.
It could be done by making the rad checking the texture of a brush and then, just for rad calculation, replace the brush by MANY small brushes (carved holes at the blue parts) all having opaque enabled. (its simular to Texture lights, were RAD places many small "virtual light spots" all over the texture)
This would make RAD take years, but well, look nice.
I'd be really interested to know how this is even possible in the HL engine. As far as I know, light maps are built into the bsp during the rad compile phase, and can't really be altered in game in any truly meaningful manner (flashlights aren't particularly well suited to a purpose such as this, I would imagine).
And also, since textures can be changed and replaced without needing to update the bsp, would this be reflected by the code in the game? I mean, is this a compile code change, that takes into account the texture during the compile phase, or is it some kind of voodoo magic which determines lightmaps on the fly in game?
Either way, this sounds a little too good to be true. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Greedo, like I said on the Off-Topic forum. Coders are getting smarter.
-------------------
Cheers for the feedback guys, next compile test i'll try the ideas.
You know, the only shot I saw of that... I received confirmation from the level designer who made it that it was just the standard additive func_illusionary method used to give the illusion of those shadows... Meh.
There is that whole problem that the patches aren't small enough to maintain that level of detail... as you can see by the jagged shadows coming off the grating in the left.
Theoretically, you -could- probably set -chop and -texchop to 1 or something... but I imagine no one here is actually stupid enough to try and compile a full-size map that way. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Heh, yeah, who needs doom, give the hl modding community another year or so and they'll have tweaked the engine so much it'll be the same quality lol
Not to mention the 65535 patch limit... at a 1 unit chop you'd <i>almost</i> be able to map a simple cube at 32 x 32 x 64 units -- a marine would have to duck <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->.
Shadow projection for immoble objects (both brush and mdl based) is possible at map compile time (if you don't mind the blocky shadows), but I wouldn't expect it anytime soon. I've been looking at how the patches are chosen-- they are actually squares projected into the S and T planes of the texture (not the normal plane of the wall, interestingly enough) and then spaced according to whatever settings the mapper has chosen, usually multiplied by the scale of the texture. I'm not sure what limitations exist on patch sizes and shapes, but I don't see why a more adaptive solution (e.g. patch edges along projected shadow lines) can't be possible unless the software engine is making assumptions about patch shapes.
Incluting "chop 1" and "texchop 1" ability to -say bye bye blocks- and some gimicks like realistic fog ,shining through blended Textures, realistic water surface (incl. reflections), moving sunlight...
Finally he will add a photorealistic Raytracer (realtime of course) for the right reflections on everything anytime<a href='http://collective.valve-erc.com/index.php?go=photorealism' target='_blank'> . </a>
<!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Coders are intelligent, but there are always physical limitations.
Thats why Sheeps dont jump to the moon all the time.
But that does not mean for XP-Cagey giving up improving sheeps jump ability.
Just woke up and re-read your post...
Are you trying to block light with a texture that is giving off light(texture lighting)? I hope not. lol
A screenshot of your problem would be helpful...
Actually, something that was just recently added to the Q3 compile tools was an interesting ability that might be useful for situations like this. Basically, variable chop settings across textures or across entities. I.E. A specific entity-type that would be auto-merged back into the main BSP instead of kept a seperate entity, but be given, say, a rotated or different-chop lightmap.
Combine that with HLRAD support for checking the alpha-mapping of a texture and the wierd lighting effects would really start to show up in maps. =^.^=