Using povray-3.8.0-alpha.10013324-av645-Win64

When using:

#local Object=
difference {
   sphere {<0,0,0>, 6.0}
   disc {<0,0,0>, y, 6.1}
}
//----------------------------------------
#declare Min = min_extent(Object);
#declare Max = max_extent(Object);
#debug concat("\n  min_extent Object: <",vstr(3, Min, ", ", 0,3),">\n")
#debug concat("  max_extent Object: <",vstr(3, Max, ", ", 0,3),">\n\n")
//----------------------------------------

My intuition tells me that the results should be:
Min = <-6.000, 0.000, -6.000>
Max = < 6.000, 6.000,  6.000>

However, I get the following:
Min = <-6.000, -6.000, -6.000>
Max = < 6.000,  6.000,  6.000>

I never noticed this before while I extensively use these features. Is 
this a bug or am I stupid?

-- 
Thomas

Post a reply to this message

See also p.b.images and p.b.scene-files with same subject line.

-- 
Thomas

Post a reply to this message

Am 17.02.2019 um 09:50 schrieb Thomas de Groot:
> Using povray-3.8.0-alpha.10013324-av645-Win64
> 
> When using:
> 
> #local Object=
> difference {
>    sphere {<0,0,0>, 6.0}
>    disc {<0,0,0>, y, 6.1}
> }
> //----------------------------------------
> #declare Min = min_extent(Object);
> #declare Max = max_extent(Object);
> #debug concat("\n  min_extent Object: <",vstr(3, Min, ", ", 0,3),">\n")
> #debug concat("  max_extent Object: <",vstr(3, Max, ", ", 0,3),">\n\n")
> //----------------------------------------
> 
> My intuition tells me that the results should be:
> Min = <-6.000, 0.000, -6.000>
> Max = < 6.000, 6.000,  6.000>
> 
> However, I get the following:
> Min = <-6.000, -6.000, -6.000>
> Max = < 6.000,  6.000,  6.000>
> 
> I never noticed this before while I extensively use these features. Is 
> this a bug or am I stupid?

The latter. (Hey, you asked a straightforward question, so you deserve a 
straightforward answer :))

You shouldn't be using `disc` to cut away a plane. The fact that it 
works is nothing more than a quirk, and the person who made it so should 
be tarred and feathered. Use straightforward `plane` instead.


A couple of things to note in this context:

- The `min_extent` and `max_extent` functions are only guaranteed to 
provide _bounds_ for the extent of the object. The actual extent may be 
smaller. Considerably smaller in some cases.

- As a matter of fact `min_extent` and `max_extent` give you the extent 
of the object's _bounding box_.

- `difference` is actually implemented as an intersection, with all 
children except the first being inverted.

- The bounding box of an intersection is computed as the intersection of 
the children's bounding boxes.

- Inverted objects are typically infinite

- Infinite objects have an infinite bounding box.

- The plane gets special treatment in the computation of intersection 
bounding boxes because it is too useful as a cutting tool.

Post a reply to this message

On 17-2-2019 21:14, clipka wrote:

>> I never noticed this before while I extensively use these features. Is 
>> this a bug or am I stupid?
> 
> The latter. (Hey, you asked a straightforward question, so you deserve a 
> straightforward answer :))

I knew I had this coming of course, so you are welcome ;-)

> 
> You shouldn't be using `disc` to cut away a plane. The fact that it 
> works is nothing more than a quirk, and the person who made it so should 
> be tarred and feathered. Use straightforward `plane` instead.

Yes, I was aware of the fact that disc is a problem child, but being 
stupid of course...

> 
> 
> A couple of things to note in this context:
> 
> - The `min_extent` and `max_extent` functions are only guaranteed to 
> provide _bounds_ for the extent of the object. The actual extent may be 
> smaller. Considerably smaller in some cases.
> 
> - As a matter of fact `min_extent` and `max_extent` give you the extent 
> of the object's _bounding box_.
> 
> - `difference` is actually implemented as an intersection, with all 
> children except the first being inverted.

OK. So, from the above, why is the difference sphere/box (see my example 
image in p.b.i and p.b.s-f) calculating a min_extent.y location 
corresponding to the base of the sphere? I do not grasp that really.

> 
> - The bounding box of an intersection is computed as the intersection of 
> the children's bounding boxes.

That is pretty straightforward.

> 
> - Inverted objects are typically infinite
> 
> - Infinite objects have an infinite bounding box.

Hmmm... ok. That makes sense and shows what can go wrong...

> 
> - The plane gets special treatment in the computation of intersection 
> bounding boxes because it is too useful as a cutting tool.

Yes, I fully agree with that one!


-- 
Thomas

Post a reply to this message

Am 18.02.2019 um 08:31 schrieb Thomas de Groot:

> OK. So, from the above, why is the difference sphere/box (see my example 
> image in p.b.i and p.b.s-f) calculating a min_extent.y location 
> corresponding to the base of the sphere? I do not grasp that really.

     difference {
       sphere { ... }
       box { ... }
     }

is the same as

     intersection {
       sphere { ... }
       box { ... inverse }
     }

The sphere has a bounding box of CENTER-RADIUS to CENTER+RADIUS.

The box _would_ normally have a bounding box of CORNER1 to CORNER2, but 
since it's inverted, it has a bounding box of -INFINITY to +INFINITY. (*)

The intersection has a bounding box equal to the intersection between 
the sphere's bounding box and the box's bounding box.

The intersection of any finite range A and an infinite range B is equal 
to the finite range A.

Thus, the intersection has a bounding box of CENTER-RADIUS to 
CENTER+RADIUS, just like the sphere.

Post a reply to this message

Am 18.02.2019 um 09:53 schrieb clipka:

> The box _would_ normally have a bounding box of CORNER1 to CORNER2, but 
> since it's inverted, it has a bounding box of -INFINITY to +INFINITY. (*)

Forgot to mention:

(* Technically that's a simplification, and the true extent is 
-BOUND_HUGE to +BOUND_HUGE - literally, because that's what the constant 
is called in the source code. But the principle remains the same.)

Post a reply to this message

On 18-2-2019 10:01, clipka wrote:
> Am 18.02.2019 um 09:53 schrieb clipka:
> 
>> The box _would_ normally have a bounding box of CORNER1 to CORNER2, 
>> but since it's inverted, it has a bounding box of -INFINITY to 
>> +INFINITY. (*)
> 
> Forgot to mention:
> 
> (* Technically that's a simplification, and the true extent is 
> -BOUND_HUGE to +BOUND_HUGE - literally, because that's what the constant 
> is called in the source code. But the principle remains the same.)

My deep felt thanks and appreciation for your patient replies, 
Christoph. I certainly have learned something new here. I shall put that 
to profit.

-- 
Thomas

Post a reply to this message