I should have known of course, and instead of swearing by Eagle the 
Bald, sacrificing nameless things to the Clipka idol and invoking the 
good spirit of Saint William of the Pokorny (in that order) for a couple 
of days, I should have opened the Grimoire and read:

"Note: This is not perfect, in some cases (such as CSG intersections and 
differences or isosurfaces) the bounding box does not represent the 
actual dimensions of the object."

The hell it doesn't!

So, I am left with the good old trial-and-error finding of the right 
dimensions/locations of intersection objects. Not a big deal afaiac ;-)

Still, I have been wondering if there would be other, smart, ways to do 
the same? And - just out of pure curiosity - why do min_extent and 
max_extent not work with intersections or differences? Where isosurfaces 
are concerned, I can imagine indeed...

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> "Note: This is not perfect, in some cases (such as CSG intersections and
> differences or isosurfaces) the bounding box does not represent the
> actual dimensions of the object."
>
> The hell it doesn't!
>
> So, I am left with the good old trial-and-error finding of the right
> dimensions/locations of intersection objects. Not a big deal afaiac ;-)
>
> Still, I have been wondering if there would be other, smart, ways to do
> the same? And - just out of pure curiosity - why do min_extent and
> max_extent not work with intersections or differences? Where isosurfaces
> are concerned, I can imagine indeed...

LOL, the problem is so much simpler: This is a patch added from the old MegaPOV,
and all it does is provide access to the internal bounding boxes POV-Ray uses to
speed up rendering. Of course, a perfect bounding box does not matter as much
for this purpose, and the bounding in POV-Ray was never well optmised.

In fact, for CSG is is mostly additive (for the most part the biggest box
bounding all objects) and for isosurces you do actually provide the bounding box
via contained_by .

Thorsten

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> I should have known of course, and instead of swearing by Eagle the
> Bald, sacrificing nameless things to the Clipka idol and invoking the

(when making sacrifices, substituting the virgins with their grandmothers does
not help!  :-))

> good spirit of Saint William of the Pokorny (in that order) for a couple
> of days, I should have opened the Grimoire and read:
>
> "Note: This is not perfect, in some cases (such as CSG intersections and
> differences or isosurfaces) the bounding box does not represent the
> actual dimensions of the object."
>
> The hell it doesn't!
>
> So, I am left with the good old trial-and-error finding of the right
> dimensions/locations of intersection objects. Not a big deal afaiac ;-)
>
> Still, I have been wondering if there would be other, smart, ways to do
> the same? ...

perhaps the 'Bounder' will work with "intersection objects"?


regards, jr.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I should have known of course, and instead of swearing by Eagle the
> Bald, sacrificing nameless things to the Clipka idol and invoking the
> good spirit of Saint William of the Pokorny (in that order) for a couple
> of days, I should have opened the Grimoire and read:

..oO(Oh boy, he's swearing again...)

> "Note: This is not perfect, in some cases (such as CSG intersections and
> differences or isosurfaces) the bounding box does not represent the
> actual dimensions of the object."
>
> The hell it doesn't!

Well, yes, we all knew that - which is what jr's bounding macro - using trace ()
- is all about, and my attempt at doing the same using SVD were all about.
I had a bit of a hard time visualizing some of what the docs were saying a while
back, and clipka gave a little more explanation about about certain pathological
cases. (presumably he was not referring to you at the time)

If your human/mathematical knowledge lets you know approximately the range of a
function in an isosurface, but you don't know _exactly_the bounds of the
surface, you can iterate through the function with a nested x, y, z #for loop
and use min and max to update the value of an indicator with each evaluation.

Post a reply to this message

Op 26/06/2020 om 09:10 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I should have known of course, and instead of swearing by Eagle the
>> Bald, sacrificing nameless things to the Clipka idol and invoking the
> 
> (when making sacrifices, substituting the virgins with their grandmothers does
> not help!  :-))
> 

I just discovered that indeed! ;-)

>> good spirit of Saint William of the Pokorny (in that order) for a couple
>> of days, I should have opened the Grimoire and read:
>>
>> "Note: This is not perfect, in some cases (such as CSG intersections and
>> differences or isosurfaces) the bounding box does not represent the
>> actual dimensions of the object."
>>
>> The hell it doesn't!
>>
>> So, I am left with the good old trial-and-error finding of the right
>> dimensions/locations of intersection objects. Not a big deal afaiac ;-)
>>
>> Still, I have been wondering if there would be other, smart, ways to do
>> the same? ...
> 
> perhaps the 'Bounder' will work with "intersection objects"?
> 

And so I forgot about that tool! :-/

However, it does not work either for the case in question. The results 
are different from the classical way but still wrong.

I attach a little test scene together with version 3 of Bounder where I 
only changed two #local statements to #declare.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'bounder.inc.txt' (9 KB) Download 'intersection_test.pov.txt' (5 KB)

Op 26/06/2020 om 09:07 schreef Thorsten Froehlich:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> "Note: This is not perfect, in some cases (such as CSG intersections and
>> differences or isosurfaces) the bounding box does not represent the
>> actual dimensions of the object."
>>
>> The hell it doesn't!
>>
>> So, I am left with the good old trial-and-error finding of the right
>> dimensions/locations of intersection objects. Not a big deal afaiac ;-)
>>
>> Still, I have been wondering if there would be other, smart, ways to do
>> the same? And - just out of pure curiosity - why do min_extent and
>> max_extent not work with intersections or differences? Where isosurfaces
>> are concerned, I can imagine indeed...
> 
> LOL, the problem is so much simpler: This is a patch added from the old MegaPOV,
> and all it does is provide access to the internal bounding boxes POV-Ray uses to
> speed up rendering. Of course, a perfect bounding box does not matter as much
> for this purpose, and the bounding in POV-Ray was never well optmised.
> 
> In fact, for CSG is is mostly additive (for the most part the biggest box
> bounding all objects) and for isosurces you do actually provide the bounding box
> via contained_by .
> 
> Thorsten
> 

Ah! yes, I hear a distant bell tolling.

-- 
Thomas

Post a reply to this message

Op 26/06/2020 om 12:51 schreef Bald Eagle:
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I should have known of course, and instead of swearing by Eagle the
>> Bald, sacrificing nameless things to the Clipka idol and invoking the
>> good spirit of Saint William of the Pokorny (in that order) for a couple
>> of days, I should have opened the Grimoire and read:
> 
> ..oO(Oh boy, he's swearing again...)

Couldn't be helped ;-)

> 
>> "Note: This is not perfect, in some cases (such as CSG intersections and
>> differences or isosurfaces) the bounding box does not represent the
>> actual dimensions of the object."
>>
>> The hell it doesn't!
> 
> Well, yes, we all knew that - which is what jr's bounding macro - using trace ()
> - is all about, and my attempt at doing the same using SVD were all about.
> I had a bit of a hard time visualizing some of what the docs were saying a while
> back, and clipka gave a little more explanation about about certain pathological
> cases. (presumably he was not referring to you at the time)
> 

Unfortunately, his bounding macro does not work correctly either in this 
case (see my answer to jr).

> If your human/mathematical knowledge lets you know approximately the range of a
> function in an isosurface, but you don't know _exactly_the bounds of the
> surface, you can iterate through the function with a nested x, y, z #for loop
> and use min and max to update the value of an indicator with each evaluation.
> 
> 

Well, I was not working with isosurfaces in this particular case but 
with good old CSG's. However, I shall keep this suggestion in mind (if 
my dreadful memory permits; I totally forgot about jr's macro...).

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 26/06/2020 om 09:10 schreef jr:
> > perhaps the 'Bounder' will work with "intersection objects"?
> ...
> However, it does not work either for the case in question. The results
> are different from the classical way but still wrong.

appears to work but wrong result?  the stuff of nightmares.  :-(

> I attach a little test scene together with version 3 of Bounder where I
> only changed two #local statements to #declare.

thanks.  I'll have a look sometime this weekend.


regards, jr.

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 26/06/2020 om 09:10 schreef jr:
> > ...
> I attach a little test scene together with version 3 of Bounder where I
> only changed two #local statements to #declare.

one thing that grabbed my attention is the scaling of 'Crossing', after it has
been created.  so I moved the 'scale 1.01' from line 73 into the declaration of
'Crossing', as line 66.  the figures output, and the images, differ slightly,
and
I am at a disadvantage in that I do not know what the "correct" result should
look like.  :-)


regards, jr.

Post a reply to this message

Op 27/06/2020 om 15:35 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 26/06/2020 om 09:10 schreef jr:
>>> ...
>> I attach a little test scene together with version 3 of Bounder where I
>> only changed two #local statements to #declare.
> 
> one thing that grabbed my attention is the scaling of 'Crossing', after it has
> been created.  so I moved the 'scale 1.01' from line 73 into the declaration of
> 'Crossing', as line 66.  the figures output, and the images, differ slightly,
> and
> I am at a disadvantage in that I do not know what the "correct" result should
> look like.  :-)
>


I solved it! And, like always, it was a trivial problem :-)
I forgot to increase the resolution parameter in Bounder. For testing, I 
had kept it low (10) but when increasing the value to, e.g. 50 or 
higher, Bounder gives the correct answers for optimized min and max extents.

So, after all, your macro works also correctly for intersections (and 
probably differences too), which is good to know of course. I shall keep 
it close at hand from now on.

-- 
Thomas

Post a reply to this message