 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Geoff Wedig" wrote:
> I've wondered, and posted, this question myself,
> but no one ever answered.
:(
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Without having had a look at the sources (neither MegaPOV's
nor your scene file) could it be that
a) you have a point_at statement in your area light?
and
b) the area light is always oriented perpendicular to
that point_at vector?
Or are the two dimensions of the area light very different,
and orient rotates the rectangle in an unexpected manner
(as you suspect in your last question) ?
-Hans-
Rune wrote:
>
> What exactly does orient do to area_lights? According to the MegaPov docs it
> makes sure the area_light plane is perpendicular to the point which is being
> tested for a shadow.
>
> However, in the image posted to p.b.i I would have expected the shadow of
> the object to the right to be blurred evenly in all directions like the
> object at the bottom, but that isn't the case. Why not?
>
> Also, when using area_lights where one dimension is bigger than the other
> (area_light is rectangular) how is the rectangle oriented, and can it be
> controlled in some way?
>
> Rune
> --
> \ Include files, tutorials, 3D images, raytracing jokes,
> / The POV Desktop Theme, and The POV-Ray Logo Contest can
> \ all be found at http://rsj.mobilixnet.dk (updated March 29)
> / Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> "Joshua English" wrote:
> > After the are light keyword you can input two vectors,
> > they don't have to be strictly along the x and z axis,
> > so you can use <0,0,4> and <0,1,4> and it will create
> > the two rows of lights oriented along those paths.
>
> I know how a regular area_light works. What I'd like to know is how it is
> oriented when the orient keyword in MegaPov is used. Especially if the
> area_light is rectangular.
>
Using the "orient" keyword, the area_light shape remains unmodified,
but whenever a ray is computed to this light source, the area is
made orthogonal to this ray (rotation about the center of the area,
you cannot specify the angles to use/fix).
It's hack to have a kind of quick volumetric light
The picture in p.b.i is false:
the area light do not become circular (their is a keyword for that),
it is rather a superposition of rectangular shape, rotated around the same
point and whose normal is the tested ray.
Beware of optimisations with big area_light and small objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Rune wrote:
>>
>> "Joshua English" wrote:
>> > After the are light keyword you can input two vectors,
>> > they don't have to be strictly along the x and z axis,
>> > so you can use <0,0,4> and <0,1,4> and it will create
>> > the two rows of lights oriented along those paths.
>>
>> I know how a regular area_light works. What I'd like to know is how it is
>> oriented when the orient keyword in MegaPov is used. Especially if the
>> area_light is rectangular.
>>
> Using the "orient" keyword, the area_light shape remains unmodified,
> but whenever a ray is computed to this light source, the area is
> made orthogonal to this ray (rotation about the center of the area,
> you cannot specify the angles to use/fix).
> It's hack to have a kind of quick volumetric light
Right, but what's the axis of rotation? if the area light is non uniform,
this makes a difference. Ie, if we have an area light that's twice as wide
as tall, and a point that's perpendicular to its normal, do we get a small
square or a big square, or something in between? When the area light is
uniform, it's obvious what it does, when the axes are of different lengths,
it isn't clear what the shape of the light appears to be when looked at from
a particular object.
The obvious axes of rotate are the axes of the area light itself, but again,
how much of each is used, and which is first (if, indeed, those are the axes
used, which is non-obvious)? Because the shape of the light is affected
greatly by the order and magnitude of these rotations.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Geoff Wedig" wrote:
> Right, but what's the axis of rotation? if the area
> light is non uniform, this makes a difference.
I mailed Eric Brown (the author of the patch) some time ago and got all the
answers (almost).
There's no way of controlling "the axis of rotation" or whatever you want to
call it. Because of this you are likely to get uncontrollable and
unpredictable results when using the orient feature, sometimes even with
square area_lights. Also, the orient feature will make the two axis of the
area_light perpendicular, even if they were not originally perpendicular.
It seems the orient feature was really intended to be used together with the
circular feature, which makes the area_light circular instead of
rectangular.
One question he didn't answer was why the image I had made had those
artifacts in it. The artifacts persisted even when I also used the circular
keyword.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig wrote:
>
> Right, but what's the axis of rotation? if the area light is non uniform,
> this makes a difference. Ie, if we have an area light that's twice as wide
> as tall, and a point that's perpendicular to its normal, do we get a small
> square or a big square, or something in between? When the area light is
> uniform, it's obvious what it does, when the axes are of different lengths,
> it isn't clear what the shape of the light appears to be when looked at from
> a particular object.
>
> The obvious axes of rotate are the axes of the area light itself, but again,
> how much of each is used, and which is first (if, indeed, those are the axes
> used, which is non-obvious)? Because the shape of the light is affected
> greatly by the order and magnitude of these rotations.
The answer is in the code (lighting.c file), there is even clear comments.
let a1 and a2 the original axis of the area light
let r be the vector of the ray
let n1 and n2 be the reoriented axis of the area light, and t a temporary
vector.
the formula is like (all operands are vectors)
t = a1 x r
n1 = t x r
t = a2 x r
n2 = t x r
(the code is more sophisticated, because it has to deal with various vector
lengths,
whereas the above formula are fine only with unit-vectors)
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...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
