I recieved the folloing fatal error message after a 50%
render

> ERROR too many nested refracting objects in scene.

For the record the word refraction appears no where in the
scene.
By changing the while declare statements to reduce the
overall
object count the error goes away But I need the scene as is
or the
smoothness of my intended object dissapears.
Any clue people.

Post a reply to this message

On Wed, 08 Jul 1998 11:53:51 -0700, K. Tyler <tyl### [at] pacbellnet> wrote:
>I recieved the folloing fatal error message after a 50%
>render
>
>> ERROR too many nested refracting objects in scene.

>For the record the word refraction appears no where in the scene.
>By changing the while declare statements to reduce the overall
>object count the error goes away But I need the scene as is or the
>smoothness of my intended object dissapears.

>Any clue people.

for the record, the word refraction is now entirely optional.  The presence
of an ior that is not 1 turns on refraction for that object.

The problem is that POV must keep a "stack" of objects and their iors in 
order to know what ior it is returning to when it exits an object.  This 
stack has a finite size (in POV 3.02, it was 100 objects) and you're 
overrunning it.  If you union a bunch of glass spheres, for example, you 
may be "inside" over a hundred objects, in which case you'll have this 
problem.

I haven't seen the scene, so my advice may be useless, but is this a case
where you could use merge instead of union?

Post a reply to this message

Ron Parker wrote:

> On Wed, 08 Jul 1998 11:53:51 -0700, K. Tyler <tyl### [at] pacbellnet> wrote:
> >I recieved the folloing fatal error message after a 50%
> >render
> >
> >> ERROR too many nested refracting objects in scene.
>
> >For the record the word refraction appears no where in the scene.
> >By changing the while declare statements to reduce the overall
> >object count the error goes away But I need the scene as is or the
> >smoothness of my intended object dissapears.
>
> >Any clue people.
>
> for the record, the word refraction is now entirely optional.  The presence
> of an ior that is not 1 turns on refraction for that object.
>
> The problem is that POV must keep a "stack" of objects and their iors in
> order to know what ior it is returning to when it exits an object.  This
> stack has a finite size (in POV 3.02, it was 100 objects) and you're
> overrunning it.  If you union a bunch of glass spheres, for example, you
> may be "inside" over a hundred objects, in which case you'll have this
> problem.
>



> I haven't seen the scene, so my advice may be useless, but is this a case
> where you could use merge instead of union?

  Not really.
  The scene is formatted roughly as follows:

  #declare Count = 0
  #while (Count < 360)
  box{<-1,-1,-1>,<1,1,1>scale 2  translate x*Count rotate x+y*Count pigment{bla
bla color_map{
  [0    rgbf*.5][1 Red*.75]}}}
  #declare Count = Count*.1
  #end

But no where is an ior or refraction or for that
matter any standard finish or normal statement.

Because of the filter component I even tried
upping the max_trace_level to 100 no luck.

Perhaps I should explicitly declare a refraction and ior at 0 ?

While I'm asking advice I ran into a problem/limitation on
another scene I was working on last week that had the same
basic scene structure as the one above. What I had intended
to do was after creating one set of objects I was going to wrap
it in a union tag it with a declared name and then using the object
statement create multiple copies.
Interestingly enough though pov would allow me to wrap it in a union
and within the union statement even apply rotations and transforms
but when I added a #declare MyObject = to the top and then tried
use the object it spit the famous > undeclared object MyObject error.
And I clearly declared the object at the top and there were no spelling
errors Is this a known limitation when using math operatives to create
objects, instead of creating a multitudes of objects statements.
Weird I say.
If any of this makes no sense to you that's ok because it hasn't to me so far
either.

Thanks for the help folks

Ken Tyler


Ken

Post a reply to this message

On Wed, 08 Jul 1998 13:30:27 -0700, "K. Tyler" <tyl### [at] pacbellnet>
wrote:

>
>  Not really.
>  The scene is formatted roughly as follows:
>
>  #declare Count = 0
>  #while (Count < 360)
>  box{<-1,-1,-1>,<1,1,1>scale 2  translate x*Count rotate x+y*Count pigment{bla
>bla color_map{
>  [0    rgbf*.5][1 Red*.75]}}}

if rgbf*.5 isn't a syntax error, it should be.  In any case, you're
making the object semitransparent, and that means POV-Ray will shoot a
"refracted" or "transmitted" ray (it uses the terms interchangeably)
and you will run into the problem I mentioned.  

>  #declare Count = Count*.1

How do you start at zero and get anything but zero if you keep
multiplying by .1?

>  #end

>Because of the filter component I even tried
>upping the max_trace_level to 100 no luck.

Nope, the limit on the size of the stack is hard-coded.  If you wanted
to make it bigger, you'd need to change it in the source and
recompile.

>Perhaps I should explicitly declare a refraction and ior at 0 ?

ior==0 is meaningless.  1 is the default for ior, but ior and
refraction don't matter - any transparent or semitransparent object is
a "refracting object."

Post a reply to this message

K. Tyler wrote:
> I recieved the folloing fatal error message after a 50%
> render
> 
> >> ERROR too many nested refracting objects in scene.

<snip>

>   The scene is formatted roughly as follows:
> 
>   #declare Count = 0
>   #while (Count < 360)
>   box{<-1,-1,-1>,<1,1,1>scale 2  translate x*Count rotate x+y*Count pigment{bla
> bla color_map{
>   [0    rgbf*.5][1 Red*.75]}}}
>   #declare Count = Count*.1
>   #end
> 
> But no where is an ior or refraction or for that
> matter any standard finish or normal statement.
> 
> Because of the filter component I even tried
> upping the max_trace_level to 100 no luck.
> 
> Perhaps I should explicitly declare a refraction and ior at 0 ?
> 
> While I'm asking advice I ran into a problem/limitation on
> another scene I was working on last week that had the same
> basic scene structure as the one above. What I had intended
> to do was after creating one set of objects I was going to wrap
> it in a union tag it with a declared name and then using the object
> statement create multiple copies.
> Interestingly enough though pov would allow me to wrap it in a union
> and within the union statement even apply rotations and transforms
> but when I added a #declare MyObject = to the top and then tried
> use the object it spit the famous > undeclared object MyObject error.
> And I clearly declared the object at the top and there were no spelling
> errors Is this a known limitation when using math operatives to create
> objects, instead of creating a multitudes of objects statements.
> Weird I say.
> If any of this makes no sense to you that's ok because it hasn't to me so far
> either.

I don't know that I can offer any help with the first question - I did
try a quick test scene with 400 closely overlapping objects, and with a
filter value of .5 the scene rendered without problems (albeit very
slowly!), while a filter value of 1 caused POVRay to crash when it hit
the centre of the scene (and I hadn't adjusted the max_trace_level in
either case from the default).

As for the second question - not having ever encountered the error you
mentioned, I tried a test using my Object Exploder include file, set to
1000 particles (ie. objects), eg:

   #declare explode_object = ... [and other options] ...
   #declare particle_res = 10
   #declare explode_clock = 1
   #declare MyObject = #include "Explode"

   object {MyObject}

I think it's reasonable to say that Explode.inc involves a fair amount
of maths used in the creation of objects, and yet the file seems to
render (on versions 3.00e and 3.1.beta.4) without any problems.  Perhaps
a more detailed extract from the code you are trying to render would
help...

Post a reply to this message