I'm not sure exactly where this bug lies, but pinning it on difference seems to
be the most logical thing.  Here's some sample code:

#version 3.7;
#include "colors.inc"

global_settings {
  max_trace_level 256
  ambient_light White
  assumed_gamma 1.0
}

camera {
  location <0,10,0>
  look_at <0,0,0>
}

light_source {
  <1000,1000,0>
  color White
}

plane {
  y, -10
  pigment { hexagon Green, White }
}

box {
  <-0.9999, -0.9999, -0.9999>, <0.9999, 0.9999, 0.9999>
  pigment { checker Violet, Yellow }
}

difference {
  box {
<-1.0000149999,-1.0000149999,-1.0000149999>,<1.0000149999,1.0000149999,1.0000149999>
}
  box { <-1, -1 ,-1>,<1,1,1> }
  pigment {
    transmit 0
  }
  finish {
    ambient 0
    diffuse 0
    conserve_energy
    reflection {
      1
      fresnel on
    }
    specular 0
    roughness 0.001
  }
  interior {
    ior 1/sqrt(2)
  }
}

difference {
  box { <-1.00003,-1.00003,-1.00003>,<1.00003,1.00003,1.00003> }
  box { <-1.000015, -1.000015 ,-1.000015>,<1.000015,1.000015,1.000015> }
  pigment {
    transmit 1
  }
  finish {
    ambient 0
    diffuse 0
    conserve_energy
    reflection {
      0
      fresnel on
    }
    specular 0
    roughness 0.001
  }
  interior {
    ior 1
  }
}

If you render the above, you should see a black square with a backdrop of
hexagons (the plane).  However, you see a checkered square with a backdrop of
hexagons.  If you comment out the second difference (the one with the ior of 1),
you will see what you are supposed to see.  There should, however, be no
difference since an ior of 1 corresponds to air!  When I rendered this with
POV-Ray 3.6, I saw a black square which confirms that this a bug that has crept
in during the development of 3.7.

- Chaanakya

Post a reply to this message

Am 16.07.2012 21:21, schrieb Chaanakya:
> I'm not sure exactly where this bug lies, but pinning it on difference seems to
> be the most logical thing.  Here's some sample code:

This is actually not really a bug, but merely a (currently) inevitable 
limitation: When tracing a ray from some surface, POV-Ray must make sure 
to ignore intersections with the very same or a coincident surface. To 
be robust against rounding errors, it does this by comparing the 
distance to the intersection with a certain minimum distance threshold.

The threshold was changed during the development of 3.7 (I'm not sure 
why though).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 16.07.2012 21:21, schrieb Chaanakya:
> > I'm not sure exactly where this bug lies, but pinning it on difference seems to
> > be the most logical thing.  Here's some sample code:
>
> This is actually not really a bug, but merely a (currently) inevitable
> limitation: When tracing a ray from some surface, POV-Ray must make sure
> to ignore intersections with the very same or a coincident surface. To
> be robust against rounding errors, it does this by comparing the
> distance to the intersection with a certain minimum distance threshold.
>
> The threshold was changed during the development of 3.7 (I'm not sure
> why though).

What was the threshold in 3.6?  I think the threshold is on the order of 1e-6
now if I'm not mistaken...

Post a reply to this message

"Chaanakya" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 16.07.2012 21:21, schrieb Chaanakya:
> > > I'm not sure exactly where this bug lies, but pinning it on difference seems to
> > > be the most logical thing.  Here's some sample code:
> >
> > This is actually not really a bug, but merely a (currently) inevitable
> > limitation: When tracing a ray from some surface, POV-Ray must make sure
> > to ignore intersections with the very same or a coincident surface. To
> > be robust against rounding errors, it does this by comparing the
> > distance to the intersection with a certain minimum distance threshold.
> >
> > The threshold was changed during the development of 3.7 (I'm not sure
> > why though).
>
> What was the threshold in 3.6?  I think the threshold is on the order of 1e-6
> now if I'm not mistaken...

I found that it was changed (in 3.7) to 1e-4 - I changed it to 1e-9 to see if
that makes a difference.  I will report back.  Thanks for pointing me in that
direction!

- Chaanakya

Post a reply to this message

"Chaanakya" <nomail@nomail> wrote:
> "Chaanakya" <nomail@nomail> wrote:
> > clipka <ano### [at] anonymousorg> wrote:
> > > Am 16.07.2012 21:21, schrieb Chaanakya:
> > > > I'm not sure exactly where this bug lies, but pinning it on difference seems
to
> > > > be the most logical thing.  Here's some sample code:
> > >
> > > This is actually not really a bug, but merely a (currently) inevitable
> > > limitation: When tracing a ray from some surface, POV-Ray must make sure
> > > to ignore intersections with the very same or a coincident surface. To
> > > be robust against rounding errors, it does this by comparing the
> > > distance to the intersection with a certain minimum distance threshold.
> > >
> > > The threshold was changed during the development of 3.7 (I'm not sure
> > > why though).
> >
> > What was the threshold in 3.6?  I think the threshold is on the order of 1e-6
> > now if I'm not mistaken...
>
> I found that it was changed (in 3.7) to 1e-4 - I changed it to 1e-9 to see if
> that makes a difference.  I will report back.  Thanks for pointing me in that
> direction!
>
> - Chaanakya

I at least fixed the problem that I mentioned above - the box now renders
correctly.  I changed the following values in source/backend/configbackend.h:

#define SMALL_TOLERANCE 1.0e-6
#define MAX_DISTANCE 1.0e10

#define MIN_ISECT_DEPTH 1.0e-9

and the box now renders correctly.  Thanks again!

Sincerely,

Chaanakya

Post a reply to this message

On 17-7-2012 0:35, clipka wrote:
> The threshold was changed during the development of 3.7 (I'm not sure
> why though).

Seems to be the same issue addressed in bug task #246, reported in 
"Scale Limit?" above.

Thomas

Post a reply to this message

On 7/16/2012 3:35 PM, clipka wrote:
> Am 16.07.2012 21:21, schrieb Chaanakya:
>> I'm not sure exactly where this bug lies, but pinning it on difference
>> seems to
>> be the most logical thing. Here's some sample code:
>
> This is actually not really a bug, but merely a (currently) inevitable
> limitation: When tracing a ray from some surface, POV-Ray must make sure
> to ignore intersections with the very same or a coincident surface. To
> be robust against rounding errors, it does this by comparing the
> distance to the intersection with a certain minimum distance threshold.
>
> The threshold was changed during the development of 3.7 (I'm not sure
> why though).
There almost needs to be like either an "infinite" math, which isn't 
practical, or some sort of "extra" math, which tells it, when running 
across these things, "Are you inside object A, instead of B, and from 
which direction are you approaching that side, as a result?". No idea if 
that is even practical, but... coincident surfaces (and obviously 
intersection code) currently require tricks that, from a practical 
standpoint "break" the actual physics of the object, by requiring things 
like, "leave a small gap between the contents of a cup, and the actual cup.

This is, kind of a silly situation, especially if you where trying to, 
say, "fill" the cup using something like someone's liquid physics 
simulations. Now, testing which thing you where just "inside" on the way 
to the surface won't work in all cases, probably, but being "aware" that 
the surface being hit has its "backside" in front of you, instead of 
behind you, in principle, might cut down on some of the issues. Or, it 
might create others, but it would, I would think, create a kind of 
"sorting", where the side you are headed for would always be, "Belonging 
to what I just came from, first, then the other one.", without regard to 
any rounding issues.

Or am I just not getting the problem again? lol

Post a reply to this message

Am 17.07.2012 21:57, schrieb Patrick Elliott:

> There almost needs to be like either an "infinite" math, which isn't
> practical, or some sort of "extra" math, which tells it, when running
> across these things, "Are you inside object A, instead of B, and from
> which direction are you approaching that side, as a result?". No idea if
> that is even practical, but... coincident surfaces (and obviously
> intersection code) currently require tricks that, from a practical
> standpoint "break" the actual physics of the object, by requiring things
> like, "leave a small gap between the contents of a cup, and the actual cup.

Coincident surface issues /are/ a major PITA - this is known to the dev 
team, and it's pretty high on the agenda. But not for 3.7, that's for sure.

Post a reply to this message

On 17-7-2012 22:28, clipka wrote:

> Coincident surface issues /are/ a major PITA - this is known to the dev
> team, and it's pretty high on the agenda. But not for 3.7, that's for sure.

But I hope the threshold is?

Thomas

Post a reply to this message

clipka wrote:

> The threshold was changed during the development of 3.7 (I'm not sure 
> why though).

Is it a compiled constant for performance issues or could it
be turned into a global setting? If there are reasons to change
it by a factor of 100 it might be useful as a parameter.

Post a reply to this message