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

On 3-5-2017 22:50, Stephen wrote:
> 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.
>

Oh well... once again I shall have to scrounge for some new ones.

-- 
Thomas

Post a reply to this message

On 5/4/2017 7:47 AM, Thomas de Groot wrote:
> On 3-5-2017 22:50, Stephen wrote:
>> 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.
>>
>
> Oh well... once again I shall have to scrounge for some new ones.
>

I am sure you will get round to it. :)

-- 

Regards
     Stephen

Post a reply to this message

On 5/4/2017 7:44 AM, Thomas de Groot wrote:
> 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.
>

That would be a plus.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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.
>
i will pile-on and say i too was surprised and dismayed at this behavior.  the
workarounds generally require much extra work.  i had ascribed the obviously odd
behavior to logical necessities in coding... or some other blahblahblah.

Post a reply to this message

Le 17-05-04 à 03:49, Stephen a écrit :
> On 5/4/2017 7:44 AM, Thomas de Groot wrote:
>> 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.
>>
> 
> That would be a plus.
> 

Proposed key word : global_shadows on/off
Default is ON

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

>
> Proposed key word : global_shadows on/off
> Default is ON

Exactly! My thought too.

Post a reply to this message