Light_origin

taleden

Can anyone verify whether the light_origin field actually works? Just now I was working on blocking light in a particular way by building an opaque func_wall. I started out with the func_wall in the position I needed it in to cast the right shadows, to make sure it was going to have the effect I wanted, and it did (I'm using a beta test copy of Cagey's next build, which fixes the opaque entity problem). So then I set the entity's light_origin to point to the center of the entity in that position : "0,576,-240", and moved the entity. When I compiled again, the entity no longer blocks light the way it did when it was physically there.

Has anyone ever used light_origin successfully to have an entity cast a shadow from a position other than the one it's physically in? If so, what syntax did you use for the light_origin value? Maybe the coordinate triplet I put in wasn't what it was looking for.

Thanks for any help
-tal

Cagey

<!--QuoteBegin--taleden+May 8 2003, 06:08 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ May 8 2003, 06:08 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Can anyone verify whether the light_origin field actually works?  Just now I was working on blocking light in a particular way by building an opaque func_wall.  I started out with the func_wall in the position I needed it in to cast the right shadows, to make sure it was going to have the effect I wanted, and it did (I'm using a beta test copy of Cagey's next build, which fixes the opaque entity problem).  So then I set the entity's light_origin to point to the center of the entity in that position : "0,576,-240", and moved the entity.  When I compiled again, the entity no longer blocks light the way it did when it was physically there.

Has anyone ever used light_origin successfully to have an entity cast a shadow from a position other than the one it's physically in?  If so, what syntax did you use for the light_origin value?  Maybe the coordinate triplet I put in wasn't what it was looking for.

Thanks for any help
-tal<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
from the source code, it appears that "light_origin" works in tandem with a "model_center" key:

<!--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-->// Allow models to be lit in an alternate location (pt1)
       if (*(s = ValueForKey(ent, "light_origin")))
       {
           entity_t*       e = FindTargetEntity(s);

           if (e)
           {
               if (*(s = ValueForKey(e, "origin")))
               {
                   double          v1, v2, v3;

                   if (sscanf(s, "%lf %lf %lf", &v1, &v2, &v3) == 3)
                   {
                       light_origin[0] = v1;
                       light_origin[1] = v2;
                       light_origin[2] = v3;

                       b_light_origin = true;
                   }
               }
           }
       }

       // Allow models to be lit in an alternate location (pt2)
       if (*(s = ValueForKey(ent, "model_center")))
       {
           double          v1, v2, v3;

           if (sscanf(s, "%lf %lf %lf", &v1, &v2, &v3) == 3)
           {
               model_center[0] = v1;
               model_center[1] = v2;
               model_center[2] = v3;

               b_model_center = true;
           }
       }

<snip> ... </snip>

       // Allow models to be lit in an alternate location (pt3)
       if (b_light_origin && b_model_center)
       {
           VectorSubtract(light_origin, model_center, origin);
       }<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->

If you don't specify a model_center, the origin recalculation for lighting doesn't take place. The source doesn't indicate how long it's been done this way.

taleden

So, looking at that code, I take it I have to create an info_target or some dummy named entity and then put its name in as the light_origin, instead of just entering a coordinate pair? And if that's the case, what're the chances you could add a feature along with the next round of features that allows for coordinates? i.e. just detect the presence of two commas with numerical characters between them and treat that as coordinates, and otherwise look for a named entity, for backwards compatibility..

Pwetty please? *bats eyelashes*

crode

yes ive used light origin and it works quite well. Ive taken my lifts and put them in a nulled brush outside the map. I used the name of one of the info_corner for the lift as the entry for light origin

taleden

Yep, an info_target did the trick. However I thought of another potential improvement to the light_origin code - if an entity name is specified as opposed to coordinates (which was my other request), right now it looks like it scans the entity list for the first so-called entity and uses that entity's center as the target. But what if more than one entity shares that name? In my case, what I am trying to do is simulate my hangar doors blocking light without making the doors themselves opaque, because then when they're opened the inner faces are pitch black and that looks ugly. So instead I have a specially shaped brush that I place directly inside the doors which blocks light from above or below getting past the midpoint of the doors, while still allowing inner faces to be lit through the non-opaque doors. The most entity-efficient way to do this would be to specify the name of the doors, but unfortunately they are double doors and therefore two separate entities, so my light-blocking brush gets placed at the center of one door, not the center of both doors (which is the center of the opening the doors fill). So, instead, it would be nice if it detected multiple entities with the given name and somehow averaged their coordinates or something to create a more logical handling.

Of course, if coordinates are made possible then that would probably be sufficient to handle any placement at all, so maybe this other functionality would be redundant. *shrug* Just an idea. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->

NerdIII

wasn't there some min_light entry for brush-entities to work around blackness?

taleden

There is a min-light field, however as far as I know it only accepts a numerical value and this is rendered with white light; in my case the inner edges needed to be lit with the red light that should physically be striking those surfaces when the doors are open. In general, min-light is not a replacement for having rad actually light the faces, if it's possible to have it do so. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->