Alain wrote:
> Lance Birch nous apporta ses lumieres en ce 2007/10/16 04:11:
>> Woody wrote:
>>> I was testing out some of the Isosurfaces from the documentation and 
>>> came
>>> across some thing which I'm not sure if its a bug, a limitation, or 
>>> so I'm
>>> just not doing it right.
>>>
>>> The code below renders to the attached image. There seems to be some 
>>> weird
>>> normals, shading, or with the general shape. But if I change the viewing
>>> coordinates to something else like <3,2,5> everything looks fine.
>>>
>>> Can anybody tell me what I'm doing wrong or make any suggestions?
>>>
>>> Image at <web.4712c21a4144865430d4452f0@news.povray.org>
>>>
>>>
>>> #include "colors.inc"
>>>
>>> camera {
>>>  location <2,2,2>
>>>  look_at <0,0,0>
>>> }
>>>
>>> isosurface{
>>>         function{ abs(x)+abs(y)-1}
>>>         contained_by {box{-1,1}}
>>>         pigment{color White}
>>> }
>>>
>>>
>>> light_source {
>>>  <2,2,2>
>>>  color White
>>> }
>>
>> Woody, I received your bug report to the povray.bugreports group, 
>> however this is *not* a bug.  The messages output by POV-Ray at the 
>> time of rendering should provide the clue:
>>
>> "Shutdown Warning: The maximum gradient found was 1.375, but the 
>> max_gradient of the isosurface was set to 1.100.  The isosurface may 
>> contain holes!  Adjust max_gradient to get a proper rendering of the 
>> isosurface."
>>
>> Therefore, to resolve the issue you're seeing (and as Mark also 
>> noticed) you have to include a higher max_gradient value in your 
>> isosurface, which can be done as follows:
>>
>> isosurface{
>>   function{ abs(x)+abs(y)-1}
>>   contained_by {box{-1,1}}
>>   max_gradient 1.375
>>   pigment{color White}
>> }
>>
>> I'd recommend checking the isosurfaces area in the documentation to 
>> read more about max_gradient and why this happens as it's something 
>> that needs to be watched out for.  Note that the higher the 
>> max_gradient setting is, the slower the isosurface takes to render, 
>> which is why the default value of max_gradient is set so low.
>>
>> As an aside, please ensure in the future when submitting possible bugs 
>> to the povray.bugreports group that you check that the provided SDL is 
>> syntactically correct, as the SDL you sent with your post contained a 
>> syntax error that made it difficult to determine whether the problem 
>> you were having was with the syntax or with something else.
>>
>> Kind regards,
>>
>> Lance Birch.
>>
>> thezone - thezone.firewave.com.au
> A hi max_gradient don't always mean slow render, and a small gradient 
> don't equate to fast render. A gradient of 1.4 is not large, and in this 
> case, setting max_gradient to 1.3 should be enough.
> If your function have area of small gradient (close to 1 or less close 
> to the tresshold) and area of large gradient (over 1000), THEN you get 
> slow rendering, as the low gradient areas get hugely oversampled. A 
> possible solution for that can be to use the log of the function as it 
> could compress the hi gradient areas.

Hi Alain, that's correct.  I was simply noting that the reason POV-Ray 
uses a low max_gradient *by default* is that a *higher than required* 
max_gradient results in more samples and a slower render.  I noted this in 
case Woody wondered why the default value of max_gradient was so low, 
since he submitted a bug report about his problem.

Regards,

Lance.

thezone - thezone.firewave.com.au

Post a reply to this message