 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I stumbled upon this in v3.6.1c while running an animation. Didn't see this
specific set of interrelated circumstances mentioned in a google search, or
in the 3.7 beta fixes.
If an area_light has a looks_like object, and that object is as large or larger
than the area_light grid size, the render takes at least twice as long as
without it, for even the simplest object. (The entire image takes longer to
render.) It's as if the program is doing some unneeded calculations (shadow
calculations?) even though the object has an implied no_shadow. Actually, this
slow-down occurs with *any* no_shadow object that happens to invade the
area_light's 'volume of space.'
The problem only shows up if automatic bounding is on; otherwise not. (Since
most scenes have enough objects to turn it ON, it's definitely annoying.) For
my tests, I turned Bounding_Threshold to zero (so it's 'on' regardless of the
number of objects), then switched Bounding on or off.
On a more detailed level: Given that jitter is OFF in the light (for
simplicity's sake), if the object is made small enough to fit 'inbetween' the
grid of lights, the problem almost disappears. As the object size increases,
enclosing more and more light points, the render time starts increasing. (I
realize that an area_light is, in reality, just a single point_light source;
but this effect does seem to take into account its 'multiple' points.) From a
practical standpoint, a complex object may or may not enclose some of the
lights, depending on the object's shape and size. And with jitter ON, I really
don't know *what* happens!
Adding an *additional* no_shadow to the looks_like object didn't help. (BTW,
making the area_light shadowless eliminates the entire problem, whether auto
bounding is on OR off.)
Not sure if circular or orient affects this, since my own looks_like test object
is just a simple sphere (where those terms wouldn't matter?) I'm guessing that
they might have an effect when using a more complex shape. Fade_distance and
fade_power don't seem to affect it either, although I haven't run enough tests
to positively say yea or nay.
BTW, this strange problem isn't there with a regular point_light source, even
though its look_like object always encloses the light.
Here is a very simple test scene, stripped to its essence, to show the effect.
(The looks_like object takes up very little screen space.) With a 6X6
area_light grid, there isn't a light 'point' in the exact center, so it's good
for testing. A sphere of < .100 radius will enclose NO lights; a radius > .707
will enclose ALL the lights. The test renders very quickly, so you will probably
need to run an animation--of, say, 50 frames--to see the render time
differences.
These are my own full animation-render times, in minutes:
1:05 auto bounding OFF, no looks_like
1:05 auto bounding OFF, with looks_like, radius .71 (no change)
1:48 auto bounding ON, no looks_like (an expected difference)
2:02 auto bounding ON, with looks_like, radius .09 (not much difference)
4:43 auto bounding ON, with looks_like, radius .71 (big difference)
4:43 auto bounding ON, with looks_like, radius 1.3 (no change)
Ken W.
-------
camera {
perspective
location <0, 1, -55>
look_at <0, .2, 0>
right x*image_width/image_height
angle 37
}
light_source {
0*x
color rgb .9
area_light
<1, 0, 0> <0, 0, 1>
6, 6
adaptive 1
//jitter // Turned off so that the light points remain in a fixed grid.
circular
orient
//shadowless
looks_like{
sphere{0,.71 // change radius to see effect
texture{
pigment{color rgb <.5,.5,1>}
finish{ambient 1 diffuse 0}
}
}
}
translate <0, 2, -3>
}
// background box
box{0,40 no_shadow translate -20 scale <1,1,.01>
texture{
pigment{color rgb 1}
finish{ambient 0 diffuse 1}
}
translate 3*z
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlink net> wrote:
> If an area_light has a looks_like object, and that object is as large or larger
> than the area_light grid size, the render takes at least twice as long as
> without it, for even the simplest object. (The entire image takes longer to
> render.) It's as if the program is doing some unneeded calculations (shadow
> calculations?) even though the object has an implied no_shadow. Actually, this
> slow-down occurs with *any* no_shadow object that happens to invade the
> area_light's 'volume of space.'
>
> The problem only shows up if automatic bounding is on; otherwise not. (Since
> most scenes have enough objects to turn it ON, it's definitely annoying.) For
> my tests, I turned Bounding_Threshold to zero (so it's 'on' regardless of the
> number of objects), then switched Bounding on or off.
I had a look at the code; obviously, when bounding is ON, POV "shoots first and
asks later": It first performs bounding tests using some standard core
functions, and filters out objects flagged with no_shadow later.
The reason that a smaller looks_like object speeds things up may be related to
the way POV does bounding box tests (didn't look at this, but e.g. POV might
first test whether a ray starts outside the box and faces away from it, before
testing whether and where it might actually intersect the faces of the box).
There seems to be another instance where the no_shadow flag is only tested after
some calculations have already been performed, which is when bounding is OFF and
the object in question is part of a CSG object.
(So basically, the only situation in which the no_shadow flag is actually tested
first, is when bounding is OFF and the object in question is a "root" object.)
From what I see in the 3.7 beta code, these issues have been addressed, by
building the no_shadow and similar filters into the core functions that
actually do the bounding box and intersection tests.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> The reason that a smaller looks_like object speeds things up may be related to
> the way POV does bounding box tests (didn't look at this, but e.g. POV might
> first test whether a ray starts outside the box and faces away from it, before
> testing whether and where it might actually intersect the faces of the box).
Though I'm still a bit perplexed as to why it happens with an area_light's
looks_like object, but not with a point_light's. Perhaps that's indicated in
your explanation; I'll have to re-read it.
> From what I see in the 3.7 beta code, these issues have been addressed, by
> building the no_shadow and similar filters into the core functions that
> actually do the bounding box and intersection tests.
That's good news! (I'm rather...shy...about running betas. Have you run my test
scene with the lastest one? I'm curious to know how it performs. You never
know... ;-) Thanks for taking the time to go through this problem. And thanks
to the POV team for the good changes!
Ken W.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> Though I'm still a bit perplexed as to why it happens with an area_light's
> looks_like object, but not with a point_light's. Perhaps that's indicated in
> your explanation; I'll have to re-read it.
I guess the reason is that with point lights, another optimization approach
called "LBuffers" can be (and is) used: Instead of testing for bounding boxes
intersection during tracing, all the bounding boxes are first projected onto a
cube around each light source, and during tracing only the projections of the
bounding boxes are tested. I didn't have a look at the corresponding code, but
I guess that no_shadow objects are filtered out during the projection (which is
possible because the LBuffers are used solely for shadow testing, while the
actual bounding boxes are used in various ray-object hit tests) so they don't
get in the way unnecessarily during the actual rendering.
> > From what I see in the 3.7 beta code, these issues have been addressed, by
> > building the no_shadow and similar filters into the core functions that
> > actually do the bounding box and intersection tests.
>
> That's good news! (I'm rather...shy...about running betas. Have you run my test
> scene with the lastest one? I'm curious to know how it performs. You never
> know... ;-) Thanks for taking the time to go through this problem. And thanks
> to the POV team for the good changes!
Actually it's not a big deal to install the beta. On Windows systems, it
installs completely in a separate directory. Similarly on Unix systems - except
that it renames any existing povray binary and installs itself as "povray", but
a simple re-rename after installation easily fixes this, so that you can have
"povray" run the original 3.6, and something like "povray-beta" run the 3.7
beta.
Anyway, I just took time to test your scene (I only looked at the code before);
on my Windows XP / P4 3.4 GHz system, the 3.6.1c needs 22 seconds for the scene
*at best* (i.e. bounding disabled or looks_like extremely small), whereas the
3.7.0 beta 29 spits out the result after just 6-8 seconds, with bounding
settings or looks_like size having no significant impact.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
>
> I guess the reason is that with point lights, another optimization approach
> called "LBuffers" can be (and is) used:...
Fascinating! You're explanation is clear and concise (although I have to admit
that some of this code stuff is a bit beyond me.) Nevertheless, I'm
learning...thanks to your well-written responses. (I nominate *you* to
re-write the POV documentation! Shouldn't take you long...heh heh...)
>
> Actually it's not a big deal to install the beta. On Windows systems, it
> installs completely in a separate directory.
Hmm, well --*gulp*--I guess I'm going to have to bite that bullet. Thanks for
the confidence boost. (My trepidation basically comes from the idea that I'll
get bogged down in its not-yet-working details--"Why doesn't this work?" "What
am I doing wrong?" etc.--and get completely frazzled, when even good ol' 3.6.1c
keeps me 'busy' in that regard. But I guess that the POV team *needs* beta
testers to find out such stuff, for the good of us all.)
>
> Anyway, I just took time to test your scene (I only looked at the code
> before); on my Windows XP / P4 3.4 GHz system, the 3.6.1c needs 22 seconds
> for the scene *at best* (i.e. bounding disabled or looks_like extremely
> small), whereas the 3.7.0 beta 29 spits out the result after just 6-8
> seconds, with bounding settings or looks_like size having no significant
> impact.
Great! And thanks for being so thorough. BTW, those are some impressive time
statistics. I'm still using a 'lowly' 2.2GHZ AMD single-core system. Perhaps
it's time to do the upgrade thing (again, *sigh*.)
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> Fascinating! You're explanation is clear and concise (although I have to admit
> that some of this code stuff is a bit beyond me.) Nevertheless, I'm
> learning...thanks to your well-written responses. (I nominate *you* to
> re-write the POV documentation! Shouldn't take you long...heh heh...)
I guess I prefer to reject that nomination :)
(Actually I think I'm not too good at explaining in general, unless I have a
specific question to answer, so general documentation... um... problematic.)
> Hmm, well --*gulp*--I guess I'm going to have to bite that bullet. Thanks for
> the confidence boost. (My trepidation basically comes from the idea that I'll
> get bogged down in its not-yet-working details--"Why doesn't this work?" "What
> am I doing wrong?" etc.--and get completely frazzled, when even good ol' 3.6.1c
> keeps me 'busy' in that regard. But I guess that the POV team *needs* beta
> testers to find out such stuff, for the good of us all.)
Well, from what I've seen so far the beta already makes a good "workhorse" for
standard-stuff scenes, and is mostly ok with more special effects as well. And
if there *are* things that seem strange to you, you can always check in the
3.6.1c for reference, before spending time to try fixing your scene.
> Great! And thanks for being so thorough. BTW, those are some impressive time
> statistics. I'm still using a 'lowly' 2.2GHZ AMD single-core system. Perhaps
> it's time to do the upgrade thing (again, *sigh*.)
On my brand-new other computer, running the test with the beta would probably
have been totally useless, because I wouldn't have been able to properly
measure execution time at all :) (64 bit AMD QuadCore; well, running only at
2.3GHz, but what the heck - 3.6.1c runs just 10% slower on a *single* core of
it as on my P4, and that's only because I have to use a generic x86 binary;
with MegaPOV's AMD64 binary, a single core of that AMD machine is even 20%
faster than the P4 running 3.6.1c (for some reason, MegaPOV performance is
rather poor *there*). Rendering of your scene would probably have taken
something like 1 or 2 seconds with the beta :).)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
>
> On my brand-new other computer, running the test with the beta would probably
> have been totally useless, because I wouldn't have been able to properly
> measure execution time at all :)...
> Rendering of your scene would probably have taken
> something like 1 or 2 seconds with the beta :).)
WOW! That's not merely impressive, it's....magical. I can envision a whole new
world of possibilities with POV-Ray.
I ran some further v3.6.1c tests using a typically complex scene (area_lights,
CSG, isosurfaces, HFs), and discovered a kind of Catch-22 situation regarding
auto bounding.
If the area_light has NO looks_like object (or any object invading it's space),
the entire scene renders at least twice as fast with auto bounding ON than with
it off. I didn't notice that before. (Of course, most scenes run faster when
using auto bounding, so it shouldn't have been surprising.) I also found that
the same thing happens when using radiosity. Again, good news. But this
presents a dilemma: If there *is* a looks_like object (which slows down the
render unless auto bounding is OFF) AND I use radiosity, there's no 'choice' of
auto bounding to get a 'faster' render. Either on or off, the scene renders more
slowly than it should, due to either one scenario or the other.
This is only temporary, of course; the v3.7 changes will make it all a moot
point.
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
