I've tried doing some renders of an SSLT object (in my buddha scene), and I'm
getting hangs all the time. If I run one thread the render just stops, if I run
two threads, one stops and then later the second thread stops at another point.

If I change the camera angle, I can sometime get a render to complete. It looks
kinda like the bad block the renderer gets stuck on it at the extreme edge of an
object if that helps at all.

The same thing happens with the 64 bit beta 36 and 37 on the Mac.

A sample of the applications stack when two threads have hung the renderer
includes the following:

    2154 Thread_1032143
      2154 thread_start
        2154 _pthread_start
          2154 thread_proxy
            2154 pov::Task::TaskThread(boost::function0<void> const&)
              2154 pov::TraceTask::Run()
                2154 pov::TraceTask::SimpleSamplingM0()
                  2154 pov::TracePixel::operator()(double, double, double,
double, pov_base::Colour&)
                    2154 pov::Trace::TraceRay(pov::Ray&, pov_base::Colour&,
float, pov::Trace::TraceTicket&, bool)
                      2154 pov::Trace::ComputeTextureColour(pov::Intersection&,
pov_base::Colour&, pov::Ray&, float, bool, pov::Trace::TraceTicket&)
                        2154
pov::Trace::ComputeOneTextureColour(pov_base::Colour&, pov::Texture_Struct*,
std::vector<pov::Texture_Struct*, std::allocator<pov::Texture_Struct*> >&,
pov::Vector3d&, pov::Vector3d&, pov::Ray&, float, pov::Intersection&, bool,
bool, pov::Trace::TraceTicket&)
                          2154
pov::Trace::ComputeLightedTexture(pov_base::Colour&, pov::Texture_Struct*,
std::vector<pov::Texture_Struct*, std::allocator<pov::Texture_Struct*> >&,
pov::Vector3d&, pov::Vector3d&, pov::Ray&, float, pov::Intersection&,
pov::Trace::TraceTicket&)
                            2154
pov::Trace::ComputeSubsurfaceScattering(pov::Finish_Struct const*, pov::Vector3d
const&, pov::Ray&, pov::Vector3d const&, pov_base::RGBColour&, double,
pov::ObjectBase*, pov::Trace::TraceTicket&)
                              1210 log
                              889
pov::Trace::ComputeSingleScatteringContribution(pov::Intersection const&,
pov::Vector3d, pov::Vector3d, double, double, pov_base::RGBColour&, double,
pov::ObjectBase*, pov::Trace::TraceTicket&)
                                454
pov::Trace::ComputeSingleScatteringContribution(pov::Intersection const&,
pov::Vector3d, pov::Vector3d, double, double, pov_base::RGBColour&, double,
pov::ObjectBase*, pov::Trace::TraceTicket&)
                                435
pov::RandomDoubleSequence::Generator::operator()()
                              55 dyld_stub_log
    2154 Thread_1032144
      2154 thread_start
        2154 _pthread_start
          2154 thread_proxy
            2154 pov::Task::TaskThread(boost::function0<void> const&)
              2154 pov::TraceTask::Run()
                2154 pov::TraceTask::SimpleSamplingM0()
                  2154 pov::TracePixel::operator()(double, double, double,
double, pov_base::Colour&)
                    2154 pov::Trace::TraceRay(pov::Ray&, pov_base::Colour&,
float, pov::Trace::TraceTicket&, bool)
                      2154 pov::Trace::ComputeTextureColour(pov::Intersection&,
pov_base::Colour&, pov::Ray&, float, bool, pov::Trace::TraceTicket&)
                        2154
pov::Trace::ComputeOneTextureColour(pov_base::Colour&, pov::Texture_Struct*,
std::vector<pov::Texture_Struct*, std::allocator<pov::Texture_Struct*> >&,
pov::Vector3d&, pov::Vector3d&, pov::Ray&, float, pov::Intersection&, bool,
bool, pov::Trace::TraceTicket&)
                          2154
pov::Trace::ComputeLightedTexture(pov_base::Colour&, pov::Texture_Struct*,
std::vector<pov::Texture_Struct*, std::allocator<pov::Texture_Struct*> >&,
pov::Vector3d&, pov::Vector3d&, pov::Ray&, float, pov::Intersection&,
pov::Trace::TraceTicket&)
                            2154
pov::Trace::ComputeSubsurfaceScattering(pov::Finish_Struct const*, pov::Vector3d
const&, pov::Ray&, pov::Vector3d const&, pov_base::RGBColour&, double,
pov::ObjectBase*, pov::Trace::TraceTicket&)
                              1223 log
                              894
pov::Trace::ComputeSingleScatteringContribution(pov::Intersection const&,
pov::Vector3d, pov::Vector3d, double, double, pov_base::RGBColour&, double,
pov::ObjectBase*, pov::Trace::TraceTicket&)
                                450
pov::Trace::ComputeSingleScatteringContribution(pov::Intersection const&,
pov::Vector3d, pov::Vector3d, double, double, pov_base::RGBColour&, double,
pov::ObjectBase*, pov::Trace::TraceTicket&)
                                444
pov::RandomDoubleSequence::Generator::operator()()
                              37 dyld_stub_log

which at least looks like it's busy doing something, and not deadlocked
somewhere...

Cheers,
Edouard.

Post a reply to this message

Am 30.04.2010 14:06, schrieb Edouard:
> I've tried doing some renders of an SSLT object (in my buddha scene), and I'm
> getting hangs all the time. If I run one thread the render just stops, if I run
> two threads, one stops and then later the second thread stops at another point.

 From the stack trace, I'd assume that POV-Ray doesn't really hang, but 
is just pretty busy. Maybe lower quality settings will get you forward?

Unfortunately, SSLT is still at a very early stage, and not exactly in 
the focus of current development efforts these days.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 30.04.2010 14:06, schrieb Edouard:
> > I've tried doing some renders of an SSLT object (in my buddha scene), and I'm
> > getting hangs all the time. If I run one thread the render just stops, if I run
> > two threads, one stops and then later the second thread stops at another point.
>
>  From the stack trace, I'd assume that POV-Ray doesn't really hang, but
> is just pretty busy. Maybe lower quality settings will get you forward?
>
> Unfortunately, SSLT is still at a very early stage, and not exactly in
> the focus of current development efforts these days.

It hangs when my settings are "subsurface { samples 1, 1 }", so I think it's
gotten stuck with something. When I try to quit POV-Ray I get a crash.

Cheers,
Edouard.

Post a reply to this message

Am 30.04.2010 21:09, schrieb Edouard:

> It hangs when my settings are "subsurface { samples 1, 1 }", so I think it's
> gotten stuck with something. When I try to quit POV-Ray I get a crash.

Um... yes, that sounds suspicious indeed.

After having had a closer look at the stack trace, I think I found the 
portion of the code where it hangs.

There is a loop at the beginning of 
Trace::ComputeSingleScatteringContribution() that is intended to trace 
the ray a random distance into the object, using a special random 
distribution that may theoretically yield infinite distances; of course 
the ray should only be traced up to the next intersection point with the 
object's surface, so the algorithm will roll the dice again if that 
condition isn't met.

That said, if the ray happens to hit an exceptionally thin part of the 
object, the algorithm will roll the dice again and again and again 
and... well, I guess you get the point.

The crucial thing here is the ratio between the object "thickness" and 
the sum of the two coefficients used to specify the material's SSLT 
properties. The smaller the coefficients and/or the "thinner" the 
object, the more likely is a lockup to occur.

Note that you can reduce the probability of a lockup without changing 
the scene geometry or material properties, by increasing the 
"mm_per_unit" global setting (though of course this will reduce the SSLT 
effect as if your whole scene was increased in size).

Post a reply to this message

On 04/30/2010 04:09 PM, Edouard wrote:
> It hangs when my settings are "subsurface { samples 1, 1 }", so I think it's
> gotten stuck with something. When I try to quit POV-Ray I get a crash.

I've not used this functionality yet, but thought I'd pass this
change-log excerpt along ... who knows you may see something that might
be helpful in determining what the problem is :-)

http://wiki.povray.org/content/Documentation:ToDo%5CCLReview#Beta_31

Jim

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 30.04.2010 21:09, schrieb Edouard:
>
> > It hangs when my settings are "subsurface { samples 1, 1 }", so I think it's
> > gotten stuck with something. When I try to quit POV-Ray I get a crash.
>
> Um... yes, that sounds suspicious indeed.
>
> After having had a closer look at the stack trace, I think I found the
> portion of the code where it hangs.
>
> There is a loop at the beginning of
> Trace::ComputeSingleScatteringContribution() that is intended to trace
> the ray a random distance into the object, using a special random
> distribution that may theoretically yield infinite distances; of course
> the ray should only be traced up to the next intersection point with the
> object's surface, so the algorithm will roll the dice again if that
> condition isn't met.
>
> That said, if the ray happens to hit an exceptionally thin part of the
> object, the algorithm will roll the dice again and again and again
> and... well, I guess you get the point.
>
> The crucial thing here is the ratio between the object "thickness" and
> the sum of the two coefficients used to specify the material's SSLT
> properties. The smaller the coefficients and/or the "thinner" the
> object, the more likely is a lockup to occur.
>
> Note that you can reduce the probability of a lockup without changing
> the scene geometry or material properties, by increasing the
> "mm_per_unit" global setting (though of course this will reduce the SSLT
> effect as if your whole scene was increased in size).

Is it the loop with the comment "calculate s_prime_out"?

It looks like the random number can simply be scaled so that you don't need the
loop at all...

At the very worst, can you make a change to ensure it doesn't hang - some sort
of bailout condition? Do you want me to add a bug to flyspray for it?

Cheers,
Edouard.

Post a reply to this message

Am 17.05.2010 03:32, schrieb Edouard:

> Is it the loop with the comment "calculate s_prime_out"?

Yup.

> It looks like the random number can simply be scaled so that you don't need the
> loop at all...

No. The proper solution is much simpler: Re-rolling the dice was the 
wrong thing to do in the first place; such an event would be equivalent 
to a photon happening to pass through unscattered and unabsorbed, so 
should be dealt with accordingly.

> At the very worst, can you make a change to ensure it doesn't hang - some sort
> of bailout condition? Do you want me to add a bug to flyspray for it?

Never mind. There's already a patch waiting to be released with beta 38.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.05.2010 03:32, schrieb Edouard:

> > It looks like the random number can simply be scaled so that you don't need the
> > loop at all...
>
> No. The proper solution is much simpler: Re-rolling the dice was the
> wrong thing to do in the first place; such an event would be equivalent
> to a photon happening to pass through unscattered and unabsorbed, so
> should be dealt with accordingly.

Oh - does that mean we'll get actual transparency if the object is thin enough?
That would be fantastic!

> > At the very worst, can you make a change to ensure it doesn't hang - some sort
> > of bailout condition? Do you want me to add a bug to flyspray for it?
>
> Never mind. There's already a patch waiting to be released with beta 38.

That's great news - thank-you again for all the work!

Cheers,
Edouard.

Post a reply to this message

Am 18.05.2010 00:21, schrieb Edouard:

> Oh - does that mean we'll get actual transparency if the object is thin enough?
> That would be fantastic!

That's the plan, yes.

I'm afraid though it will take some time until then - there's other 
construction sites with higher priority in POV-Ray at present.

Post a reply to this message