 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 <run### [at] iname com> 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?
I've wondered, and posted, this question myself, but no one ever answered.
It certainly does affect something, since I've had edge on shadows become
softer, but I don't know what it does with non-sqare area lights. I've
experimented a bit, but couldn't figure it out from inference.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
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.
josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
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:
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
