 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, I've just had a few Stack-Overflows when rendering a blob with
reflective finish. I had raised the max_trace_level to 256 (because I had
been using media in the scene before I switched to the metallic blob) and
then the overflow happened. I experimented and ended up with raising
max_intersections to 256 and reducing max_trace_level to 64, and then
everything worked fine.
My question is: how do adc_bailout, max_trace_level and max_intersection
interact with each other? From the Docs I understand that once POV-Ray
notices that a new ray will change the color of the ray by an amount smaller
than the set adc_bailout, it will, as the name suggests, "bail out" and
won't track that ray any further. But what does max_intersections do?
I thought that if ADC-Bailout doesn't kick in, max_trace_level would set an
upper boundary how far the ray is traced. In my particular case (reflective
blobs) it seems like max_intersections was the main factor to work around
the overflow, but when reading the Section 6.11.8 of the Docs I don't
understand how it interacts with the raytracing-engine.
Anyone care to enlighten me? I'm just curious, that's all. :-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <404519e7$1@news.povray.org> , "Tim Nikias v2.0" <tim.nikias (@)
nolights.de> wrote:
> But what does max_intersections do?
It sets a static limit to the maximum number of intersections POV-Ray can
handle when tracing a particular ray. Today there is no technical need for
it, but back in the days when memory was limited, it did matter to have a
static limit. This keyword will be obsolete once POV-Ray is rewritten
(thus, it will be done for 4.0).
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It sets a static limit to the maximum number of intersections POV-Ray can
> handle when tracing a particular ray. Today there is no technical need
for
> it, but back in the days when memory was limited, it did matter to have a
> static limit. This keyword will be obsolete once POV-Ray is rewritten
> (thus, it will be done for 4.0).
Ah, then if I raise max_trace_level, I should raise max_intersections as
well? Or is this related to something entirely different?
Do I understand correctly that the "intersection-count" gets incremented
everytime the viewing-ray hits an object? Does it get incremented by two
when the ray gets split into reflective and refractive ray? If I'm getting
too technical, then sorry for the nuisance, but I've always been interested
in how POV-Ray's clockwork looks.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <404528ed@news.povray.org> , "Tim Nikias v2.0" <tim.nikias (@)
nolights.de> wrote:
> Ah, then if I raise max_trace_level, I should raise max_intersections as
> well? Or is this related to something entirely different?
No, max_intersections is per ray, while max_trace_level tells how many rays
can be there.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No, max_intersections is per ray, while max_trace_level tells how many
rays
> can be there.
Sorry for being dense, but let me just think: I shoot a ray and hit an
object. When it gets reflected or refracted, I go to the next trace_level
until max_trace_level is reached. I still don't get what max_intersections
actually saves and why. If I'm annoying, then just settle it with "too
technical", okay? :-)
I guess I'd understand it, but I don't want to waste your time, so feel free
to tell me to bugger off. ;-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4045b5ce@news.povray.org> , "Tim Nikias v2.0" <tim.nikias (@)
nolights.de> wrote:
> Sorry for being dense, but let me just think: I shoot a ray and hit an
> object. When it gets reflected or refracted, I go to the next trace_level
> until max_trace_level is reached. I still don't get what max_intersections
> actually saves and why. If I'm annoying, then just settle it with "too
> technical", okay? :-)
>
> I guess I'd understand it, but I don't want to waste your time, so feel free
> to tell me to bugger off. ;-)
You need to understand the difference between a ray and a ray ;-) There are
two kinds of rays: Lets call them mathematical rays and physical rays.
Mathematically a ray is just a line that extended to infinity in one
direction and has exactly one end if you follow the other direction (well,
you remember this from school, I guess).
In physics however, the concept of a ray is less well defined. Of course,
first you have to remember that there are neither light rays nor viewing
rays. What is frequently called a ray is usually light in its particle
form, and those particle streams can get partially redirected.
So, while for you as a user POV-Ray shoots rays and follows them through the
scene, and occasionally when they hit an object might split them, in order
to do all this, POV-Ray has to use the mathematical definition of what a ray
is. Along this ray, POV-Ray can find any number of objects. In order to
determine which object is closest, it needs to find all objects that are in
the way of this ray (well, not really all in every case, but that is another
story). For every object the intersection (and some more information) needs
to be stored. For simplicity (and memory usage reduction needed in the old
days) there is an upper limit of the number of intersections POV-Ray will
store per ray, and this is the number is what you can alter by changing
max_intersections.
Thorsten
PS: Sorry of all the parenthesis, but I don't want to get a comment about
being inaccurate by any of the usual suspects ;-)
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You need to understand the difference between a ray and a ray ;-) There
are
> two kinds of rays: Lets call them mathematical rays and physical rays.
SNIP the Explanation
Thanks very much. Why can't you just save one intersection and then, for
every new intersection, just replace the stored one when it is closer? Too
much calculation? But that has to be done in any case...
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4045de39$1@news.povray.org> , "Tim Nikias v2.0" <tim.nikias (@)
nolights.de> wrote:
> Thanks very much. Why can't you just save one intersection and then, for
> every new intersection, just replace the stored one when it is closer? Too
> much calculation? But that has to be done in any case...
The short answer is that you sometimes need more than just the first
intersection.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The short answer is that you sometimes need more than just the first
> intersection.
Okay, I'll settle for the short answer. If someone's got some spare time, I
won't complain about getting a long answer, but if you say so, then I'll
(just this once ;-) ) believe you.
Perhaps I'll just do some research on raytracing to find out why one would
need more intersections. Thanks for the tutoring! :-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Mar 2004 18:50:46 +0100, "Tim Nikias v2.0" <tim.nikias (@)
nolights.de> wrote:
>Perhaps I'll just do some research on raytracing to find out why one would
>need more intersections. Thanks for the tutoring! :-)
IIRC the main need for storing an intersection stack arises from the
way CSG works. Basically to find out the intersection with a CSG
object you need to find the intersections with all its children (and
theirs... recursively). Once you have them, the intersection point of
the CSG objects is the first one among those of its children that is
inside all of them, the one in belongs to is not checked for precision
reasons. The inside test itself is either based on Jordan's theorem
(based on the evenness of the number of intersections from the ray's
origin to the point in question) or is object-specific, whichever is
faster.
Another use is object media. POV needs to know the point(s) of entry
and exit of a media container in order to be able to correctly perform
media sampling in the object's interior.
I hope I'm not talking rubbish, but IIRC at least CSG worker that way
in a raytracer I wrote a few years ago.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
