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

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

> > 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.

Ah, but that's not what I'm suggesting.
Yes, it would be best to only _calculate_ the parameters for every unique sphere
only once - however; since we can only see the outer layer of spheres in the
render, then we only need to _save_ those in the include file.
So, you could take the radius of the outer enclosing sphere, subtract the radius
of the current sphere, and see if that's equal to the distance of the sphere's
center from the origin.  If it is, save it, if the distance to the center is
less, then it's inside of the outer shell of spheres and therefore not visible.

I think that would also be a much better object to illuminate from the inside.
:)

I would also think that, given symmetry considerations, one could further only
calculate a subset of the whole spherical collection, and simply rotate a lot of
spheres around the origin in order to further minimize calculations.
(granted, this is fussy, and as Boyd says, "It can be shown, with some effort .
.. ." ;) that this is possible)

- BW

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> MichaelJF <fri### [at] t-onlinede> wrote:
> > ...
> 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!

+1.  I think that "nibbling" deeper and deeper into the arrangement of spheres
would make a real cool animation.


regards, jr.

Post a reply to this message

Il 16/09/2024 17:40, MichaelJF ha scritto:
> 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
> [...]

The third image is fascinating!

Paolo

Post a reply to this message