3D.lua

[muzik]

New neighbourhood suggestion: currently hexagonal rules are simulated using a square grid neighbourhood which resembles the intersection of two 2x2 squares. How about adding a new neighbourhood which comes about as the intersection of two 2x2x2 blocks (with the one intersecting cell being the center)? It probably wouldn't be as good an analogue as the hexahedral neighbourhoood but would be interesting to see.

[Andrew]

New neighbourhood suggestion: ...

Given the lack of interest in the currently supported neighborhoods I'd have to say the chances of me implementing a new one are zilch.

[muzik]

Is 3D.lua tied to the currently set refresh rate? Patterns seem to whizz past compared to normal 2D Golly patterns, leading to the conclusion that it's using the 144hz monitor refresh rate rather than a fixed 60fps (which is preferable for some things, but not always others).

[rowett]

Is 3D.lua tied to the currently set refresh rate? Patterns seem to whizz past compared to normal 2D Golly patterns, leading to the conclusion that it's using the 144hz monitor refresh rate rather than a fixed 60fps (which is preferable for some things, but not always others).

From my brief experiment on Windows 11: Golly uses the monitor refresh rate for the event loop. This is both for 3D.lua and if you're running B3/23 in QuickLife.

[Andrew]

From my brief experiment on Windows 11: Golly uses the monitor refresh rate for the event loop. This is both for 3D.lua and if you're running B3/23 in QuickLife.

Actually, Golly uses a 60 hertz timer to generate patterns, so if you run a small pattern like a blinker at a step size of 1 it should do about 600 generations in 10 seconds, regardless of the monitor's refresh rate (see StartGenTimer in wxcontrol.cpp). If you don't see that on Windows 11 then something is going wrong.

Scripts that generate patterns (like 3D.lua) are a different matter. It is up to the script to decide if it wants to update patterns at a particular frame rate. If you look at the EventLoop routine in 3D.lua it calls NextGeneration as fast as it can go (g.sleep is only called when not generating a pattern). If I run the following small oscillator in 3D.lua on my Windows 10 VM it does about 170 gens per second. I'd be interested to see what speed you get on Windows 11.

Code: Select all

3D version=1 size=45 pos=21,21,21
x=3 y=3 z=4 rule=3D4,7/5,8
$bo/bo$bbo$obo/bo$bbo$obo/$bo!

Note however that on a Mac there *is* a restriction on how fast a script can update the viewport. If I run the same pattern in 3D.lua on my Mac I only see about 60 gens per second. I'm pretty sure this is because some low-level wxMac code prevents window updates occurring faster than 60 frames per second (I forget the details but I remember investigating this about 10 years ago).

[rowett]

From my brief experiment on Windows 11: Golly uses the monitor refresh rate for the event loop. This is both for 3D.lua and if you're running B3/23 in QuickLife.

Actually, Golly uses a 60 hertz timer to generate patterns, so if you run a small pattern like a blinker at a step size of 1 it should do about 600 generations in 10 seconds, regardless of the monitor's refresh rate (see StartGenTimer in wxcontrol.cpp). If you don't see that on Windows 11 then something is going wrong.

I don't see that. My experiment was pretty much as you suggested. I ran a simple pattern in 3D.lua and measured 600 steps in 10 seconds (60 per second). I then ran a blinker in B3/S23 QuickLife and measured the same.

I then changed my monitor refresh rate to 30Hz and repeated the experiment. In both cases I got 300 steps in 10 seconds (30 per second).

[Andrew]

I then changed my monitor refresh rate to 30Hz and repeated the experiment. In both cases I got 300 steps in 10 seconds (30 per second).

That's odd. Maybe wxMSW is now doing the same throttling as wxMac (but only on Win 11?). Or maybe it's done automatically by the OS?

Can you bump the refresh rate above 60Hz? I'd be surprised if Golly then generates at that faster rate.

EDIT: Why is muzik seeing faster rates in 3D.lua on his Windows system? Is it because his monitor is doing refreshes at 144Hz?

[rowett]

Can you bump the refresh rate above 60Hz? I'd be surprised if Golly then generates at that faster rate.

EDIT: Why is muzik seeing faster rates in 3D.lua on his Windows system? Is it because his monitor is doing refreshes at 144Hz?

I switched to 75Hz. I see 75 generations a second in 3D.lua (which probably answers the question about muzik and his 144Hz monitor).

However, I see 64 generations per second in QuickLife.

[Andrew]

However, I see 64 generations per second in QuickLife.

Ok, that makes sense. The timer firing rate is only approximately 60 gens per sec. On my Mac I typically see about 62 gens per sec -- this is because we set SIXTY_HERTZ = 16 for Mac/Linux in wxprefs.h (the wxTimer interval has to be an integer) and 1000/16 = 62.5. But for Windows we had to set SIXTY_HERTZ = 15 (see comments why) and 1000/15 = 66.7.

[confocaloid]

[...] If I run the following small oscillator in 3D.lua on my Windows 10 VM it does about 170 gens per second. I'd be interested to see what speed you get on Windows 11.

Code: Select all

3D version=1 size=45 pos=21,21,21
x=3 y=3 z=4 rule=3D4,7/5,8
$bo/bo$bbo$obo/bo$bbo$obo/$bo!

[...]

I ran the same pattern in 3D.lua on Ubuntu 22.04.
With display refresh rate set to 60 Hz, the pattern evolves for about 60 ticks per second.
With display refresh rate set to 48 Hz, the pattern evolves for about 48 ticks per second.
Then I ran the pentadecathlon in QuickLife (same system), with step 1. The results are the same (the number of ticks per second matches the display refresh rate).
In every case, I ran the pattern for about 20 seconds.

[Andrew]

I ran the same pattern in 3D.lua on Ubuntu 22.04.
With display refresh rate set to 60 Hz, the pattern evolves for about 60 ticks per second.
With display refresh rate set to 48 Hz, the pattern evolves for about 48 ticks per second.

Ok, so the only anomaly seems to be when I run 3D.lua on my Windows VM. Not surprising really -- I've seen other cases where the VM doesn't behave the same as a real Windows machine.

[muzik]

EDIT: Why is muzik seeing faster rates in 3D.lua on his Windows system?

To clarify, I'm running Linux in this case; yet to see if Windows does anything different for either 3D.lua or 2D patterns. Monitor refresh rate is indeed set to 144.

[b-engine]

To clarify, I'm running Linux in this case; yet to see if Windows does anything different for either 3D.lua or 2D patterns. Monitor refresh rate is indeed set to 144.

I also met this problem in Windows 11.

[Chameleon]

The "hexahedral" neighbourhood is misnamed. It is actually a rhombic dodecahedral neighbourhood. It would be more accurately called something like "dodecahedral" rather than "hexahedral".

Ironically, it's actually cubes that are hexahedra! So the other neighbourhoods are the real hexahedral ones.

[Andrew]

The "hexahedral" neighbourhood is misnamed. ...

I was just following the nomenclature used by Carter Bays. From the help notes in 3D.lua:

The Hexahedral neighborhood simulates 12 spheres packed around a central sphere (also known as the face-centred cubic lattice, or the rhombic dodecahedral honeycomb). Because it is simulating a hexahedral tessellation in a cubic grid, this neighborhood is not orthogonally symmetric, so flipping or rotating a pattern can change the way it evolves.

[Chameleon]

I was just following the nomenclature used by Carter Bays.

Carter Bays made a mistake in using such ridiculous terminology. Another mistake he made was calling the cuboctahedron, which is the dual of the rhombic dodecahedron, a hexadecahedron, when in fact it has 14 faces not 16, making it a tetradecahedron, and indeed he even acknowledged this, calling it by the oxymoron "14-sided hexadecahedron"!

It's possible that he meant to say "hexadecahedral" rather than "hexahedral", but even that would have been inaccurate.

In any case, I find it more intuitive to think of it in terms of the rhombic dodecahedron rather than the cuboctahedron. At the same time, the cuboctahedron has a shorter name, so maybe "cuboctahedral" could be a good name for the type of symmetry.

P.S. Come to think of it, it should be the "rhombic dodecahedral" neighbourhood.

[muzik]

Are the "edges-only" and "hexahedral" neighbourhood identical, in the sense that they both emulate the rhombic dodecahedral honeycomb, and the former just does it in a way that results in the grid being partitioned into two disconnected checkerboards?

[Andrew]

Are the "edges-only" and "hexahedral" neighbourhood identical ... ?

Presumably not, given that the same pattern generates differently in the two neighborhoods. Try loading Three-Dimensional/p126-christmas-tree.rle3 and use Control > Set Rule to change the H in the rule to E. The pattern dies out instead of being periodic.

[muzik]

Are the "edges-only" and "hexahedral" neighbourhood identical ... ?

Presumably not, given that the same pattern generates differently in the two neighborhoods.

Well, that's true. But there does seem to be a correspondence that allows for any pattern operating on a H rule to be turned into a functionally equivalent pattern in an E rule.

For example, here's an oscillator predecessor (triangle with side length 27):

Code: Select all

3D version=1 size=50 pos=12,12,25
x=27 y=27 z=1 rule=3D3/3H
26bo$25boo$24b3o$23b4o$22b5o$21b6o$20b7o$19b8o$18b9o$17b10o$16b11o$
15b12o$14b13o$13b14o$12b15o$11b16o$10b17o$9b18o$8b19o$7b20o$6b21o$5b
22o$4b23o$3b24o$bb25o$b26o$27o!

This indeed does something different in E, but here's a different way of representing the same triangle that does end up doing the same thing as the first pattern does in H:

Code: Select all

3D version=1 size=50 pos=12,11,11
x=27 y=27 z=27 rule=3D3/3E
o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$
16bo$17bo$18bo$19bo$20bo$21bo$22bo$23bo$24bo$25bo$26bo/$o$bo$bbo$3b
o$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$17bo$18b
o$19bo$20bo$21bo$22bo$23bo$24bo$25bo/$$o$bo$bbo$3bo$4bo$5bo$6bo$7bo
$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$17bo$18bo$19bo$20bo$21b
o$22bo$23bo$24bo/3$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12b
o$13bo$14bo$15bo$16bo$17bo$18bo$19bo$20bo$21bo$22bo$23bo/4$o$bo$bbo
$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$17b
o$18bo$19bo$20bo$21bo$22bo/5$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10b
o$11bo$12bo$13bo$14bo$15bo$16bo$17bo$18bo$19bo$20bo$21bo/6$o$bo$bbo
$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$17b
o$18bo$19bo$20bo/7$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12b
o$13bo$14bo$15bo$16bo$17bo$18bo$19bo/8$o$bo$bbo$3bo$4bo$5bo$6bo$7bo
$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$17bo$18bo/9$o$bo$bbo$3b
o$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$17bo/10$
o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$
16bo/11$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14b
o$15bo/12$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$
14bo/13$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo/14$
o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo/15$o$bo$bbo$3bo
$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo/16$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$
8bo$9bo$10bo/17$o$bo$bbo$3bo$4bo$5bo$6bo$7bo$8bo$9bo/18$o$bo$bbo$3b
o$4bo$5bo$6bo$7bo$8bo/19$o$bo$bbo$3bo$4bo$5bo$6bo$7bo/20$o$bo$bbo$3b
o$4bo$5bo$6bo/21$o$bo$bbo$3bo$4bo$5bo/22$o$bo$bbo$3bo$4bo/23$o$bo$bb
o$3bo/24$o$bo$bbo/25$o$bo/26$o!

2D rules have similar relationships between certain neighbourhoods - for example, the Tri6outer neighbourhood is functionally equivalent to two hexagonal neighbourhoods (which can, perhaps by definition, never interact):

Code: Select all

x = 7, y = 4, rule = B2/S34H
o5bo2$3bobo$3b4o!
[[ ZOOM 32 AUTOSTART GPS 32 ]]

Code: Select all

x = 14, y = 4, rule = B2/S34LO
bo11bo2$5bo3bo$4bobobobo!
[[ ZOOM 17 AUTOSTART GPS 32 ]]

Of course, you can't just run one pattern in the other rule since the cells are arranged differently:

Code: Select all

x = 7, y = 4, rule = B2/S34LO
o5bo2$3bobo$3b4o!
[[ ZOOM 17 ]]

Code: Select all

x = 14, y = 4, rule = B2/S34H
bo11bo2$5bo3bo$4bobobobo!
[[ ZOOM 32 ]]

My assumption is that the same thing is going on in 3D - the "edges" neighbourhood is functionally the same thing as two non-interacting "hexahedral" neighbourhoods, and there's a way to turn any "hexahedral" pattern into an equivalent "edges" pattern (and conversely, if we choose one of the two possible checkerboard-separated universes, any "edges" pattern into an equivalent "hexahedral" pattern).

[Andrew]

My assumption is that the same thing is going on in 3D - the "edges" neighbourhood is functionally the same thing as two non-interacting "hexahedral" neighbourhoods, and there's a way to turn any "hexahedral" pattern into an equivalent "edges" pattern (and conversely, if we choose one of the two possible checkerboard-separated universes, any "edges" pattern into an equivalent "hexahedral" pattern).

Yep, I see what you mean. It would be a nice little exercise for someone to write a Lua script to convert a H pattern to a corresponding E pattern.

[gzaytman]

Are the "edges-only" and "hexahedral" neighbourhood identical, in the sense that they both emulate the rhombic dodecahedral honeycomb, and the former just does it in a way that results in the grid being partitioned into two disconnected checkerboards?

Yes.

[gzaytman]

New neighbourhood suggestion: currently hexagonal rules are simulated using a square grid neighbourhood which resembles the intersection of two 2x2 squares. How about adding a new neighbourhood which comes about as the intersection of two 2x2x2 blocks (with the one intersecting cell being the center)? It probably wouldn't be as good an analogue as the hexahedral neighbourhoood but would be interesting to see.

This neighbourhood is equivalent to the truncated octahedral tiling of space.

[muzik]

This neighbourhood is equivalent to the truncated octahedral tiling of space.

This is also what the 8-cell "vertices only" neighbourhood corresponds to, is it not (assuming we only consider cells adjacent to hexagonal faces, and there are eight non-interacting universes)?

Is there a neighbourhood that implements it more efficiently (i.e. less non-interacting universes, such that we use more of the grid's available cells to represent the same pattern in a smaller way, much like how "hexahedral" is twice as efficient as "edges only" for representing the rhombic dodecahedral honeycomb)?

[gzaytman]

This neighbourhood is equivalent to the truncated octahedral tiling of space.

This is also what the 8-cell "vertices only" neighbourhood corresponds to, is it not (assuming we only consider cells adjacent to hexagonal faces, and there are eight non-interacting universes)?

Correct. However, the neighborhood you described in the comment above is the 14-cell neighborhood corresponding to both hexagonal and square faces.

Is there a neighbourhood that implements it more efficiently (i.e. less non-interacting universes, such that we use more of the grid's available cells to represent the same pattern in a smaller way, much like how "hexahedral" is twice as efficient as "edges only" for representing the rhombic dodecahedral honeycomb)?

Yes. The 8-cell "vertices only" neighborhood compresses to the 6-cell von Neumann neighborhood plus the points ±(1,1,1).

[muzik]

This neighbourhood is equivalent to the truncated octahedral tiling of space.

This is also what the 8-cell "vertices only" neighbourhood corresponds to, is it not (assuming we only consider cells adjacent to hexagonal faces, and there are eight non-interacting universes)?

Correct.

Certainly I'd be interested to see how this generalizes in higher dimensions.

In 2D, the four edge-adjacent cells comprise the square tiling (effectively by definition), whereas considering only the four vertex-adjacent cells creates a different square tiling (scaled by sqrt(2) and rotated 45 degrees).

In 3D, the six face-adjacent cells also gets us the same cubic honeycomb again, the twelve edge-adjacent cells gives the rhombic dodecahedral honeycomb, and the eight vertex-adjacent cells gives the bitruncsted cubic honeycomb.

In 4D, the eight cell-adjacent cells once again just return the same tesseract honeycomb. I assume the 24 face-adjacent cells result in the 24-cell tiling? What do the 32 edge-adjacent cells and 16 vertex-adjacent cells result in?

In 5D, we can select from the 10 hypercell-adjacent cells (which just gets us the same penteractic honeycomb), 40 cell-adjacent cells, 80 face-adjacent cells, 80 edge-adjacent cells and 32 vertex-adjacent cells, but I don't know how one would even start to address these.