Le 11.03.2009 00:30, Alain nous fit lire :
> Le_Forgeron nous illumina en ce 2009-03-10 15:36 -->
>> Hello,
>>
>> on a linux 64bits (amd/ubuntu), compilation from sources.
>> Beta 31
>>
>> There is something fishy when the bounding optimisation is turn on.
>>
>> Bugs:
>>    1. povray -Ibug.pov +MB1 +A0.01
>>
>> No Bugs:
>>    1. povray -Ibug.pov +MB100 +A0.01
>>
>>
>>
>>
>> //start scene
>> global_settings{max_trace_level 55}
>> camera {location  <0,0,-18> look_at <0,0,0> angle 55}
>>
>> background {rgb <.8,0.7,0>}
>>
>> light_source {<-30, 100, -30> color rgb 1.6}
>> // light_source {<-30, -100, -30> color rgb 1.6}
>>
>> #declare f_sphere = function { internal(61) }
>> #declare f_rounded_box = function { internal(60) }
>> isosurface {
>>   function { f_rounded_box(x, y, z, 0.3, 0.8, 1, 0.8)  }
>> //  contained_by{box{<-0.85, -1.4,-0.25>,<0.85, 1.4, 0.85>}}
>>   contained_by{sphere{<0,0,0>,0.9} }
>>   pigment {rgb 1}
>>   scale <3,4,3>
>>   translate x*4
>> }
>> //end scene
>>
> What exactly is your problem?

well, as this is not a binary group, I couldn't post pictures.
But the rendering time of the scene is small.

> I see some with the provided sample: the bounding objetcs are realy
> badly dimentionned.
That's on purpose.

The issue is with the container object vs automatic bounding.
The function is mainly irrelevant in the issue (but it happens only for
isosurface, so we need some anyway)

The sphere container is ok when no automatic bounding (+MB100).
With automatic bounding (+MB1 to force it on), the surface provided
looks "noisy", kind of "coincident surface" (but only when the container
is a sphere; whereas I think** that the bounding system uses only boxes).

**I'm unable to find the tracing code with the bounding box-tree  used.
In fact, I'm unable to even locate the rendering threads top function!
(there is maybe a related issue to the number of threads, their
initialisation and so on, which might explain the two-tones rendering of
cut-by container in m_isosurfaces, but that's another story.)

This one bug is deterministic, whatever the number of thread, so it must
be some "obvious" computation error... somewhere.

Post a reply to this message