 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Thomas de Groot <tho### [at] degroot org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
