"Kenneth" <kdw### [at] gmailcom> wrote:
> Alain <kua### [at] videotronca> wrote:
>
> >
> > This is the correct and expected behaviour and did not change since
> > light_group have been introduced.
> >
>
> I'm having trouble understanding the logic of this; but maybe it will become
> clearer to me, as I continue to think about it. ;-)

You need to consider the purpose of light groups: They exist to allow additional
local lights for objects, a technique that is frequently used in computer
animations to help make certain objects appear lit "better" - after all, there
is no physical equivalent of light groups in the real world.

What you are looking for is something like "shadow groups", though I suppose you
might want to rethink what you actually want to render.

Post a reply to this message

On 1-5-2017 9:40, Thorsten Froehlich wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> Alain <kua### [at] videotronca> wrote:
>>
>>>
>>> This is the correct and expected behaviour and did not change since
>>> light_group have been introduced.
>>>
>>
>> I'm having trouble understanding the logic of this; but maybe it will become
>> clearer to me, as I continue to think about it. ;-)
>
> You need to consider the purpose of light groups: They exist to allow additional
> local lights for objects, a technique that is frequently used in computer
> animations to help make certain objects appear lit "better" - after all, there
> is no physical equivalent of light groups in the real world.
>
> What you are looking for is something like "shadow groups", though I suppose you
> might want to rethink what you actually want to render.
>
>

As for me, that clarifies a lot indeed. Use a bit different than I 
expected. I have used light_group is a somewhat different context with a 
reddish sundown landscape and a 'midday' lighted moon. I think I got 
some unwanted artefacts but I resolved them with no_shadow and 
no_reflection.

-- 
Thomas

Post a reply to this message

"Thorsten Froehlich" <nomail@nomail> wrote:

>
> You need to consider the purpose of light groups: They exist to allow additional
> local lights for objects, a technique that is frequently used in computer
> animations to help make certain objects appear lit "better" -

That's basically what the documentation says, although the behavior of shadows
vis-a-vis a light_group isn't discussed there-- which seems like an important
topic, as shadow behavior may be 'unexpected', in an intuitive sense. (Well, at
least for me-- and maybe Thomas as well.) My immediate intuition when reading
the docs is basically this: that a light_group should *only* light the objects
in the group, AND *only* those objects should cast shadows from that light.
Obviously, it doesn't work according to my intuition...  ;-) I admit that I
haven't completely thought through the ramifications of my idea; there may
indeed be some logical conundrums with it. But its present behavior seems like a
conundrum (to me.)
>
> What you are looking for is something like "shadow groups", though I
> suppose you might want to rethink what you actually want to render.

That's very possible (and I could probably find a work-around to the scene
problem I encountered, using no_image and/or no_shadow as Thomas mentioned.) My
current scene-- which prompted me to post about this-- is an animation of an
expanding  'explosion' on the top of a tower (like the old A-bomb tests.) I
wanted a VERY bright fading light to flare on the ground (and only there), from
a position at the center of the explosion, so I made a light_group with the
ground-- but found that the explosion sphere and the tower were casting unwanted
harsh shadows... which I didn't expect (based on my... intuition...)

I think my past use of a light_group was always with a carefully-positioned
spotlight, so I probably never noticed the unexpected shadow behavior from other
scene objects. (Actually, I do recall once making a scene where I wanted a light
*underneath* the ground, to artifically light up some above-ground objects-- and
I did have to add no_shadow to the ground. But I thought that was because I had
made some kind of dumb mistake in my complex code.)

Post a reply to this message

Am 30.04.2017 um 18:15 schrieb Alain:

> This is the correct and expected behaviour and did not change since
> light_group have been introduced.

Kenneth and Tomas' posts are clear evidence (nay, proof) that it is
/not/ "expected behaviour" - or at least not universally so.

My personal guess is that light groups were originally implemented for a
use case where shadowing objects or media were a non-issue, and thus no
thought was given in that direction whatsoever. And that when the issue
first arose, light groups were well-established already, so that the
developers were reluctant to change the implementation, out of fear of
breaking existing scenes.

Post a reply to this message

Am 30.04.2017 um 17:04 schrieb Kenneth:

> Also, the light's looks_like object (yellow sphere) is showing lighting effects
> from the extra 'global light', even with 'global_lights off' in the light_group
> (although there's no shadow from that sphere, as far as I can tell.) I don't
> know if that is correct behavior or not.

I haven't examined the issue myself, but I wouldn't be surprised if
`looks_like` objects would always be hooked up into the global group
(again presumably because no thought had been given about the
interaction of these two features).

A workaround would be to replace the `looks_like` object with a
corresponding "regular" object in the same light group, with
`no_shadow`, `no_radiosity` and whatever other flags the `looks_like`
feature automatically sets.

Post a reply to this message

Am 03.05.2017 um 20:40 schrieb clipka:

> Kenneth and Tomas' posts are clear evidence (nay, proof) that it is
> /not/ "expected behaviour" - or at least not universally so.

(Sorry Tom, stole an "h" from you there...)

Post a reply to this message

On 5/3/2017 7:47 PM, clipka wrote:
> Am 03.05.2017 um 20:40 schrieb clipka:
>
>> Kenneth and Tomas' posts are clear evidence (nay, proof) that it is
>> /not/ "expected behaviour" - or at least not universally so.
>
> (Sorry Tom, stole an "h" from you there...)
>
Now you have stolen an as.
A tisk a tisk.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> ...And...when the issue
> first arose, light groups were well-established already, so that the
> developers were reluctant to change the implementation, out of fear of
> breaking existing scenes.

I had the same thought. The light_group feature *has* been around a long time,
and changing it would cause old scenes to 'look' quite different. (Not mine, of
course... ha!)

Putting myself in the position of 'Devil's advocate' for BOTH sides, I can see
that one group of people might want its behavior changed to *MY* way (oops, I
mean, my way and Thomas's way!), and another group might just as strongly be in
favor of keeping its shadow behavior as-is. Either way, *someone* would probably
be unhappy! ;-) I guess it would boil down to which 'version' of light_group
behavior turned out to be easiest to work around (i.e., the desire for shadows
vs. no shadows.) In other words, would it be easier to eliminate unwanted
shadows, or to *add* them if they're not already there? POV-Ray's other features
like no_shadow, no_image, shadowless, etc. would seem to argue for the former
case (which is the current light_group behavior.) But those other tools may be
inadequate for certain kinds of scenes.

It's difficult to imagine *all* the different use cases that might arise, with
either version of a light_group-- especially with *nested* light_groups; they
can be 'logically complex' in either scenario.

But I still vote for 'no shadows'. ;-)

Post a reply to this message

Here's a really naive thought: Would it be possible to add an on-off switch to
the current light_group implementation, to either allow the 'global' shadows
(as-is), or to turn them off (for objects not in that light_group?)

My thinking is this: Since a light_group's LIGHT is already restricted to only
the group's objects, could the shadow calculations from the light also be
restricted like that? If so, we could choose which behavior to use-- 'the best
of both worlds', so to speak. And it wouldn't break backward compatibility.

Post a reply to this message

On 4-5-2017 6:14, Kenneth wrote:
> Here's a really naive thought: Would it be possible to add an on-off switch to
> the current light_group implementation, to either allow the 'global' shadows
> (as-is), or to turn them off (for objects not in that light_group?)
>
> My thinking is this: Since a light_group's LIGHT is already restricted to only
> the group's objects, could the shadow calculations from the light also be
> restricted like that? If so, we could choose which behavior to use-- 'the best
> of both worlds', so to speak. And it wouldn't break backward compatibility.
>

My thoughts entirely.

-- 
Thomas

Post a reply to this message