POV-Ray : Newsgroups : povray.binaries.images : Box division Server Time27 Nov 2022 07:54:57 EST (-0500)
 Box division (Message 1 to 10 of 17)
 From: Samuel B  Subject: Box division Date: 22 Sep 2021 19:05:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614bb60b76fb524ccb705ca46e741498%40news.povray.org",
"dateCreated": "2021-09-22T23:05:00+00:00",
"datePublished": "2021-09-22T23:05:00+00:00",
"author": {
"@type": "Person",
"name": "Samuel B "
}
}
Hi,

I was looking through old files for something else and came across this scene.
Since I can't remember if I ever posted it or not, I am doing so now!

The basic idea is that you have a cuboid. The longest dimension gets split
somewhere along its length. The algorithm then evaluates the resulting cuboids
and performs the same operation over and over again. In this scene the boxes are
inset by a certain thickness at each iteration, and they are drawn with polar
geometry using cylinders, tori and spheres.

(If your system is capable of handling shaders, here's a real time 2D

~Sam

Source for this file:

/*

BoxDivideB.pov
2016-2021 Samuel B.
+fn +f +a0.3 +am2 +r1

*/

#version 3.7;

#include "math.inc"
#include "shapes.inc"

#macro Lerp(A, B, C) A*(1-C) + B*C #end

// I believe Rune made this
#macro Z_Align( Normal_vector, Z_vector )
#local ObjectZ = vnormalize( Z_vector );
#local ObjectY = VPerp_Adjust( Normal_vector, Z_vector );
#local ObjectX = vcross( ObjectY, ObjectZ );
transform{ Shear_Trans( ObjectX, ObjectY, ObjectZ ) }
#end

global_settings{
assumed_gamma 1.0
#if(1)
count 1
error_bound .1
recursion_limit 1
nearest_count 10
normal on
}
#end
}

#default{ finish{ambient 0} }

#declare Seed = seed(1002);
#declare SunDir = <-1, .5, -.25>;
#declare RGBSun = srgb .74*<2, 1.95, 1.8>;
#declare RGBSky = rgb <.1, .2, .4>;
#declare CamPos = <0, 4, -8>;

camera{
right x*16/9 up y
location CamPos
look_at .67*y
angle 60/2.7
aperture .25 focal_point y/2 blur_samples 20 variance 0
}

// sunlight
#if(1)
light_source{
SunDir*1e7, RGBSun
#if(1)
#declare ALRes = 2;
#declare ALSize = .03*1e7;
area_light x*ALSize, z*ALSize, ALRes, ALRes
jitter
area_illumination
#end
}
#end

#if(1)
sky_sphere{
pigment{
spherical scale 2 translate z
poly_wave 2
Z_Align(-y, SunDir)
color_map{
[0 RGBSky]
[1 RGBSun]
}
}
}
#end

#macro WireBox(C1, C2, Thk)
cylinder{<C1.x, C1.y, C1.z>, <C2.x, C1.y, C1.z>, Thk}
cylinder{<C1.x, C1.y, C2.z>, <C2.x, C1.y, C2.z>, Thk}
cylinder{<C1.x, C2.y, C1.z>, <C2.x, C2.y, C1.z>, Thk}
cylinder{<C1.x, C2.y, C2.z>, <C2.x, C2.y, C2.z>, Thk}
cylinder{<C1.x, C1.y, C1.z>, <C1.x, C2.y, C1.z>, Thk}
cylinder{<C2.x, C1.y, C1.z>, <C2.x, C2.y, C1.z>, Thk}
cylinder{<C1.x, C1.y, C2.z>, <C1.x, C2.y, C2.z>, Thk}
cylinder{<C2.x, C1.y, C2.z>, <C2.x, C2.y, C2.z>, Thk}
cylinder{<C1.x, C1.y, C1.z>, <C1.x, C1.y, C2.z>, Thk}
cylinder{<C1.x, C2.y, C1.z>, <C1.x, C2.y, C2.z>, Thk}
cylinder{<C2.x, C1.y, C1.z>, <C2.x, C1.y, C2.z>, Thk}
cylinder{<C2.x, C2.y, C1.z>, <C2.x, C2.y, C2.z>, Thk}

sphere{<C1.x, C1.y, C1.z>, Thk}
sphere{<C2.x, C1.y, C1.z>, Thk}
sphere{<C1.x, C2.y, C1.z>, Thk}
sphere{<C2.x, C2.y, C1.z>, Thk}
sphere{<C1.x, C1.y, C2.z>, Thk}
sphere{<C2.x, C1.y, C2.z>, Thk}
sphere{<C1.x, C2.y, C2.z>, Thk}
sphere{<C2.x, C2.y, C2.z>, Thk}
#end

#macro WireBox_Wedge(C1, C2, Thk)
#local A1 = degrees(C1.x);
#local A2 = degrees(C2.x);
#local Wedge_ = object{Wedge(A2-A1) rotate y*A1}
torus{C1.z, Thk clipped_by{Wedge_} translate y*C1.y}
torus{C1.z, Thk clipped_by{Wedge_} translate y*C2.y}
torus{C2.z, Thk clipped_by{Wedge_} translate y*C1.y}
torus{C2.z, Thk clipped_by{Wedge_} translate y*C2.y}
cylinder{<0, C1.y, C1.z>, <0, C2.y, C1.z>, Thk rotate y*A1}
cylinder{<0, C1.y, C1.z>, <0, C2.y, C1.z>, Thk rotate y*A2}
cylinder{<0, C1.y, C2.z>, <0, C2.y, C2.z>, Thk rotate y*A1}
cylinder{<0, C1.y, C2.z>, <0, C2.y, C2.z>, Thk rotate y*A2}

cylinder{<0, C1.y, C1.z>, <0, C1.y, C2.z>, Thk rotate y*A1}
cylinder{<0, C1.y, C1.z>, <0, C1.y, C2.z>, Thk rotate y*A2}
cylinder{<0, C2.y, C1.z>, <0, C2.y, C2.z>, Thk rotate y*A1}
cylinder{<0, C2.y, C1.z>, <0, C2.y, C2.z>, Thk rotate y*A2}

sphere{<0, C1.y, C1.z>, Thk rotate y*A1}
sphere{<0, C2.y, C1.z>, Thk rotate y*A2}
sphere{<0, C1.y, C2.z>, Thk rotate y*A1}
sphere{<0, C2.y, C2.z>, Thk rotate y*A2}
sphere{<0, C1.y, C1.z>, Thk rotate y*A2}
sphere{<0, C2.y, C1.z>, Thk rotate y*A1}
sphere{<0, C1.y, C2.z>, Thk rotate y*A2}
sphere{<0, C2.y, C2.z>, Thk rotate y*A1}
#end

// corner 1, corner 2, iterations (counting down)
#macro boxDivide(C1, C2, I)
#local Gap = .01;
#local Size = <abs(C2.x-C1.x), abs(C2.y-C1.y), abs(C2.z-C1.z)>;

#if(1)
WireBox_Wedge(C1, C2, Gap)
#else
WireBox(C1, C2, Gap)
#end

#local R = Lerp(.5, rand(Seed), .5);

#if(I>0)
#if(Size.x>=Size.y & Size.x>=Size.z) // x is greater than or equal to y &/ z

boxDivide(<Lerp(C1.x, C2.x, R), C1.y, C1.z>+Gap, C2-Gap, I-1)
boxDivide(C1+Gap, <Lerp(C1.x, C2.x, R), C2.y, C2.z>-Gap, I-1)

#else
#if(Size.y>=Size.z) // y is greater than or equal to z

boxDivide(<C1.x, Lerp(C1.y, C2.y, R), C1.z>+Gap, C2-Gap, I-1)
boxDivide(C1+Gap, <C2.x, Lerp(C1.y, C2.y, R), C2.z>-Gap, I-1)

#else // z

boxDivide(<C1.x, C1.y, Lerp(C1.z, C2.z, R)>+Gap, C2-Gap, I-1)
boxDivide(C1+Gap, <C2.x, C2.y, Lerp(C1.z, C2.z, R)>-Gap, I-1)
#end
#end
#end
#end

union{
boxDivide(<-pi/3, -.5, .5>, <pi/3, .5, 1.5>, 7)
rotate -x*20
pigment{rgb .57}
normal{granite .1 scale .001}
}
```

Attachments:

Preview of image 'boxdivideb17m_43s.jpg'

 From: Kenneth Subject: Re: Box division Date: 23 Sep 2021 18:10:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614cfaa5154a1cc34cef624e6e066e29%40news.povray.org",
"dateCreated": "2021-09-23T22:10:00+00:00",
"datePublished": "2021-09-23T22:10:00+00:00",
"author": {
"@type": "Person",
"name": "Kenneth"
}
}
Wow, that is really impressive. I want to go through the code in detail, to see
how and why it works-- especially the Lerp(...) macro.

Rune's sky_sphere orienting macro is also interesting and complex, with its
several inner operations; I had not seen that kind of thing before.

Thanks for posting!
```
 From: Samuel B  Subject: Re: Box division Date: 23 Sep 2021 19:05:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614d0785154a1cc3cb705ca46e741498%40news.povray.org",
"dateCreated": "2021-09-23T23:05:00+00:00",
"datePublished": "2021-09-23T23:05:00+00:00",
"author": {
"@type": "Person",
"name": "Samuel B "
}
}
"Kenneth" <kdw### [at] gmailcom> wrote:
> Wow, that is really impressive. I want to go through the code in detail, to see
> how and why it works-- especially the Lerp(...) macro.
>
> Rune's sky_sphere orienting macro is also interesting and complex, with its
> several inner operations; I had not seen that kind of thing before.
>
> Thanks for posting!

Hi again,

The Z_Align macro is not only good for sky_spheres, it's good for many things.
Depending on what you want to do it can be a better alternative to
Point_At_Trans, since it gives you more control over the final orientation.

The Lerp macro is for linear interpolation. It just makes it easier to choose an
arbitrary value between A and B. I could have made the scene without it, but
decided to use it since it simplifies the code a bit. (But looking at it now, I
should have declared a variable to reduce computation times and to keep the code
cleaner, haha.)

Sam
```
 From: Thomas de Groot Subject: Re: Box division Date: 24 Sep 2021 09:20:25 Message: <614dd099\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#614dd099%241%40news.povray.org",
"dateCreated": "2021-09-24T13:20:25+00:00",
"datePublished": "2021-09-24T13:20:25+00:00",
"author": {
"@type": "Person",
"name": "Thomas de Groot"
}
}
Op 23-9-2021 om 01:02 schreef Samuel B.:
> Hi,
>
> I was looking through old files for something else and came across this scene.
> Since I can't remember if I ever posted it or not, I am doing so now!
>
Stop it! Again, one of those things I /need/ to try out. When am I going
to get some well-earned rest, by Jove?

--
Thomas
```
 From: William F Pokorny Subject: Re: Box division Date: 24 Sep 2021 11:33:28 Message: <614defc8\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#614defc8%241%40news.povray.org",
"dateCreated": "2021-09-24T15:33:28+00:00",
"datePublished": "2021-09-24T15:33:28+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
On 9/22/21 7:02 PM, Samuel B. wrote:
> I was looking through old files for something else and came across this scene.
> Since I can't remember if I ever posted it or not, I am doing so now!

Neat! I don't recall seeing a previous post.

Your scene turned out to be a useful performance test case for my povr
branch! Some years back I turned off extra on the fly bounding in
torus.cpp done with a function called: Test_Thick_Cylinder(). It first
looks for intersections on both an inner and outer cylinder before
trying find the true ray->torus intersections.

Why? I'd found my way to the routine - or a similar one in a different
shape (lathe?) - chasing a bug. On fixing it, ran on the torus solver
test cases I had and it didn't seem to help or hurt too much. Sometimes
slower, sometimes faster. I also didn't like that it was more bounding
in front of the final ray-surface solver which I could not turn off by
option.

Well, by Jove, The automatic bounding for:

...
torus{C1.z, Thk clipped_by{Wedge_} translate y*C1.y}
torus{C1.z, Thk clipped_by{Wedge_} translate y*C2.y}
torus{C2.z, Thk clipped_by{Wedge_} translate y*C1.y}
torus{C2.z, Thk clipped_by{Wedge_} translate y*C2.y}
...

is poor and without the extra Test_Thick_Cylinder() your scene is 48%
slower in povr than v3.8 beta 2!

For now, going back to using Test_Thick_Cylinder() as I don't remember
the slower cases with it being anywhere near 48% slower. Good protection
against extremes I guess.

Someday need to play with something for arcs based upon 'carefully'
placed blobs - or maybe some kind of tori slice and dice into a union
for performance. My expectation is we can do better than that internal
Test_Thick_Cylinder() test bounding wise.

Better optimization for +bm2 suppose a general idea worth a look any
time we get into non-orthogonal 'stuff'. Someday...

Bill P.
```
 From: Kenneth Subject: Re: Box division Date: 24 Sep 2021 14:20:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614e1466154a1cc34cef624e6e066e29%40news.povray.org",
"dateCreated": "2021-09-24T18:20:00+00:00",
"datePublished": "2021-09-24T18:20:00+00:00",
"author": {
"@type": "Person",
"name": "Kenneth"
}
}
"Samuel B." <stb### [at] hotmailcom> wrote:
>
> I was looking through old files for something else and came across this scene.

I like to use animation, along with a changing code value somewhere, just to see
what happens with scenes. Here's a test, changing your 'gap' value...

// corner 1, corner 2, iterations (counting down)
#macro boxDivide(C1, C2, I)
#local Gap = .06 - .057*clock; // originally set at 0.01
..........

I picked out three representative images (no radiosity or focal-blur, for
quicker renders). Fun!

#include "math.inc"
#include "shapes.inc"

.......I commented-out "shapes.inc" and instead pulled out the needed code
snippets from the various include files, and stuck them directly into your
scene...just to be slightly more efficient ;-)

// [from "shapes.inc]
#macro Wedge(Angle)
#local A = clamp(Angle, 0, 360);
#if(A < 180)
difference {
plane {-x, 0}
plane {-x, 0 rotate y*A}
}
#else
#if(A = 180)
plane {-x, 0}
#else
intersection {
plane {x, 0}
plane {-x, 0 rotate y*A}
inverse
}
#end
#end
#end

// [from "transforms.inc", which happens to be #included in "shapes.inc"]
#macro Shear_Trans(A, B, C)
transform {
matrix < A.x, A.y, A.z,
B.x, B.y, B.z,
C.x, C.y, C.z,
0, 0, 0>
}
#end
```

Attachments:

Preview of image 'gap_changed_via_clock.jpg'

 From: Samuel B  Subject: Re: Box division Date: 24 Sep 2021 21:45:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614e7e6f154a1cc3cb705ca46e741498%40news.povray.org",
"dateCreated": "2021-09-25T01:45:00+00:00",
"datePublished": "2021-09-25T01:45:00+00:00",
"author": {
"@type": "Person",
"name": "Samuel B "
}
}
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 23-9-2021 om 01:02 schreef Samuel B.:
> > Hi,
> >
> > I was looking through old files for something else and came across this scene.
> > Since I can't remember if I ever posted it or not, I am doing so now!
> >
> Stop it! Again, one of those things I /need/ to try out. When am I going
> to get some well-earned rest, by Jove?

If you're not quite kidding, then maybe try to get some more sleep? Maybe eat
some tryptophan-rich cheese? ;)

Speaking of Jove, he probably does help us rest a bit more easily, with his
propensity of tugging away at cosmic threats and whatnot :)

Btw, did you ever hear the sounds the planets make? Not actual sounds, but radio
emissions. Great stuff. I like Jupiter the most. https://youtu.be/vDoRIXQxAqA

Sam
```
 From: Thomas de Groot Subject: Re: Box division Date: 25 Sep 2021 03:13:30 Message: <614ecc1a\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#614ecc1a%241%40news.povray.org",
"dateCreated": "2021-09-25T07:13:30+00:00",
"datePublished": "2021-09-25T07:13:30+00:00",
"author": {
"@type": "Person",
"name": "Thomas de Groot"
}
}
Op 25/09/2021 om 03:42 schreef Samuel B.:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 23-9-2021 om 01:02 schreef Samuel B.:
>>> Hi,
>>>
>>> I was looking through old files for something else and came across this scene.
>>> Since I can't remember if I ever posted it or not, I am doing so now!
>>>
>> Stop it! Again, one of those things I /need/ to try out. When am I going
>> to get some well-earned rest, by Jove?
>
> If you're not quite kidding, then maybe try to get some more sleep? Maybe eat
> some tryptophan-rich cheese? ;)
>
The cheese did help! :-)

> Speaking of Jove, he probably does help us rest a bit more easily, with his
> propensity of tugging away at cosmic threats and whatnot :)
>
Oh, certainly! After he almost helped us to kingdom come in the early
days of the solar system (there was an very interesting series about the
planets on the BBC, presented by Brian Cox, where that was explained).

> Btw, did you ever hear the sounds the planets make? Not actual sounds, but radio
> emissions. Great stuff. I like Jupiter the most. https://youtu.be/vDoRIXQxAqA
>
I shall listen...

--
Thomas
```
 From: jr Subject: Re: Box division Date: 25 Sep 2021 04:45:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614ee0d2154a1cc380468f836cde94f1%40news.povray.org",
"dateCreated": "2021-09-25T08:45:00+00:00",
"datePublished": "2021-09-25T08:45:00+00:00",
"author": {
"@type": "Person",
"name": "jr"
}
}
hi,

"Samuel B." <stb### [at] hotmailcom> wrote:
> ...
> Btw, did you ever hear the sounds the planets make? Not actual sounds, but radio
> emissions. Great stuff. I like Jupiter the most. {...}

interesting.  fwiw, Titan is nice, musical even, intriguing how similar Neptune
+ Earth sound.

regards, jr.
```
 From: Samuel B  Subject: Re: Box division Date: 25 Sep 2021 18:20:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#web.614fa042154a1cc3cb705ca46e741498%40news.povray.org",
"dateCreated": "2021-09-25T22:20:00+00:00",
"datePublished": "2021-09-25T22:20:00+00:00",
"author": {
"@type": "Person",
"name": "Samuel B "
}
}
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/22/21 7:02 PM, Samuel B. wrote:
> > I was looking through old files for something else and came across this scene.
> > Since I can't remember if I ever posted it or not, I am doing so now!
>
> Neat! I don't recall seeing a previous post.
>
> is poor and without the extra Test_Thick_Cylinder() your scene is 48%
> slower in povr than v3.8 beta 2!

I did consider doing some 'manual' bounding for the tori (boxes sized to
encompass only the clipped objects), but I'm not sure how much it would actually
help since there would still be plenty of empty space where no ray could ever
make an intersection.

> Someday need to play with something for arcs based upon 'carefully'
> placed blobs -

Are you talking about using blobs as the bounding objects, to take advantage of
their bounding performance vs. the toruses' bounding performance?

> or maybe some kind of tori slice and dice into a union
> for performance. My expectation is we can do better than that internal
> Test_Thick_Cylinder() test bounding wise.

Slicing and dicing tori for smaller bounding objects? Sound complex...

One thing I've noticed about slicing objects (using clipped_by, open geometry,
etc.) and putting them into a union, is that weird artifacts can appear when
rendering them. Especially if transparency in involved.

Sam

Sam
```