|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I'm still a newbie trying to render some scientific (or, really,
"scientific") visualizations. One scene I have keeps failing the rendering
with the following error:
"Rendering Error: Too many nested refracting objects."
The scene is basically about a thousand translucent image maps distributed
about some 3D space. The image maps are just colored squares with the image
used as an opacity map. They're of the form:
polygon {
5, 0, x, x+y, y, 0
pigment {
image_pattern { png IMAGE interpolate 2 }
pigment_map {
[ 0 transmit 0 ]
[ 1 FILTERING_COLOR ]
}
}
SOME_TRANSFORM_HERE
}
If I turn down the "max_trace_level" parameter, I don't get the rendering
error, but the scene looks terrible. If I titrate that parameter upwards,
just before all the artifacts disappear I start getting these render
errors.
Naturally, if I turn off the translucency of the image maps, the error goes
away. Likewise if I replace the image maps with simple translucent squares,
there's no problem.
Is there any way I can get POV-Ray to up the limit on whatever is happening?
Or a better way to get around the issue? There are probably no more than
2-300 overlapping objects in any one ray -- that shouldn't be too much to
choke a raytracer in this day and age, right?
Thanks,
Zach Pincus
Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "Rendering Error: Too many nested refracting objects."
> Is there any way I can get POV-Ray to up the limit on whatever is
> happening? Or a better way to get around the issue? There are probably
> no more than 2-300 overlapping objects in any one ray -- that
> shouldn't be too much to choke a raytracer in this day and age, right?
Get the POV-Ray sources, open source/frame.h, grep for the line
#define MAX_CONTAINING_OBJECTS 100
change it to whatever you feel like and recompile. Don't set it too
high, though, as it will make POV-Ray use quite a bit more memory, and
run slightly slower.
POV-Ray was not written with the zero-one-infinity rule in mind.
--
"Of all things, good sense is the most fairly distributed: everyone
thinks he is so well supplied with it that even those who are the
hardest to satisfy in every other respect never desire more of it than
they already have." -- Descartes, 1637 http://surreal.istic.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Hulme <pho### [at] isticorg> wrote:
> Get the POV-Ray sources, open source/frame.h, grep for the line
> #define MAX_CONTAINING_OBJECTS 100
> change it to whatever you feel like and recompile. Don't set it too
> high, though, as it will make POV-Ray use quite a bit more memory, and
> run slightly slower.
Thanks for the information.
If I might ask, does setting MAX_CONTAINING_OBJECTS too high decrease speed
and increase memory use in the general case, or *only* when POV-Ray is
attempting to render something with a lot of refracting objects?
Thanks again,
Zach
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If I might ask, does setting MAX_CONTAINING_OBJECTS too high decrease
> speed and increase memory use in the general case, or *only* when
> POV-Ray is attempting to render something with a lot of refracting
> objects?
In the general case.
--
Stop the infinite loop, I want to get off! http://surreal.istic.org/
Paraphernalia/Never hides your broken bones,/ And I don't know why you'd
want to try:/ It's plain to see you're on your own. -- Paul Simon
The documentation that can be written is not the true documentation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When a ray goes through a polygon, it thinks it's "inside" that polygon
until it hits it again (which never happens). Usually this works for shapes
like spheres, where the ray goes in and then comes out on the other side.
You might try replacing your polygons with flat boxes, that might fix it.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You might try replacing your polygons with flat boxes, that might fix
> it.
Ah, of course, this is the proper solution and should be used in
preference to mine. That's what I get for not reading the whole question
:-(
--
Six is a number perfect in itself, and not because God created the world
in six days; rather the contrary is true. God created the world in six
days because this number is perfect, and it would remain perfect, even
if the work of the six days did not exist. -- St. Augustine
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <fak### [at] emailaddress> wrote:
> When a ray goes through a polygon, it thinks it's "inside" that polygon
> until it hits it again (which never happens). Usually this works for shapes
> like spheres, where the ray goes in and then comes out on the other side.
>
> You might try replacing your polygons with flat boxes, that might fix it.
>
> - Slime
> [ http://www.slimeland.com/ ]
Aah, thank you -- this makes good sense. Now my scene renders much faster!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |