> 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