global_settings {
   assumed_gamma 1

   max_trace_level 50
   radiosity {}
}

camera{
  location <5, 9, 11>
  up       <0, 1, 0>
  right    <1, 0, 0>
  look_at  <0, -1, 0>
}

sphere {
  0, 10000

  hollow
  no_shadow

  pigment { rgb 1 }
  finish { diffuse 0 ambient 1 }
}

#local fchecker = function { pigment { checker } }

union{
  cylinder{ <-5,  3, -3>, <5,  3, -3>, 1/8 }
  cylinder{ <-5,   0, -3>, <5,   0, -3>, 1/8 }
  cylinder{ <-5, -3, -3>, <5, -3, -3>, 1/8 }

  cylinder{ <-5,  3, 0>, <5,  3, 0>, 1/8 }
  cylinder{ <-5,   0, 0>, <5,   0, 0>, 1/8 }
  cylinder{ <-5, -3, 0>, <5, -3, 0>, 1/8 }

  cylinder{ <-5,  3, 3>, <5,  3, 3>, 1/8 }
  cylinder{ <-5,   0, 3>, <5,   0, 3>, 1/8 }
  cylinder{ <-5, -3, 3>, <5, -3, 3>, 1/8 }

  cylinder{ < 3, -5, -3>, < 3, 5, -3>, 1/8 }
  cylinder{ <  0, -5, -3>, <  0, 5, -3>, 1/8 }
  cylinder{ <-3, -5, -3>, <-3, 5, -3>, 1/8 }

  cylinder{ < 3, -5, 0>, < 3, 5, 0>, 1/8 }
  cylinder{ <  0, -5, 0>, <  0, 5, 0>, 1/8 }
  cylinder{ <-3, -5, 0>, <-3, 5, 0>, 1/8 }

  cylinder{ < 3, -5, 3>, < 3, 5, 3>, 1/8 }
  cylinder{ <  0, -5, 3>, <  0, 5, 3>, 1/8 }
  cylinder{ <-3, -5, 3>, <-3, 5, 3>, 1/8 }

  cylinder{ <-3,  3, -5>, <-3,  3, 5>, 1/8 }
  cylinder{ <-3,   0, -5>, <-3,   0, 5>, 1/8 }
  cylinder{ <-3, -3, -5>, <-3, -3, 5>, 1/8 }

  cylinder{ <0,  3, -5>, <0,  3, 5>, 1/8 }
  cylinder{ <0,   0, -5>, <0,   0, 5>, 1/8 }
  cylinder{ <0, -3, -5>, <0, -3, 5>, 1/8 }

  cylinder{ <3,  3, -5>, <3,  3, 5>, 1/8 }
  cylinder{ <3,   0, -5>, <3,   0, 5>, 1/8 }
  cylinder{ <3, -3, -5>, <3, -3, 5>, 1/8 }

  quadric{ <1, 0, 1>, 0, 0, -1/4 }

  texture{ function { fchecker(x, y, z).gray }
   texture_map{
    [0 pigment {rgb 0 } finish { reflection {0, 1/2 metallic 1/2} 
ambient 0 diffuse 1 }]
    [1 pigment {rgb 0.8 } finish { reflection {0, 1 metallic 1/2} 
ambient 0 diffuse 1 }]
   }
  }
}

Rendering settings: 1000x1000, no AA.

The rendering freezes for several hours on 27%.

POV-Ray v3.6.1.icl8.win32

William

Post a reply to this message

Yup I get it too:

I tried it different ways using a custom build of 3.6.0 (just a bug fix of
the "Identifier expected. - Incomplete function call or spline call found
instead" bug).  Not knowing what it'd look like and wanting to move things
along quicker I started with max_trace_level 5 and it rendered fine at the
same 1000x1000 no AA.  Then:

max_trace_level 5  & radiosity = renders fine at 1000x1000 no AA
max_trace_level 50 & radiosity = stops at 27% just like you said
(or 28% if 800x800)
max trace_level 5  no radiosity = renders fine at 1000x1000 no AA
max_trace_level 50 no radiosity = renders fine at 1000x1000 no AA

Leaving both max_trace_level at 50 and radiosity on:
500x500 stops at 27%  499^2 and 501^2 both render fine.
600^2 renders fine.  700^2 stops at 12%  699^2 stops at 28%
701^2 stops at 26% 698^2 renders fine.

700^2 renders fine with the camera moved to <5,9,11.1>

Charles

William Peska <wil### [at] yahoocom> wrote:
> global_settings {
>    assumed_gamma 1
>
>    max_trace_level 50
>    radiosity {}
> }
>
> camera{
>   location <5, 9, 11>
>   up       <0, 1, 0>
>   right    <1, 0, 0>
>   look_at  <0, -1, 0>
> }

Post a reply to this message

The bug is in the quartic, it appears
not to work predicably with radiosity
(even if you bound it).

The easy solution is just to replace it
with a long cylinder...

Post a reply to this message

Tim Attwood wrote:
> The bug is in the quartic, it appears
> not to work predicably with radiosity
> (even if you bound it).

The bug remains if the quartic is replaced with isosurface:

  isosurface{
   function { x*x + z*z - 1/4 }
   contained_by { box{ <-1, -5, -1>, <1, 5, 1> } }
   max_gradient 8
  }

> The easy solution is just to replace it
> with a long cylinder... 

This will not fix the bug.
I have a scene with isosurface (which can not be replaced), in which the 
rendering freezes during a radiosity pre-trace pass.

William

Post a reply to this message

The line
#local fchecker = function { pigment { checker } }
probably should have been
#local fchecker = function { pigment { checker 0 1} };
The default colors for a checker pigment are green
and blue. Since you later evaluate the gray values,
which should be nearly equal, I think somewhere
the pov engine gets confused.

After making this change it rendered fine for me
at 1000x1000 no AA and default radiosity (23 sec)

Post a reply to this message

Tim Attwood wrote:
> The line
> #local fchecker = function { pigment { checker } }
> probably should have been
> #local fchecker = function { pigment { checker 0 1} };
> The default colors for a checker pigment are green
> and blue. Since you later evaluate the gray values,
> which should be nearly equal, I think somewhere
> the pov engine gets confused.

With the following definitions of fchecker the problem remains:

#local fchecker = function { 0.11 + 0.48*(sin(pi*x)*sin(pi*y)*sin(pi*z) 
< 0) }

#local fchecker = function { 0.11 + 0.48*(sin(3*x)*sin(3*y)*sin(3*z) < 0) }

William

Post a reply to this message

They worked OK for me with max_trace_level 10
instead of 50. I think when you are dealing with
multiple reflections there is a chance of getting
something like a hall of mirrors effect...
possibly 2^max_trace_level rays per pixel.

Post a reply to this message

Tim Attwood wrote:
> They worked OK for me with max_trace_level 10
> instead of 50. I think when you are dealing with
> multiple reflections there is a chance of getting
> something like a hall of mirrors effect...
> possibly 2^max_trace_level rays per pixel. 

That really explains why if the quadric is replaced with:

cylinder{ <  0, -5, 0>, <  0, 5, 0>, 1/2 }

there is no problem.

Thanks for your deep insights. I think that it is a responsibility of 
the POV-Ray developers to figure out their bugs. I wasted enough time.

William

Post a reply to this message

William Peska <wil### [at] yahoocom> wrote:
> Thanks for your deep insights. I think that it is a responsibility of 
> the POV-Ray developers to figure out their bugs. I wasted enough time.

  Do you really think sarcasm is going to solve things?

  People tried to help you and wrote about their ideas on the subject,
and you thank them with sarcasm. With that kind of attitude you are
only going to get people annoyed.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   People tried to help you and wrote about their ideas on the subject,
> and you thank them with sarcasm.

1. This is a bug report, not a request for help. I nowhere asked for 
help in the two "[bug]" titled posts. I posted this post here because 
povray.bugreports is moderated (so far my post titled "Very slow 
rendering" from 26.1.2007 does not exist there).

2. There is only one on who I "thanked". So your statement is false.

 > With that kind of attitude you are only going to get people annoyed.

3. Have you considered the possibility that your answer "The source code 
is there. Just implement it yourself." may also annoy?

William

Post a reply to this message

William Peska wrote:
> 
> Thanks for your deep insights. I think that it is a responsibility of 
> the POV-Ray developers to figure out their bugs. I wasted enough time.

That attitude makes me wonder if you actually have any interest in 
solving your problem or if you just want to nag.  In the latter case you 
should note it is rather pointless to claim reporting a bug.

The purpose of bug reports in these groups is to actually solve problems 
- the replies you got tried to do exactly this.  If you are not 
interested in a solution you are first of all wasting the time of those 
trying to help you.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 15 Oct. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann wrote:
> William Peska wrote:
>>
>> Thanks for your deep insights. I think that it is a responsibility of 
>> the POV-Ray developers to figure out their bugs. I wasted enough time.
> 
> That attitude makes me wonder if you actually have any interest in 
> solving your problem or if you just want to nag.

The only reliable way to solve the stated POV-Ray problems is to fix the 
bugs. The workarounds are not reliable solutions and some (most) of them 
require scene modifications which is unacceptable for me.

The purpose of a bug report is to clearly show a problem in the 
software. If you haven't noticed the posted pov scenes are only test 
scenes designed to show a problem. I can't post actual scene, so the 
workarounds may or may not work with my actual scenes and therefore are 
almost useless for me.

Now, is there something UNCLEAR here?

William

Post a reply to this message

William Peska <wil### [at] yahoocom> wrote:
> 3. Have you considered the possibility that your answer "The source code 
> is there. Just implement it yourself." may also annoy?

  The post to which that was my reply had an arrogant tone of voice,
so to speak. I only responded likewise.

-- 
                                                          - Warp

Post a reply to this message

William Peska wrote:
> Christoph Hormann wrote:
>> William Peska wrote:
>>>
>>> Thanks for your deep insights. I think that it is a responsibility of 
>>> the POV-Ray developers to figure out their bugs. I wasted enough time.

I suspect the first responsibility of the developers is to do their day 
jobs. Only much further down the list is fixing problems so you can 
render your scenes.

>> That attitude makes me wonder if you actually have any interest in 
>> solving your problem or if you just want to nag.
> 
> The only reliable way to solve the stated POV-Ray problems is to fix the 
> bugs. The workarounds are not reliable solutions and some (most) of them 
> require scene modifications which is unacceptable for me.
> 
> The purpose of a bug report is to clearly show a problem in the 
> software. If you haven't noticed the posted pov scenes are only test 
> scenes designed to show a problem. I can't post actual scene, so the 
> workarounds may or may not work with my actual scenes and therefore are 
> almost useless for me.
The purpose of open source software is so the users can help narrow down 
the bugs. If you want them fixed you've three choices:
a) Do it yourself.
b) Pay someone to do it.
c) Ask politely and wait for someone to do it for free.
Failing this you can either use a workaround or go without. There's 
friendly and very knowledgeable community here who will generally help 
anyone they can and are very hard to alienate - acting as if you have a 
right to support, or suggesting your time is more valuable than theirs 
is however one way of alienating people.

> Now, is there something UNCLEAR here?

Nope we'll all move along now.

Post a reply to this message

William Peska <wil### [at] yahoocom> wrote:
> The only reliable way to solve the stated POV-Ray problems is to fix the 
> bugs.

  Your problem is that you *assume* it's a bug and not just a side-effect
of how raytracing works.

  If you come here and say "this is clearly a bug, fix it" and then people
try to actually verify that it indeed is a bug and not just something which
is natural to raytracing, and moreover, some people even try to provide
a work-around to avoid the problem and your response to this is "I'm not
interested, I have wasted my time", what do you expect people to think
about that?

  That kind of attitude just sounds arrogant and completely unhelpful.
It sounds almost like you were demanding something and then complaining
when you get something different.
  You shouldn't expect anything else in return.

-- 
                                                          - Warp

Post a reply to this message

General consideration: replying to this kind of attitude encourages this
attitude. It's helpless trying to explain, otherwise he would not have had
this behaviour and think people are at his disposal. Let us concentrate for
interesting people, don't you think?


   Bruno

Post a reply to this message

Verm wrote:
> William Peska wrote:
>> Christoph Hormann wrote:
>>> William Peska wrote:
>>>>
>>>> Thanks for your deep insights. I think that it is a responsibility 
>>>> of the POV-Ray developers to figure out their bugs. I wasted enough 
>>>> time.
> 
> I suspect the first responsibility of the developers is to do their day 
> jobs. Only much further down the list is fixing problems so you can 
> render your scenes.

My scenes may become your scenes some day, so the stated problems are 
not limited to me.

William

Post a reply to this message

Warp wrote:
> William Peska <wil### [at] yahoocom> wrote:
>> The only reliable way to solve the stated POV-Ray problems is to fix the 
>> bugs.
> 
>   Your problem is that you *assume* it's a bug and not just a side-effect
> of how raytracing works.

Well, I think I clearly *proved* that there is a problem with the 
rendering - just replace the quartic with the isosurface and try to 
render, after that replace the isosurface with cylinder and try again.

Well, you are free to state that there are no bugs in any software - the 
perceived malfunctions are simply side effects... . I don't think that 
philosophy will lead to improvements.

William

Post a reply to this message

> I don't think that 
> philosophy will lead to improvements.

	And it's clear that your own philosophy definitely will  :-/

	- NC

Post a reply to this message

William Peska wrote:
> 
> Well, you are free to state that there are no bugs in any software -
> the perceived malfunctions are simply side effects... . I don't think
> that philosophy will lead to improvements.
> 

Anyhow reading the license agreement might be in order:
http://www.povray.org/povlegal.html

I think the disclaimer of warranty is specially relevant in your case:

> This Software is provided on an "AS IS" basis, without warranty of
> any kind, express or implied, including without limitation, any
> implied warranties of merchantability, fitness for a particular
> purpose and non-infringement of intellectual property of any third
> party. This Software has inherent limitations including design faults
> and programming bugs. The entire risk as to the quality and
> performance of the Software is borne by you, and it is your
> responsibility to ensure that it does what you require it to do prior
> to using it for any purpose (other than testing it), and prior to
> distributing it in any fashion. Should the Software prove defective,
> you agree that you alone assume the entire cost resulting in any way
> from such defect.
> 
> This disclaimer of warranty constitutes an essential and material
> term of this agreement. If you do not or cannot accept this, or if it
> is unenforceable in your jurisdiction, then you may not use the
> Software in any manner.
> 

I will not paraphrase but if I understand correctly, judging from what
I've read from you, it seems to me that you are not even allowed to use
POV-Ray ;-)

As to improvements, they will come from people working in their own time
if they feel that their work is appreciated. I wouldn't think that your
comments are seen this way...

It's a shame because the problems you raised are still interesting
effects, you could have learned a lot from the workarounds, and finally
even get someone sufficiently interested to work on the source and see
if they can be avoided. Dismissing anyone willing to help, and demanding
that the software be modified to suit your scene, is just causing the
opposite effect.

I'd humbly suggest you try commercial software and see what you get for
your money,

-- 
Vincent

Post a reply to this message

I understood that William was just demonstrating
a bug.

However, he made no real attempt to pinpoint
what part of the SDL was at fault.

So far I've eliminated the radiosity feature as
a cause, and I've narrowed it down to some
form of hall of mirrors effect with isosurfaces
and quartics with user defined function pigments.

My guess is that the combination of functional
objects (isosurfaces, and quartics) and
function pigments, is causing errors in the
floating point of a small amount not normally
any problem, but when combined with larger
max_trace_levels and reflections with repeating
checkers, is causing a value "bounce" which
makes adc_bailout not kick in, and hence it
tries to cast all the reflection rays, which consumes
too much memory and then freezes.

My suggestion to the POV team would be to
check for user input (render cancel) if after some
amount of time (10 seconds?) a pixel is still not
rendered. This might result in a perception that
POV handles error conditions better.

As for William, POV is a free program made
for the express reason of creating pretty pictures.
As such, POV is inherently a waste of time.

Additionally, any bug that has easy work-arounds
isn't ever going to be high on anyone's to-do list.

Post a reply to this message

You've taken it a lot further than I did but I was thinking along the
hall-of-mirrors line too, just by the fact that it was resolution dependent
and not a single resolution but narrow ranges of resolutions.  Do you have a
version of the scene which stops even with radiosity off?
Charles


"Tim Attwood" <tim### [at] comcastnet> wrote:

> So far I've eliminated the radiosity feature as
> a cause, and I've narrowed it down to some
> form of hall of mirrors effect with isosurfaces
> and quartics with user defined function pigments.

Post a reply to this message

Charles C wrote:
> You've taken it a lot further than I did but I was thinking along the
> hall-of-mirrors line too, just by the fact that it was resolution dependent
> and not a single resolution but narrow ranges of resolutions.  Do you have a
> version of the scene which stops even with radiosity off?
> Charles

Usually such things are very position and angle dependent.  Shifting the 
camera or object by a very small amount (enough to cause the object to 
shift position by a fraction of a pixel, though) *could* eliminate this 
effect.

If you try this, does it change anything?

...Chambers

Post a reply to this message

William Peska wrote:
> Thanks for your deep insights. I think that it is a responsibility of 
> the POV-Ray developers to figure out their bugs. I wasted enough time.
> 
> William

The POV-Ray team has worked extremely hard for around 15 years to 
provide you with a free tool.  I think you should be just a little more 
grateful, especially since we're not really certain that the bug is in 
POV-Ray rather than in your scene.

If it is really so important to you that this be resolved, a very simple 
solution exists: Pay one (or all) of the POV-Ray developers enough money 
that they can leave their day jobs and work on a solution for you. 
Otherwise, you'll just have to wait for them to do it in their free time.

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Usually such things are very position and angle dependent.  Shifting the
> camera or object by a very small amount (enough to cause the object to
> shift position by a fraction of a pixel, though) *could* eliminate this
> effect.
>
> If you try this, does it change anything?
>
> ...Chambers

Yes...  I mentioned it in my original reply.  (See 2nd one on this thread.)
A small change to the camera positon does change whether it stops or not.

Post a reply to this message

Charles C wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
>> Usually such things are very position and angle dependent.  Shifting the
>> camera or object by a very small amount (enough to cause the object to
>> shift position by a fraction of a pixel, though) *could* eliminate this
>> effect.
>>
>> If you try this, does it change anything?
>>
>> ...Chambers
> 
> Yes...  I mentioned it in my original reply.  (See 2nd one on this thread.)
> A small change to the camera positon does change whether it stops or not.
> 
> 

Then it's almost definitely a Hall of Mirrors effect, and not a bug in 
POV-Ray.  Adjusting your max intersections and/or ADC bailout to speed 
the rendering through those sections.

...Chambers

Post a reply to this message

Yes, I had it freeze without radiosity.

Yes, changing the angle makes it work,
or freeze at a different place.

Never locks with max_trace_level lowered to 10.
Function pattern, texture map with reflections,
and isosurface or quadric objects are all required
elements for the render to freeze.

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Then it's almost definitely a Hall of Mirrors effect, and not a bug in
> POV-Ray.  Adjusting your max intersections and/or ADC bailout to speed
> the rendering through those sections.
>
> ...Chambers

Are you advising me or William Peska?  ;-)  I posted some results with the
intent of showing some implied inferences.

Post a reply to this message