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

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> There is something fishy when the bounding optimisation is turn on.

That's the kind of error description developers really *love* :P

http://chemistry.lsu.edu/ACSBR/jokes/quantas.htm

Post a reply to this message

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?
I see some with the provided sample: the bounding objetcs are realy badly 
dimentionned.
The sphere is way to small.
The box is much to short on the z axis, and uselessy tall.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you are compulsive, neurotic, 
anti-social, paranoid and manic-depressive but basically happy.
Quietly Watching

Post a reply to this message

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

Le_Forgeron <jgr### [at] freefr> wrote:
> 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)

Are you sure you're not just messing up "contained_by" and "bounded_by"?

"bounded_by" is intended to provide the renderer with a manually-optimized
bounding shape instead of the auto-generated bounding box.

"contained_by" is intended to clip away parts of an object's surface (namely all
that lie outside the clipped_by shape), and has *nothing* to do with bounting.

(I think it's even mentioned somewhere in the FAQ.)

Post a reply to this message

clipka <nomail@nomail> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > 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)

> Are you sure you're not just messing up "contained_by" and "bounded_by"?

> "bounded_by" is intended to provide the renderer with a manually-optimized
> bounding shape instead of the auto-generated bounding box.

> "contained_by" is intended to clip away parts of an object's surface (namely all
> that lie outside the clipped_by shape), and has *nothing* to do with bounting.

  I think you are confusing "contained_by" and "clipped_by".

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > "bounded_by" is intended to provide the renderer with a manually-optimized
> > bounding shape instead of the auto-generated bounding box.
>
> > "contained_by" is intended to clip away parts of an object's surface (namely all
> > that lie outside the clipped_by shape), and has *nothing* to do with bounting.
>
>   I think you are confusing "contained_by" and "clipped_by".

Well, as a matter of fact I was - but still contained_by is totally unrelated to
bounding (except that POV will probably base its bounding box on the shape
specified), and is actually quite akin to clipped_by regarding its effect.

Post a reply to this message

Confirmed the error - and found the culprit!

Chris, there is a bug in the IsoSurface::All_Intersections() implementation -
and possibly a misconception about the RefPool:

The IsoSurface::All_intersections() code contains the following:

  /*  METHOD 2   by R. Suzuki */
  tmax = Depth2 = min(Depth2, BOUND_HUGE);
  tmin = Depth1 = min(Depth2, Depth1);
  if((tmax - tmin) < accuracy)
   return (false);

At this point however, an intersection with the container object may already
have been pushed. (I don't know whether the intention here is to discard all
intersection points already found, or just stop searching for additional ones.
In the latter case, IFound should be returned instead.)

The calling function, getting the impression from the return code that there
*are* no intersection points, will in this case not bother evaluating the
intersection stack, and just leave it for deconstruction.

Unfortunately, being managed by a RefPool, the stack is in fact *not*
deconstructed. Instead, the contents are retained until some other code
requests an intersection stack from the pool and is assigned this one.

Obviously, with stale values already in the stack, that other code will compute
crap.

Post a reply to this message

clipka wrote:
> Confirmed the error - and found the culprit!
> 
> Chris, there is a bug in the IsoSurface::All_Intersections() implementation -
> and possibly a misconception about the RefPool:

Good work!:)

-- Chris

Post a reply to this message

Le 13.03.2009 02:58, Chris Cason nous fit lire :
> clipka wrote:
>> Confirmed the error - and found the culprit!
>>
>> Chris, there is a bug in the IsoSurface::All_Intersections() implementation -
>> and possibly a misconception about the RefPool:
> 
> Good work!:)

As Beta 32 is still displaying the issue, I would suggest the following correction
(on Beta 32 sources):

Poping the entry added locally, and leaving the remaining untouched.
Tested with the problematic scene of this thread, looks ok.

Not done: checking all other All_Intersection method to find if some are also using
that
lazy shortcut of pushing intersection and returning false. Left as an exercise for the
good people.

Not an optimal patch, as an optimal patch would have avoided, with less instructions,
to
push an intersection to pop it a fraction of second later. Not sure such optimal patch
might exist.

diff -r da476cece3cc source/backend/shape/isosurf.cpp
--- a/source/backend/shape/isosurf.cpp  Mon Apr 13 14:10:46 2009 +0200
+++ b/source/backend/shape/isosurf.cpp  Mon Apr 13 20:16:48 2009 +0200
@@ -277,5 +277,11 @@
                tmin = Depth1 = min(Depth2, Depth1);
                if((tmax - tmin) < accuracy)
-                       return (false);
+                {
+                   if (IFound==true)
+                   {
+                      Depth_Stack->pop();
+                   }
+                   return (false);
+                }
                Thread->Stats[Ray_IsoSurface_Tests]++;
                if((Depth1 < accuracy) && (Thread->isosurfaceData->Inv3 == 1))

Post a reply to this message