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.

Sorry about the lack of useful comments in the code ':|

(If your system is capable of handling shaders, here's a real time 2D
implementation: https://www.shadertoy.com/view/XlV3DW)

~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)
  radiosity{
   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
   adaptive 1
   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}
}

Post a reply to this message

Attachments:
Download 'boxdivideb17m_43s.jpg' (93 KB)

Preview of image 'boxdivideb17m_43s.jpg'

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!

Post a reply to this message

"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

Post a reply to this message

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

Post a reply to this message

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.

Post a reply to this message

"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!

BTW, instead of this...

#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

Post a reply to this message

Attachments:
Download 'gap_changed_via_clock.jpg' (122 KB)

Preview of image 'gap_changed_via_clock.jpg'

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

Post a reply to this message

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

Post a reply to this message

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.

Post a reply to this message

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

Post a reply to this message