Alain <kua### [at] videotronca> wrote:

> > I don't know if this will help, but have you tried upping the
> > 'max_intersections' value in your global_settings{} block?
>
> I don't think that it'll work in this case.
> If the value is to low, you get an "I-Stack Overflows" message in the
> statistics after the scene is rendered.
> It's normaly a non-fatal error, and may be more similar to a
> max_gradiant error. The scene renders, but not correctly.
>

Yes, you are correct. I thought increasing it *might* make a difference--
somehow-- but I tried it in the code example here, and the error still occurs in
v3.7. But I also see that 3.7 issues a parse warning: max_intersections is no
longer used(!) That information is missing from the new documentation.

I've been playing around with the code example-- using 3.7 and also 3.62-- and
I've noticed a BIG difference in the rendered appearance of the scene. It seems
that there's something 'not right' about global_settings' max_trace_level in
3.7; something has changed since 3.62.

In 3.62, setting max_trace_level to 5 results in *many* of the 900 overlapping
spheres turning black-- as expected. But in 3.7, even with max_trace_level set
to only 2(!), ALL the spheres render normally (that is, when r1=1 and r2=5 and
the render doesn't fail.) Plus, the render statistics show that the 'max level'
reached is only 1 of 2! (Setting the value to 1 instead of 2 results in ALL
black spheres.) It *seems* that max_trace_level is now completely ON or OFF,
with no in-between values; but that's just a guess. Perhaps this has something
to do with the bigger problem.

I'm still experimenting with the code example, to see what else I can
discover...

Post a reply to this message

Hi,

I checked to change the max_intersections value, but it does not help, and I get
the message:

Parse Warning: 'max_intersections' is no longer needed and has no effect in
POV-Ray 3.7 or later.



Alain <kua### [at] videotronca> wrote:

> > "Sereib" <nomail@nomail> wrote:
> >
> >>
> >> rendering stops with the message:
> >>
> >> Internal limit exceeded in FixedSimpleVector
> >> Fatal error in renderer: A POV-Ray internal nesting limit was reached.
> >> Render failed
> >>
> >
> > I don't know if this will help, but have you tried upping the
> > 'max_intersections' value in your global_settings{} block? By default, it is 64.
> > (Admittedly, I don't know the technical aspects of what it does; but changing it
> > might be worth a try.)
> >
> >
>
> I don't think that it'll work in this case.
> If the value is to low, you get an "I-Stack Overflows" message in the
> statistics after the scene is rendered.
> It's normaly a non-fatal error, and may be more similar to a
> max_gradiant error. The scene renders, but not correctly.
>
>
>
> Alain

Post a reply to this message

Le Forgeron already provided a competent and correct answer; what you are trying
only wastes your time. It cannot work!

Thorsten

"Sereib" <nomail@nomail> wrote:
> Hi,
>
> I checked to change the max_intersections value, but it does not help, and I get
> the message:
>
> Parse Warning: 'max_intersections' is no longer needed and has no effect in
> POV-Ray 3.7 or later.
>
>
>
> Alain <kua### [at] videotronca> wrote:

> > > "Sereib" <nomail@nomail> wrote:
> > >
> > >>
> > >> rendering stops with the message:
> > >>
> > >> Internal limit exceeded in FixedSimpleVector
> > >> Fatal error in renderer: A POV-Ray internal nesting limit was reached.
> > >> Render failed
> > >>
> > >
> > > I don't know if this will help, but have you tried upping the
> > > 'max_intersections' value in your global_settings{} block? By default, it is 64.
> > > (Admittedly, I don't know the technical aspects of what it does; but changing it
> > > might be worth a try.)
> > >
> > >
> >
> > I don't think that it'll work in this case.
> > If the value is to low, you get an "I-Stack Overflows" message in the
> > statistics after the scene is rendered.
> > It's normaly a non-fatal error, and may be more similar to a
> > max_gradiant error. The scene renders, but not correctly.
> >
> >
> >
> > Alain

Post a reply to this message

Hi,

Le Forgeron mentioned that the error should have nothing to do with the number
of overlapping elements. However, we have shown it indeed does make a difference
(error on/off for different values of r2).

And we've also seen that v3.62 makes no problem, while v3.70 does result in
failed render for exactly the same scene.

So to my opinion, there is still no reasonable answer why this error occurs, or
maybe I've overseen anything?


"Thorsten Froehlich" <nomail@nomail> wrote:
> Le Forgeron already provided a competent and correct answer; what you are trying
> only wastes your time. It cannot work!
>
> Thorsten
>

Post a reply to this message

Hello,

I found something interesting:

If I set

r1 = 1
r2 = 2

the scene renders without error, if I change the pigment to "rgbt 1" to "rgbt
0.9". I checked some values between 0.9 and 1: "rgbt 0.99" again makes the
error.

This effect is independent from the max_trace_level.

!! However: If I set a global_settings' adc_bailout to 0.2 no error occurs !!

In conclusion (always r1 = 1; r2 = 2; max_trace_level=256):

"rgbt 1" in combination with "adc_bailout 1/256" gives an error

"rgbt 0.99" in combination with "adc_bailout 1/256" gives an error

"rgbt 0.9" in combination with "adc_bailout 1/256" works

"rgbt 0.99" in combination with "adc_bailout 0.1" works

Any idea?

Post a reply to this message

Le 05/04/2014 11:58, Sereib nous fit lire :
> Hi,
> 
> Le Forgeron mentioned that the error should have nothing to do with the number
> of overlapping elements. However, we have shown it indeed does make a difference
> (error on/off for different values of r2).
> 

number of object: no.
number of object with media: a different story.

> And we've also seen that v3.62 makes no problem, while v3.70 does result in
> failed render for exactly the same scene.
> 
> So to my opinion, there is still no reasonable answer why this error occurs, or
> maybe I've overseen anything?
> 
> 
> "Thorsten Froehlich" <nomail@nomail> wrote:
>> Le Forgeron already provided a competent and correct answer; what you are trying
>> only wastes your time. It cannot work!
>>
>> Thorsten
>>
> 
> 
>

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

>
> number of object: no.
> number of object with media: a different story.
>

The problem might not be as clear-cut as that. I rendered the OP's test code
*without* media, and with pigment{rgbt 1} and r2=2 (to get closer overlapping
spheres), and v3.7 actually crashes. The crash info says "...a stack overflow at
address 0x005F32CC has caused POV-Ray to crash." (I don't know if that's useful
information, but I've included it anyway.) Changing the pigment to rgbt
<1,1,1,.994> does not cause a crash, and the render proceeds OK with no problem.

I admit that my test is not a practical one (just perfectly transparent
spheres!), but I wanted to see what would happen.

> "Thorsten Froehlich" <nomail@nomail> wrote:
>> Le Forgeron already provided a competent and correct answer; what you are
>> trying only wastes your time. It cannot work!

Do you mean, it cannot work because the problem is a known one (to be addressed
in the future?) Or that it cannot work at all? I don't mean to be argumentative;
I'm just curious. :-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> The problem might not be as clear-cut as that. I rendered the OP's test code
> *without* media, and with pigment{rgbt 1} and r2=2 (to get closer overlapping
> spheres), and v3.7 actually crashes...
>
> I admit that my test is not a practical one (just perfectly transparent
> spheres!), but I wanted to see what would happen.
>

After reading some older posts re: problems with lots of perfectly transparent
objects, I see that a crash was to be expected (due to 'stack overflow errors',
max_trace_level, ADC, etc.) Sorry for my ignorance :-(

Post a reply to this message

> Alain <kua### [at] videotronca> wrote:
>
>>> I don't know if this will help, but have you tried upping the
>>> 'max_intersections' value in your global_settings{} block?
>>
>> I don't think that it'll work in this case.
>> If the value is to low, you get an "I-Stack Overflows" message in the
>> statistics after the scene is rendered.
>> It's normaly a non-fatal error, and may be more similar to a
>> max_gradiant error. The scene renders, but not correctly.
>>
>
> Yes, you are correct. I thought increasing it *might* make a difference--
> somehow-- but I tried it in the code example here, and the error still occurs in
> v3.7. But I also see that 3.7 issues a parse warning: max_intersections is no
> longer used(!) That information is missing from the new documentation.
>
> I've been playing around with the code example-- using 3.7 and also 3.62-- and
> I've noticed a BIG difference in the rendered appearance of the scene. It seems
> that there's something 'not right' about global_settings' max_trace_level in
> 3.7; something has changed since 3.62.
>
> In 3.62, setting max_trace_level to 5 results in *many* of the 900 overlapping
> spheres turning black-- as expected. But in 3.7, even with max_trace_level set
> to only 2(!), ALL the spheres render normally (that is, when r1=1 and r2=5 and
> the render doesn't fail.) Plus, the render statistics show that the 'max level'
> reached is only 1 of 2! (Setting the value to 1 instead of 2 results in ALL
> black spheres.) It *seems* that max_trace_level is now completely ON or OFF,
> with no in-between values; but that's just a guess. Perhaps this has something
> to do with the bigger problem.
>
> I'm still experimenting with the code example, to see what else I can
> discover...
>
>
>
>

There was a big change with the handling of the trace_level in the early 
betas of version 3.7.
When a ray pass through a surface that don't cause a ray to change 
direction and don't cause any secondary ray to be shot, that surface NO 
LONGER COUNT toward the max_trace_level limit.

That mean that any surface that have no reflection for any object that 
don't have an interior block, will not be counted toward max_trace_level.

Now, a ray can pass through 1000+ surfaces...

max_trace_level is STILL important if you have any reflection at all. 
Even reflection{0.00001} will count.
Also, if you have interior{ior 1.000001}, any ior <> 1, or an interior 
defining some media of fading colour, the surfaces of that object WILL 
count toward max_trace_level.





Alain

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

>
> There was a big change with the handling of the trace_level in the early
> betas of version 3.7...

Thanks; that's a new feature to me, and your explanation is very clear. I should
have paid more attention to the many beta changes ;-)

Post a reply to this message