How Would You Go About This?
Parasite
Join Date: 2002-04-13 Member: 431Members
Join Date: 2002-04-13 Member: 431Members
<div class="IPBDescription">sequesnce lighting effect...</div> I want to have a series of lights "trailing" down a hallway.
Each light would be ON for 1/2 second, and OFF for 4 seconds before coming back ON for 1/2 second and so on.
Each consecutive light would be use the same pattern, but be on a 1/2 second delay from the light before it.
The effect when looking down the hall would be that the closest light "flashes" on, then goes off and the next closest light imediatly flashes on, then goes off, then the 3rd closest light flashes on, and so on all the way down the hall untill the sequesnce starts over again 3 seconds later.
there would be 12-18 lights in the sequence.
Hopefully that makes it clear (theres a hallway that has a similar effect in Alien Resurection)
Any ideas how I could go about acheiving such an effect? Id like to add fog to the overall effect as well, but Im mainly concerned with getting this light sequence down. Im not nearing any limits as far as entities and such go so any and all ideas are welcome.
Each light would be ON for 1/2 second, and OFF for 4 seconds before coming back ON for 1/2 second and so on.
Each consecutive light would be use the same pattern, but be on a 1/2 second delay from the light before it.
The effect when looking down the hall would be that the closest light "flashes" on, then goes off and the next closest light imediatly flashes on, then goes off, then the 3rd closest light flashes on, and so on all the way down the hall untill the sequesnce starts over again 3 seconds later.
there would be 12-18 lights in the sequence.
Hopefully that makes it clear (theres a hallway that has a similar effect in Alien Resurection)
Any ideas how I could go about acheiving such an effect? Id like to add fog to the overall effect as well, but Im mainly concerned with getting this light sequence down. Im not nearing any limits as far as entities and such go so any and all ideas are welcome.
Comments
Each light would be ON for 1/2 second, and OFF for 4 seconds before coming back ON for 1/2 second and so on.
Each consecutive light would be use the same pattern, but be on a 1/2 second delay from the light before it.
The effect when looking down the hall would be that the closest light "flashes" on, then goes off and the next closest light imediatly flashes on, then goes off, then the 3rd closest light flashes on, and so on all the way down the hall untill the sequesnce starts over again 3 seconds later.
there would be 12-18 lights in the sequence.
Hopefully that makes it clear (theres a hallway that has a similar effect in Alien Resurection)
Any ideas how I could go about acheiving such an effect? Id like to add fog to the overall effect as well, but Im mainly concerned with getting this light sequence down. Im not nearing any limits as far as entities and such go so any and all ideas are welcome. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Use a multimanager to toggle each set of lights on (4 seconds 1/2 second apart would mean 8 lights then the pattern repeats and you said 12-18, so you'll be using the same light targetname twice) half a second apart.
Also target a second multimanager on a half second delay to turn them off in the same sequence. Have the second multimanager target the first at the end of its sequence to make an infinite loop.
Edit: On further thought, I remember somebody else asking a similar question before, and the response he got was that such a room wouldn't compile because it would have too might lightdata in it. Recall that in the halflife engine, each face may have up to 8 light-styles on it; that could be 8 different colors/brightnesses of static light, or 3 switchable lights (because it has to store every combination of each light on or off, 3^2=8 styles); so, you could have three such lights in your chain, but if more than three of them cast light on the same face (which it almost definitely would - i.e. the floor), it would overload the light data. Again, try it and see, but that's what I recall.
Also, Ive never used multi_manager, so I dont really understand how I would do what XPCagey mentions.
//edit: In regards to you edit <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Would that give me an error? or just render weird?
<!--QuoteBegin--taleden+Sep 7 2003, 09:42 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ Sep 7 2003, 09:42 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->that in the halflife engine, each face may have up to 8 light-styles on it; that could be 8 different colors/brightnesses of static light<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
There are 4 lightstyles max per face including static light, leaving room for 3 dynamic styles per face.
<!--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-->#define MAXLIGHTMAPS 4
typedef struct
{
unsigned short planenum; // ZHLT1.6/Zoner: was signed in previous versions
short side;
int firstedge; // we must support > 64k edges
short numedges;
short texinfo;
// lighting info
byte styles[MAXLIGHTMAPS];
int lightofs; // start of [numstyles*surfsize] samples
}
dface_t;<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
<!--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-->because it has to store every combination of each light on or off, 3^2=8 styles<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Nope, light styles can be summed at runtime -- the combinations don't need to be stored.
<!--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-->that could be 8 different colors/brightnesses of static light<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Data is recorded for encoded as a red-green-blue sample in each style for each sample point, so a change in color or brightness doesn't add another lightstyle. You can combine an arbitrary number of truly static lights on a single face -- named lights are never considered static because they can be switched on and off by their targetname, requiring them to be stored separately.
<!--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-->if more than three of them cast light on the same face (which it almost definitely would - i.e. the floor), it would overload the light data. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
This is true, but remember that one surface can be made up of many faces. I made a map with dozens of spotlights that toggled independantly down a hallway a while back -- because the hall had beams spaced along the walls, the floor was cut by CSG and RAD ran without any errors. The map also ran really poorly in game though--possibly because of the work all those dynamic light types put on the engine.
----------------------------
<!--QuoteBegin--Parasite+Sept 7 2003, 9:50 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Parasite @ Sept 7 2003, 9:50 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Would that give me an error? or just render weird?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If you're using the latest copy of my tools, it will give you a warning in RAD and look wierd in-game if you did hit the limit.
<!--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-->Also, Ive never used multi_manager, so I dont really understand how I would do what XPCagey mentions<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Check around/post on the <a href='http://collective.valve-erc.com' target='_blank'>VERC</a> (game entity definitions and message board links are both in the page header) and you should find what you need.
Re: compilation - well, I would say to test the compilability, set up each of the lights with a different name and then make a separate button for each and every one of them. If you can get more than 3 named light entities or 'grouped' type texture lights to compile in one room, and are able to control each one individually with its switch, then you've got a winner.. I'm not sure exactly what it would do if you can't, I imagine hlrad would choke on it and tell you you're over the limit or something.
Re: multimanager - to use these you have to turn 'smartedit' off. With that done, you start adding variables whose names are the names of things you want to target (in your case, the lights) and whose values are delays at which to target them; so you would add variables like:
light1 = 0
light1 = 10
light2 = 10
light2 = 20
light3 = 20
light3 = 30
light1 = 30
multimanager = 40
where 'light1' etc are the names of your lights and 'multimanager' is the name of the multimanager itself (I believe it is possible to have a multimanager target itself, but if it only does one interation of the lights, then you know you'll just need a trigger_relay instead of that last variable, and have the trigger_relay then target the multimanager again.) The delays I just made up, I also forget what the units are in multimanager timing, but the basic idea is as soon as you turn the MM on, it turns the first light on.. 10 units later, it turns light 1 off and light 2 on, and so on.
Hope some of that helps <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
EDIT: Re: cagey
Well, I've committed the cardinal sin of making up details when I didn't really know them, so thanks cagey for explaining what the /actual/ rules are, and my apologies for anyone I would have misled otherwise. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I did a test map with one light overhead and two lights lit ever 128 units or so, all tied to different func_pres, and it compiled and worked perfectly, although technically the middle block should of had a potential 2 x 2 x 2 + 3 light maps on it (11). I was wondering if the light map works on the number of shades on a brush, rather than the number of light sources hitting a brush...
Also, the hallway with lights tied to a func_pres looks awesome thanks to 2.0. Standing there, watching the lights come closer and closer, but nobody there...
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
None of the above <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Light styles are based on the value of three fields : targetname, style, and pattern. Under Hammer's Smart Edit, those three fields are labeled Name, Appearance, and Custom Appearance.
If two light sources have the same settings for these three fields, they are the same lightstyle. Color/shade/brightness/fade/falloff don't matter.
EDIT: think of it this way... can one light source be getting brighter or darker over time while another isn't? If so, they are different lightstyles. If they can't change independantly, the light they cast will be summed ahead of time by the compiler into a single lightstyle for use on the face.
Also, could you possibly add support for switchable lights that specifically store the lighting difference between an opaque and transparent entity? I.E. Make a 'breakable' wall opaque, so it blocks light properly from both sides when still solid, but when it's broken, I can switch a light-style on and the lighting is correct then as well. I know it's an odd idea.
Maybe a variant on the zhlt_lightflags key, zhlt_opaquetargetname or similair, that lets me point at the named light entity to store the 'opaque' lighting difference on? Would allow for semi-dynamic lighting as doors open and similair, with simple fades of lighting styles. Or is something similair to this already buried in the existing tools somewhere, and I just missed it?
There are a couple approaches to this that I'm considering, and I'll probably implement more than one of them.
Option #1 for map authors would be to use a different texture as a placeholder, assign all of the dynamic light properties to the substitute texture explicitly in the properties files, and then use the same files to tell the tools to swap the texture to the final in-game image on export--this would be akin to using shaders but would require creating a temporary texture in Wally.
Option #2 that I've discussed privately would be using a point entity to mark textures with dynamic light properties--the entity's properties would be transferred to the nearest face by the tools, similar to what happens with an info_decal during runtime. The tools could strip out the point entity on export.
Option #3 is true tool-level shader support before conversion to standard Half-Life texture information in the final BSP--since you're a Radiant user I know that's something that you'd like to see <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->. This is probably the most powerful option, but wouldn't see a large initial audience. Without giving too much away, texture handling code is modular in the new tools, so this wouldn't be that tough for a 3rd party to accomplish even if I don't get to it.
<!--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-->Also, could you possibly add support for switchable lights that specifically store the lighting difference between an opaque and transparent entity? I.E. Make a 'breakable' wall opaque, so it blocks light properly from both sides when still solid, but when it's broken, I can switch a light-style on and the lighting is correct then as well. I know it's an odd idea.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's actually something that I'd like to see incorporated--I'm currently puzzling through the best way to make this work properly with my current design for lighting calculation--I could brute force it, but I've developed a *significantly* faster solution for static object opacity that I'd like to maintain for dynamic opacity if possible.
<!--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-->Maybe a variant on the zhlt_lightflags key, zhlt_opaquetargetname or similair, that lets me point at the named light entity to store the 'opaque' lighting difference on? Would allow for semi-dynamic lighting as doors open and similair, with simple fades of lighting styles. Or is something similair to this already buried in the existing tools somewhere, and I just missed it?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
No, the current opacity code is pretty primitive. In order to get the desired effect, you'd need to insert a light entity that doesn't emit anything and set up a trigger system so that it fires at the appropriate time--for doors, this would be turning on when it opens and off when it closes. For a func_breakable, it'd be turning on when it's broken. To save my sanity, I think I'll put the responsibility for hooking up entities correctly on the mapper, and have an optional property attached to the light that turns it into the difference the opaque object makes on its surroundings. The presense of a light with this setting will trigger the dynamic opacity lighting.