 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
While building a mesh macro earlier, I noticed a bug when using the
area_illuminate keyword with an open object. The new keyword treats all
open objects as if they have double_illuminate enabled in their object
definitions. This probably explains my confusion during earlier attempts
to use area_illuminate with shadowless light sources.
Since I found no mention of this in the change log, I will assume it has
not yet been observed.
I am running 3.7.beta.24 on Windows XP.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge <stb### [at] hotmail com> wrote:
> While building a mesh macro earlier, I noticed a bug when using the
> area_illuminate keyword with an open object. The new keyword treats all
> open objects as if they have double_illuminate enabled in their object
> definitions. This probably explains my confusion during earlier attempts
> to use area_illuminate with shadowless light sources.
It's not a bug, it's intentional. I forgot to mention this in the release
notes.
Area lights with area_illumination treat all objects as if they were
double-illuminated. The reason for this is that without this objects would
have ugly sharp shadow lines (much sharper than with a point light!).
The problem happens when povray has to decide whether a normal vector
is pointing towards a light source (in which case illumination is calculated)
or away from it (in which case illumination from that light source is
completely skipped). There are three possible solutions for this:
1) Treat all objects as double-illuminated. The advantage of this is that
the decision is very fast to make, and closed surfaces will self-shadow
and present no problems. Only open surfaces present problems.
2) Calculate whether any part of the area light is visible from the current
point by a more complicated algorithm. (Maybe testing against each corner
of the area light could be enough, except in the case of the circular
area light.) This will make the whole rendering slower because the
algorithm would be spawned for each intersection point between a ray
and a surface. It also may cause artifacts on the "dark side" of open
surfaces, in which case it's not really a solution at all.
3) Just treat the area light as if it was a basic grid of point lights
which results in perfect lighting (at least if the grid is dense enough),
but there would be absolutely no speed benefit in having a specialized
area_illumination feature as the exact same effect (including speedwise)
could be accomplished by simply creating a grid of point lights.
Which one do you prefer?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 1) Treat all objects as double-illuminated. The advantage of this is that
> the decision is very fast to make, and closed surfaces will self-shadow
> and present no problems. Only open surfaces present problems.
>
> 2) Calculate whether any part of the area light is visible from the current
> point by a more complicated algorithm. (Maybe testing against each corner
> of the area light could be enough, except in the case of the circular
> area light.) This will make the whole rendering slower because the
> algorithm would be spawned for each intersection point between a ray
> and a surface. It also may cause artifacts on the "dark side" of open
> surfaces, in which case it's not really a solution at all.
>
> 3) Just treat the area light as if it was a basic grid of point lights
> which results in perfect lighting (at least if the grid is dense enough),
> but there would be absolutely no speed benefit in having a specialized
> area_illumination feature as the exact same effect (including speedwise)
> could be accomplished by simply creating a grid of point lights.
>
> Which one do you prefer?
Well, since 3) would be the same as a grid of area_lights, I consider it
no new solution. Seeing how 2) produces artifacts in every case, I
rule it out. Which leaves me cheering for 1). How often do I really use
open objects? Rarely, and only under certain circumstances.
The only problem I can see is when you have a semi-transparent object.
The forced double illumination shows up there. This is no big deal for
me though.
Thanks~
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 3) Just treat the area light as if it was a basic grid of point lights
> which results in perfect lighting (at least if the grid is dense
enough),
> but there would be absolutely no speed benefit in having a specialized
> area_illumination feature as the exact same effect (including
speedwise)
> could be accomplished by simply creating a grid of point lights.
Why is that? I thought the speed benefit came from the adaptive sampling.
You can still do the adaptive sampling, but you basically move the normal
dot product check to the point where you trace an individual ray. So instead
of
if ( CheckNormalDirection( lightCenter ) || doubleIlluminated )
{
For each samplePoint in ComplicatedAdaptiveSampling()
{
TraceShadowRay( samplePoint )
}
}
you have
For each sample point in ComplicatedAdaptiveSampling()
{
if ( CheckNormalDirection( samplePoint ) || doubleIlluminated )
{
TraceShadowRay( samplePoint )
}
}
Obviously I've simplified the problem a lot so it might not be that easy,
but it seems like all you have to do is take the current implementation and,
if double illumination is off, add a dot product check between the normal
and the direction to the sample point before tracing a shadow ray.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It may be actually possible to do something like you suggest. I'll look
into it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Using Slime's suggestion I was actually able to fix the double illumination
problem, and it even doesn't cause a significant slowdown.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Using Slime's suggestion I was actually able to fix the double illumination
> problem, and it even doesn't cause a significant slowdown.
>
Yes! And you had me believing it couldn't be done ;) Cheers to the both
of you!
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
