After showing a first version of osculatory sphere packings in 
BaldEagle's "Pappus Chain" thread, I couldn't let the topic rest.

https://news.povray.org/povray.advanced-users/message/%3C66a14899%40news.povray.org%3E/#%3C66a14899%40news.povray.org%3E

In the image mentioned above, I cancelled the process after nine 
iteration steps in each packing. In the examples shown here, I have 
ended the process after 13 ‘generations’, which exhausts the 
possibilities of POV on my machine (Core I9 with 32GB RAM). Each of the 
following sphere packings consists of a total of 16,099,560 individual 
balls. With 14 generations one reaches a total of 54,118,529 spheres, 
which is beyond the capabilities of my machine.
In these pictures I have always used the initial configuration with the 
curvatures 1,2,2,3,3 (i.e. the radii 1,1/2,1/2,1/3,1/3), which all 
authors seem to agree on calling ‘apollonian’.
Even though the CGSphere competition was shut down in 2018, I used the 
scenario demanded there back then. The first image shows the Apollonian 
sphere packing in front of this classic CGSphere background with the 
material from the first image mentioned above: It still looks quite nice 
here, but in my eyes looks better in the first image.

Post a reply to this message

Attachments:
Download '20240911osp_cgsphere_1920.png' (2109 KB)

Preview of image '20240911osp_cgsphere_1920.png'

In the second image, the sphere packing has been opened by omitting all 
spheres whose centres are located within two spheres on the left and 
right above the packing.

Post a reply to this message

Attachments:
Download '20240913osp_cgsphere_2_1920.png' (1630 KB) Download '20240914osp_cgsphere_2b_1920.png' (1629 KB)

Preview of image '20240913osp_cgsphere_2_1920.png'

Preview of image '20240914osp_cgsphere_2b_1920.png'

In the third image, I modified texture 79 from Norbert Kern's material 
collection and an HDRI environment with an image from NASA.
https://svs.gsfc.nasa.gov/4851/
Here, the first three generations have been omitted and replaced by 
simple light sources.

Post a reply to this message

Attachments:
Download '20240912osp_cgsphere_4_1920.png' (3282 KB)

Preview of image '20240912osp_cgsphere_4_1920.png'

The last is an update to the image in
https://news.povray.org/povray.advanced-users/message/%3C66a14899%40news.povray.org%3E/#%3C66a14899%40news.povray.org%3E
with 13 instead of 9 generations and a modified glass material.

And now I'm done with packings for the near future ...

Best regards,
Michael

Post a reply to this message

Attachments:
Download '20240914apollonian_spheres_01d_1920.png' (561 KB)

Preview of image '20240914apollonian_spheres_01d_1920.png'

MichaelJF <fri### [at] t-onlinede> wrote:
> In the examples shown here, I have

> possibilities of POV on my machine (Core I9 with 32GB RAM). Each of the
> following sphere packings consists of a total of 16,099,560 individual
> balls. With 14 generations one reaches a total of 54,118,529 spheres,
> which is beyond the capabilities of my machine.

I find this interesting.
Somehow that doesn't seem like a lot of spheres for those system specs.

1. What happens when you "exceed the capabilities"?
2. Is there any difference if you use blobs?
3. Do you think that happens because each sphere is assigned it's own individual
texture?  What happens if they're all union[ed] and given a single texture?
4. What happens if you make a sphere mesh and simply translate and scale that,
instead of instantiating a new sphere {} ?


Very nice work!  I'm glad you pursued this topic with all of the subsequent
renders :)
How long did it take you to adapt this to 3D, and how much extra code is there?

I especially like the version with the missing spheres - you can clearly see the
inner Pappas chain(s) inside the outer bounding sphere, which is such a cool
effect!

Maybe just honor one request - do one with iridescent bubbles.  :)

- BW

Post a reply to this message

Le 2024-09-16 à 12:25, Bald Eagle a écrit :
> MichaelJF <fri### [at] t-onlinede> wrote:
>> In the examples shown here, I have
>> ended the process after 13 ‘generations’, which exhausts the
>> possibilities of POV on my machine (Core I9 with 32GB RAM). Each of the
>> following sphere packings consists of a total of 16,099,560 individual
>> balls. With 14 generations one reaches a total of 54,118,529 spheres,
>> which is beyond the capabilities of my machine.
> 
> I find this interesting.
> Somehow that doesn't seem like a lot of spheres for those system specs.
> 
> 1. What happens when you "exceed the capabilities"?
> 2. Is there any difference if you use blobs?
> 3. Do you think that happens because each sphere is assigned it's own individual
> texture?  What happens if they're all union[ed] and given a single texture?
> 4. What happens if you make a sphere mesh and simply translate and scale that,
> instead of instantiating a new sphere {} ?
I don't think that it would help.
As I understand it :
A minimal sphere is defined by it's centre and radius. A translated 
sphere sees it's centre point modified by the translation, so, no added 
translation component. That's a vector and a float = 4 floats.
For a mesh, that would be a translation and a scaling. That's two 
vectors= 6 floats, or two extra floats.

In both cases, individually assigning a texture would add the texture 
definition to each object.

> 
> 
> Very nice work!  I'm glad you pursued this topic with all of the subsequent
> renders :)
> How long did it take you to adapt this to 3D, and how much extra code is there?
> 
> I especially like the version with the missing spheres - you can clearly see the
> inner Pappas chain(s) inside the outer bounding sphere, which is such a cool
> effect!
> 
> Maybe just honor one request - do one with iridescent bubbles.  :)
> 
> - BW
> 
> 
>

Post a reply to this message

Le 2024-09-16 à 11:40, MichaelJF a écrit :
> After showing a first version of osculatory sphere packings in 
> BaldEagle's "Pappus Chain" thread, I couldn't let the topic rest.
> 
>
https://news.povray.org/povray.advanced-users/message/%3C66a14899%40news.povray.org%3E/#%3C66a14899%40news.povray.org%3E
> 
WOW !
Those are very impressive.

Post a reply to this message

Am 16.09.2024 um 18:25 schrieb Bald Eagle:

> 
> I find this interesting.
> Somehow that doesn't seem like a lot of spheres for those system specs.

Yes indeed, you're right. While parsing the 14 generation version I got 
the message:

"OSP05_CE_3_0_14_244110_onlySpheres.inc" line 54118526: Parse Error: 
Expected 'numeric expression', ,  found instead

Render failed

But there is no single syntax error in this include-file which was 
automatically generated by another render. And since the 13 generation 
version used some 16 GB peak memory I assumed that there was not enough 
memory for the larger version. But in the meantime I have also been able 
to render the version with 14 generations. There seems to be another 
limit I reached. Most likely the size of an include file may not exceed 
2GB, since after dividing the original file of some 4 GB into smaller 
pieces (< GB) all went well.

But I think, one has to meet a compromise between the number of balls 
and the possibilities to depict them. IMO, 13 generations is a good setting.


> Very nice work!  I'm glad you pursued this topic with all of the subsequent
> renders :)

Thank you!

> How long did it take you to adapt this to 3D, and how much extra code is there?

I didn't used the algorithm from

https://news.povray.org/povray.advanced-users/message/%3C6670942f%40news.povray.org%3E/#%3C6670942f%40news.povray.org%3E

but wrote an approach after formula (3.25) from

https://arxiv.org/pdf/math/0010298

first for the 2D-case which was straightforward and caused no problems. 
Then I implemented the same idea in 3D and could calculate all balls. 
Unfortunately, not just once. Many spheres occurred several times, 
sometimes several hundred times. I made some progress in finding rules 
to avoid repetitions but couldn't get rid of all the duplicates.

Now that I had been working on the topic for a while, I recognised my 
reflection matrices in the code given by Esperanca, which I hadn't been 
able to do at first, and was able to convert his rules to POV.

https://observablehq.com/@esperanc/3d-apollonian-sphere-packings

> Maybe just honor one request - do one with iridescent bubbles.  :)

Maybe, but this renders a while...

global_settings { max_trace_level infinity }


Best regards
Michael

Post a reply to this message

MichaelJF <fri### [at] t-onlinede> wrote:


> But I think, one has to meet a compromise between the number of balls
> and the possibilities to depict them. IMO, 13 generations is a good setting.

It's interesting that you're doing this with an include file!
How long does it take to parse the scene that writes the .inc file?
How much faster does it parse when reading the .inc and not calculating the
sphere parameters?
Would it go faster without writing to a file?
And you're right - at some point, the size of a sphere will be less than a pixel
- so why bother.

Now, in order to massively cut down on the number of actual spheres that you
need to use, I was wondering if you could somehow test for tangency with the
outer enclosing sphere and only render those spheres. (maybe 1 additional
layer...?)
It would take longer to parse, but then you could write a much smaller .inc.

You _might_ be able to test for tangency with the spheres that you subtract as
well, for the "cutaway" renders.


> Now that I had been working on the topic for a while, I recognised my
> reflection matrices in the code given by Esperanca, which I hadn't been
> able to do at first, and was able to convert his rules to POV.
>
> https://observablehq.com/@esperanc/3d-apollonian-sphere-packings

That looks familiar - I might have that in a pile of papers that I haven't
gotten to yet.  All of the IRL stuff has been exploding, to eat up the otherwise
free hours.

> > Maybe just honor one request - do one with iridescent bubbles.  :)
>
> Maybe, but this renders a while...
>
> global_settings { max_trace_level infinity }

Just an idea  ;)

Also another idea... (just to jot it down here)
All of the spheres tangent to the outer enclosing sphere could be
stereographically projected onto the plane...  :D

- BW

Post a reply to this message

> It's interesting that you're doing this with an include file!
> How long does it take to parse the scene that writes the .inc file
IIRC, some 90-120 minutes with 13 generations.

> How much faster does it parse when reading the .inc and not calculating the
> sphere parameters?

10-15 minutes, and you can use the file for other representations. The 
first four images in this post show all the same include file.

> Would it go faster without writing to a file?

Not if you plan to reuse the include-file.

> And you're right - at some point, the size of a sphere will be less than a pixel
> - so why bother.

Especially when one has in mind to depict the spheres as soap bubbles 
one has to avoid very small ones;)

> Now, in order to massively cut down on the number of actual spheres that you
> need to use, I was wondering if you could somehow test for tangency with the
> outer enclosing sphere and only render those spheres. (maybe 1 additional
> layer...?)

That was the riddle. To generate all spheres but only once. Without 
testing. If they fulfill the Descartes-rule tangency test are 
superflous. This is what the rule-set of Claudio Esperanca does. There 
is an article by David W. Boyd from 1973, who developed a similar (?) 
rule-set.

https://www.ams.org/journals/mcom/1973-27-122/S0025-5718-1973-0338937-6/S0025-5718-1973-0338937-6.pdf

But I did and do not understand his arguments.

Best regards
Michael

Post a reply to this message