 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Alain <kua### [at] videotronca> wrote:
>
> >
> > Proposed key word : global_shadows on/off
> > Default is ON
>
> Exactly! My thought too.
thinking more like
light_group{ BOOLEAN tokens...
where a missing BOOLEAN would denote the default.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"green" <rov### [at] gmailcom> wrote:
>
> thinking more like
> light_group{ BOOLEAN tokens...
> where a missing BOOLEAN would denote the default.
An interesting idea; less keyboard typing to do.
However, there is already a 'global_lights' keyword for light_groups, so its
'mate' should be a similar phrase (in my opinion), which would seem logical, as
the two phrases are so closely related as to the meaning of their operations.
Of course, this is all hypothetical right now. Clipka and the other developers
are probably thinking, "What?! ANOTHER new feature to add??" :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.05.2017 um 20:57 schrieb Kenneth:
> Of course, this is all hypothetical right now. Clipka and the other developers
> are probably thinking, "What?! ANOTHER new feature to add??" :-P
No, actually I'm thinking "Yup, I guess we should implement something
like this"; I haven't looked too much at the details though to decide on
any particular syntax.
What I can say for sure is that it won't be in 3.7.1, and that it will
/not/ be `light_group { BOOLEAN ... }`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17-05-05 à 09:03, green a écrit :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> Alain <kua### [at] videotronca> wrote:
>>
>>>
>>> Proposed key word : global_shadows on/off
>>> Default is ON
>>
>> Exactly! My thought too.
>
> thinking more like
> light_group{ BOOLEAN tokens...
> where a missing BOOLEAN would denote the default.
>
>
>
>
Putting a naked boolean is a big no no.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
