 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I wonder if there is not a bug in the formula when r is k.a1 or k.a2 (but
> maybe this is already tested, and the correction is obviously to replace
> the null vector with the cross product of r and the other new axis)
>
> Alas, I do not have the code at hand right now...
Well, if anyone has interest about that patch, I see two bugs and more
in the code of megapov 0.7 :
- first, minor impact: the length of the second vector is lost
the oriented area light is a square (or circle if "circular" is used)
(Looks like a copy-paste of code was made too quickly)
- second, crash expected: the result of the cross-product is not checked
against the null-vector and there is a macro that will normalize
the length of the new vector; if the new vector is null, there
will be a division by 0... With float values, the chance are low
that this will happen, but they still exist.
- more: I do not understand why the code wastes some time to
first invert (scale -1) the ray direction, do its calculation and
then invert again the ray direction.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> J?r?me Grimbert wrote:
>
>> I wonder if there is not a bug in the formula when r is k.a1 or k.a2 (but
>> maybe this is already tested, and the correction is obviously to replace
>> the null vector with the cross product of r and the other new axis)
>>
>> Alas, I do not have the code at hand right now...
> Well, if anyone has interest about that patch, I see two bugs and more
> in the code of megapov 0.7 :
> - first, minor impact: the length of the second vector is lost
> the oriented area light is a square (or circle if "circular" is used)
> (Looks like a copy-paste of code was made too quickly)
> - second, crash expected: the result of the cross-product is not checked
> against the null-vector and there is a macro that will normalize
> the length of the new vector; if the new vector is null, there
> will be a division by 0... With float values, the chance are low
> that this will happen, but they still exist.
> - more: I do not understand why the code wastes some time to
> first invert (scale -1) the ray direction, do its calculation and
> then invert again the ray direction.
Thanks for the info. This is quite helpful to me, as I've often wondered
about this ever since I encountered it several months back. Hopefully some
of the 3.5 team will fix these issues (are the area_light changes in 3.5? I
assume so, since they've been around awhile, but I don't know it)
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig schrieb in Nachricht <3aded3fc@news.povray.org>...
>Thanks for the info. This is quite helpful to me, as I've often wondered
>about this ever since I encountered it several months back. Hopefully some
>of the 3.5 team will fix these issues (are the area_light changes in 3.5?
I
>assume so, since they've been around awhile, but I don't know it)
According to the Status Report they will be part of 3.5.
Marc-Hendrik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Marc-Hendrik Bremer <Mar### [at] t-online de> wrote:
> Geoff Wedig schrieb in Nachricht <3aded3fc@news.povray.org>...
>>Thanks for the info. This is quite helpful to me, as I've often wondered
>>about this ever since I encountered it several months back. Hopefully some
>>of the 3.5 team will fix these issues (are the area_light changes in 3.5?
> I
>>assume so, since they've been around awhile, but I don't know it)
> According to the Status Report they will be part of 3.5.
Thanks. I was just too lazy to go look it up. ;)
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
