POV-Ray : Newsgroups : povray.text.scene-files : bounding box calculator Server Time
23 Jun 2021 02:11:37 EDT (-0400)
  bounding box calculator (Message 33 to 42 of 42)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: jr
Subject: Re: bounding box calculator
Date: 6 Nov 2019 05:15:01
Message: <web.5dc29d0734d8ef06feeb22ff0@news.povray.org>
hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> > - the test is also useful with hyperboloid, superellipsoid, and
> > isosurface objects. Quartic and parametric objects do no comply,
> > probably they are not 'solid'? I did not test this thoroughly.
>
> The test (using version 2 of bounder.inc) for quartic objects is
> interesting. Using the Lemniscate object the BB seems to be infinite and
> the test is considered optimal. See image attached.

I see the BB change in size when the object is aligned, no idea(s).
interesting.


regards, jr.


Post a reply to this message

From: jr
Subject: Re: bounding box calculator
Date: 6 Nov 2019 05:20:00
Message: <web.5dc29d3b34d8ef06feeb22ff0@news.povray.org>
hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 05/11/2019 om 01:19 schreef jr:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ...
> > also new, if "slack" is reported, two variables with the differences from the
> > BB's min/max extents are declared, to allow use of the info from in-scene.
> > after 'Bounder' has run, one can for instance:
> >
> > #ifdef(Bounder_min_diff)
> >    // do something
> > #end
>
> With version 3, I get a parser error in the scene file when the object
> is considered as near optimal: "Expected 'numeric expression',
> undeclared 'Bounder_min_diff' found instead"

pls read the added comments in the file.  the vars are only 'declare'd _if_
there's any worthwhile "slack" to report.

the '#ifdef()' idiom though ought to work in any case (it does here).


regards, jr.


Post a reply to this message

From: jr
Subject: Re: bounding box calculator
Date: 6 Nov 2019 06:25:00
Message: <web.5dc2ad7034d8ef06feeb22ff0@news.povray.org>
hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> > - the test is also useful with hyperboloid, superellipsoid, and
> > isosurface objects. Quartic and parametric objects do no comply,
> > probably they are not 'solid'? I did not test this thoroughly.
>
> The test (using version 2 of bounder.inc) for quartic objects is
> interesting. Using the Lemniscate object the BB seems to be infinite and
> the test is considered optimal. See image attached.

I think I will add, in the header/comments of the file, a list of "unsuitable
for use with this macro" shapes.  what do you (and others) think?  thanks.


regards, jr.


Post a reply to this message

From: Thomas de Groot
Subject: Re: bounding box calculator
Date: 6 Nov 2019 06:51:13
Message: <5dc2b3b1@news.povray.org>
Op 06/11/2019 om 11:15 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 05/11/2019 om 01:19 schreef jr:
>>> "jr" <cre### [at] gmailcom> wrote:
>>>> ...
>>> also new, if "slack" is reported, two variables with the differences from the
>>> BB's min/max extents are declared, to allow use of the info from in-scene.
>>> after 'Bounder' has run, one can for instance:
>>>
>>> #ifdef(Bounder_min_diff)
>>>     // do something
>>> #end
>>
>> With version 3, I get a parser error in the scene file when the object
>> is considered as near optimal: "Expected 'numeric expression',
>> undeclared 'Bounder_min_diff' found instead"
> 
> pls read the added comments in the file.  the vars are only 'declare'd _if_
> there's any worthwhile "slack" to report.
> 
> the '#ifdef()' idiom though ought to work in any case (it does here).
> 
> 

Yes, I thought so. The problem is not with the macro but with my test 
scene. I shall try to add something there which bypasses this.

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: bounding box calculator
Date: 6 Nov 2019 07:23:30
Message: <5dc2bb42$1@news.povray.org>
Op 06/11/2019 om 11:15 schreef jr:
> the '#ifdef()' idiom though ought to work in any case (it does here).
> 

It does! My bad.

Interesting test following this earlier post:

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
 > - rotating the object changes the 'tightness' of the standard BB. I 
did that with a simple cylinder: when properly aligned along one of the 
axis, the BB test is always optimal; rotate the cylinder (e.g. 
<45,45,45>) and do the test, and the standard BB becomes too wide.
 >

I have to correct this: The BB only becomes slightly less optimal in the 
example cited. With increasing complexity of the object however, 
optimisation kicks in.

(1) use the following object: superellipsoid {<0.50, 3.50>}. The test is 
optimal.

(2) change the object to: superellipsoid {<0.50, 3.50> rotate 45}. The 
BB has now 'at least 5% "slack".'

-- 
Thomas


Post a reply to this message

From: Bald Eagle
Subject: Re: bounding box calculator
Date: 6 Nov 2019 07:25:00
Message: <web.5dc2baac34d8ef064eec112d0@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> > The test (using version 2 of bounder.inc) for quartic objects is
> > interesting. Using the Lemniscate object the BB seems to be infinite and
> > the test is considered optimal. See image attached.
>
> I see the BB change in size when the object is aligned, no idea(s).
> interesting.


I guess add some #debug output, and maybe show some or all of the trace ()
tests, coloring them red or green according to if they "hit" or not.  Show each
successive BB with a different color, and that would help show what was going on
and give a better idea.

I would imagine that if POV-Ray can see and render the object, then the macro
ought to give sensible results.

Given an infinite (or sufficiently large) object along one axis, perhaps a
bounding rectangle (a cross-section of the infinitely long BB) could be shown /
reported.


Maybe after the SVD adventure, we coulld throw some function {} foo in there and
do a semi-transparent isosurface as a representation, which would allow
"infinite" objects to be easily displayed (by 'scaling' one axis to 0)

Just some early-morning thoughts.


Post a reply to this message

From: jr
Subject: Re: bounding box calculator
Date: 6 Nov 2019 08:50:00
Message: <web.5dc2cf5334d8ef06feeb22ff0@news.povray.org>
hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 06/11/2019 om 11:15 schreef jr:
> > the '#ifdef()' idiom though ought to work in any case (it does here).
>
> It does! My bad.
>
> Interesting test following this earlier post:
> ...
> (1) use the following object: superellipsoid {<0.50, 3.50>}. The test is
> optimal.
> (2) change the object to: superellipsoid {<0.50, 3.50> rotate 45}. The
> BB has now 'at least 5% "slack".'

another candidate.  nice.  :-)  (more in reply to BE)


regards, jr.


Post a reply to this message

From: jr
Subject: Re: bounding box calculator
Date: 6 Nov 2019 08:50:01
Message: <web.5dc2cf6234d8ef06feeb22ff0@news.povray.org>
hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > The test (using version 2 of bounder.inc) for quartic objects is
> > > interesting. Using the Lemniscate object the BB seems to be infinite and
> > > the test is considered optimal. See image attached.
> > I see the BB change in size when the object is aligned, no idea(s).
> > interesting.
>
> I guess add some #debug output, and maybe show some or all of the trace ()
> tests, coloring them red or green according to if they "hit" or not.  Show each
> successive BB with a different color, and that would help show what was going on
> and give a better idea.

I'd play with something like that, no doubt, but won't put effort into (cf my
"rant" in an earlier reply to Thomas).

the 'Bounder' does not use 'trace()' though, it's all 'inside()' testing.

> I would imagine that if POV-Ray can see and render the object, then the macro
> ought to give sensible results.

agree, provided the object is amenable to 'inside()' testing.

ideally, I'd like a developer who knows POV-Ray's 'inside()' inside out (pun
intended) to chime in, giving us POV-Ray's "perspective" of processing an object
using 'inside()'.

> Given an infinite (or sufficiently large) object along one axis, perhaps a
> bounding rectangle (a cross-section of the infinitely long BB) could be shown /
> reported.

I'm more inclined[*] to provide a list of unsuitable object types, then the onus
is on the user to avoid things like the "Lemniscate"s reported by Thomas.

[*] currently.

> Maybe after the SVD adventure, we coulld throw some function {} foo in there and
> do a semi-transparent isosurface as a representation, which would allow
> "infinite" objects to be easily displayed (by 'scaling' one axis to 0)

again, nice but who'd write the code?

> Just some early-morning thoughts.

(one hand on keyboard, the other cradling the first cup of coffee, no doubt
:-))


regards, jr.


Post a reply to this message

From: jr
Subject: Re: bounding box calculator
Date: 4 Oct 2020 07:15:01
Message: <web.5f79ad6734d8ef06f5e85bab0@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:
> find attached the second update of the 'Bounder'.
>
> things have changed a little.  now, if the object's BB is found to be "(near)
> optimal", the macro prints that and ends, otherwise, ie having some "slack", the
> macro prints the difference lines as before, plus the optimised extents and
> dimensions, as per Thomas's feedback.
>
> also new, if "slack" is reported, two variables with the differences from the
> BB's min/max extents are declared, to allow use of the info from in-scene.
> after 'Bounder' has run, one can for instance:
>
> #ifdef(Bounder_min_diff)
>   // do something
> #end
>
> so.  version 3.  fingers crossed.
>

posting the 4th, and probably final, version of the 'Bounder', which ties up a
couple of loose ends.

an addition to the code removes existing 'Bounder_{min,max}_diff' variables,
whenever the macro is run.  this means that if you call the macro multiple
times, you can be confident that existing variables were created by the most
recent call.  this then allows automating the (re)bounding of objects, as
illustrated in the code below.

second, I added a thanks to TdG, whose input was (is) appreciated.  kept
forgetting.  :-(


enjoy, jr.


# ------------------------------------------------------------------------

jr@crow:5:bounder$ c### [at] bt1apov
#version 3.8;

global_settings {assumed_gamma 1}

background {color srgbt 0}

#ifndef (global.I)
  #declare I = 0;
#end

#declare R = <20,20,20>;

#switch (I)
  #case (0)
    #debug concat("cylinder","\n")
    #declare O = cylinder {
      0, 1, .25
      translate 5
    };
  #break
  #case (1)
    #debug concat("box","\n")
    #declare O = box {
      0, 1
    };
  #break
  #case (2)
    #debug concat("sphere","\n")
    #declare O = sphere {
      0, 1
    };
  #break
  #case (3)
    #debug concat("blob","\n")
    #declare O = blob {
      threshold .6
      sphere {0, 1, 1}
      scale 2
    };
    #declare R = <25,25,25>;
  #break
  #case (4)
    #debug concat("superellipsoid","\n")
    #declare O = superellipsoid {
      <.5,3.5>
      translate 5
    };
  #break
  #case (5)
    #debug concat("superellipsoid rotated","\n")
    #declare O = superellipsoid {
      <.5,3.5>
      rotate 45
      translate 5
    };
    #declare R = <25,25,25>;
  #break
  #else
    #error concat("oops, no object for I=",str(I,0,0),".\n")
#end

#include "bounder.inc"
Bounder(O,R)

#ifdef (Bounder_min_diff)
  #local nlb_ = min_extent(O) + Bounder_min_diff;
  #local nub_ = max_extent(O) - Bounder_max_diff;
  #declare O = object {
    O
    clipped_by {box {nlb_, nub_}}
    bounded_by {clipped_by}
  };
#end

Bounder(O,R)


jr@crow:6:bounder$ povparse bt1a.pov declare=I=5
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
   ...
==== [Parsing...] ==========================================================
superellipsoid rotated
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <25, 25, 25>
       min_extent "as is" BB: <3.499850, 3.499850, 3.292722>
       max_extent "as is" BB: <6.500150, 6.500150, 6.707277>
       BB aligned dimensions: <3.000300, 3.000300, 3.414555>
    'X' axis scan resolution: 75
              scans per face: 6375
         scan axis increment: 0.04000400
          face col increment: 0.04017124
          face row increment: 0.04000400
                           -: ...scanning...
Parsing 5069K tokensParsing 10221K tokens
              inside() calls: 280500
    'Y' axis scan resolution: 75
              scans per face: 6375
         scan axis increment: 0.04000400
          face col increment: 0.04000400
          face row increment: 0.04017124
                           -: ...scanning...
Parsing 15363K tokensParsing 20530K tokens
              inside() calls: 153000
    'Z' axis scan resolution: 85
              scans per face: 5625
         scan axis increment: 0.04017124
          face col increment: 0.04000400
          face row increment: 0.04000400
                           -: ...scanning...
Parsing 25672K tokensParsing 30802K tokens
              inside() calls: 225000

  object bounding box has at least 5% "slack".

      difference from BB min: <0.800080, 0.400040, 0.723082>
      difference from BB max: <0.800080, 0.400040, 0.723082>
     min_extent optimised BB: <4.299930, 3.899890, 4.015805>
     max_extent optimised BB: <5.700070, 6.100110, 5.984195>
     BB optimised dimensions: <1.400140, 2.200220, 1.968391>
------------------------------------------------------------------------
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <25, 25, 25>
       min_extent "as is" BB: <4.299930, 3.899890, 4.015805>
       max_extent "as is" BB: <5.700070, 6.100110, 5.984195>
       BB aligned dimensions: <1.400140, 2.200220, 1.968391>
    'X' axis scan resolution: 35
              scans per face: 2695
         scan axis increment: 0.04000400
          face col increment: 0.04017124
          face row increment: 0.04000400
                           -: ...scanning...
              inside() calls: 10780
    'Y' axis scan resolution: 55
              scans per face: 1715
         scan axis increment: 0.04000400
          face col increment: 0.04000400
          face row increment: 0.04017124
                           -: ...scanning...
              inside() calls: 6860
    'Z' axis scan resolution: 49
              scans per face: 1925
         scan axis increment: 0.04017124
          face col increment: 0.04000400
          face row increment: 0.04000400
                           -: ...scanning...
              inside() calls: 7700

  object bounding box is (near) optimal.
------------------------------------------------------------------------
File 'bt1a.pov' line 295: Parse Warning: No objects in scene.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

jr@crow:7:bounder$ povparse bt1a.pov declare=I=0
  ...
==== [Parsing...] ==========================================================
cylinder
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <20, 20, 20>
       min_extent "as is" BB: <4.750000, 4.750000, 4.711325>
       max_extent "as is" BB: <6.250000, 6.250000, 6.288675>
       BB aligned dimensions: <1.500000, 1.500000, 1.577350>
    'X' axis scan resolution: 30
              scans per face: 960
         scan axis increment: 0.05000000
          face col increment: 0.04929219
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 3840
    'Y' axis scan resolution: 30
              scans per face: 960
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.04929219
                           -: ...scanning...
              inside() calls: 3840
    'Z' axis scan resolution: 32
              scans per face: 900
         scan axis increment: 0.04929219
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 5400

  object bounding box is good, less than 5% "slack".

      difference from BB min: <0.000000, 0.000000, 0.049292>
      difference from BB max: <0.000000, 0.000000, 0.049292>
     min_extent optimised BB: <4.750000, 4.750000, 4.760617>
     max_extent optimised BB: <6.250000, 6.250000, 6.239383>
     BB optimised dimensions: <1.500000, 1.500000, 1.478766>
------------------------------------------------------------------------
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <20, 20, 20>
       min_extent "as is" BB: <4.750000, 4.750000, 4.760617>
       max_extent "as is" BB: <6.250000, 6.250000, 6.239383>
       BB aligned dimensions: <1.500000, 1.500000, 1.478766>
    'X' axis scan resolution: 30
              scans per face: 900
         scan axis increment: 0.05000000
          face col increment: 0.04929219
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 3600
    'Y' axis scan resolution: 30
              scans per face: 900
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.04929219
                           -: ...scanning...
              inside() calls: 3600
    'Z' axis scan resolution: 30
              scans per face: 900
         scan axis increment: 0.04929219
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 3600

  object bounding box is (near) optimal.
------------------------------------------------------------------------
File 'bt1a.pov' line 295: Parse Warning: No objects in scene.


Post a reply to this message


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

From: Kenneth
Subject: Re: bounding box calculator
Date: 5 Oct 2020 00:35:01
Message: <web.5f7aa1c334d8ef06d98418910@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

>
> posting the 4th, and probably final, version of the 'Bounder', which ties up a
> couple of loose ends.
>
I'm coming late to this discussion, sorry that I never saw it earlier.

This looks useful for my current 'city buildings' scene, particularly for my
'rooftop greebles' and their correct placement.

Thanks for all the hard work (and Thomas too for his earlier testing and
suggestions.)


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.