Pattern viewer for forum threads

[muzik]

How does POLYFILL decide how to colour intersecting polygons?

Separate, intersecting polygons have the intersecting regions filled with double intensity:

Code: Select all

x = 1, y = 1, rule = B/S0123HT
!
[[ X 2.83 Y 2 GRID COLOR POLY Green POLYALPHA 0.5 POLYFILL 0 0 6 6 6 0 0 0 32 POLYFILL 2 -2 8 4 2 4 2 -2 32 ]]

Polygons that intersect themselves appear to have even-density regions not filled in:

Code: Select all

x = 1, y = 1, rule = B/S0123HT
!
[[ X 2.83 Y 2 GRID COLOR POLY Orange POLYALPHA 0.5 POLYFILL 2 -2 8 4 0 0 6 6 6 0 2 4 2 -2 32 ]]

...though not always, since this fills in the density 1, 2 and 3 regions, rather than only 1 and 3:

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ ZOOM 64 GRID COLOR POLY Pink POLYALPHA 0.5 POLYFILL -1 0 0.7071067812 -0.7071067812 0 1 -0.7071067812 -0.7071067812 1 0 -0.7071067812 0.7071067812 0 -1 0.7071067812 0.7071067812 -1 0 64 ]]

Should I report these posts (either using the functionality or some dedicated thread) so they can be edited to no longer use an invalid format?

No need - I've corrected them.

I'm not sure about other users but there appear to be a few more examples of this incorrect formatting:

viewtopic.php?f=11&t=3293&p=166056#p166056
viewtopic.php?f=11&t=1971&p=164760#p164760
viewtopic.php?f=12&t=6063&p=164376#p164376

[rowett]

How does POLYFILL decide how to colour intersecting polygons?

Each polygon is drawn separately so if you overlap different polygons with alpha they will blend in the intersection.

For single polygons the non-zero winding rule is used.

I'm not sure about other users but there appear to be a few more examples of this incorrect formatting:

Fixed.

[muzik]

In build 1381 zooming in beyond the threshold where non-rectangular polygons are displayed will cause an unpleasant and distracting flash, which was not the case previously.

There appear to be some residual issues with the build 1381 hexagonal grid rendering fixes where history cells will disappear when they should not be doing so:

Code: Select all

# use Draw to remove the highlighted cell
x = 37, y = 37, rule = B2/S2H
obobo2$3bo$3b2o$4bo28$o2b2o27b2o2bo$3b2o28b2o$2bo33bo2$4bo31bo!
[[ THEME Red STARTFROM 64 PASTET 64 PASTE o! 24 12 ARROW 18 12 22 12 16 ARROW 24 6 24 10 16 ARROW 30 18 26 14 16 ]]

Code: Select all

# play and pause and note the trail on the left
x = 1, y = 1, rule = MAPAAD//wAA//8AAP//AAD//w
!
[[ RANDOMIZE RANDWIDTH 8 RANDHEIGHT 8 AUTOSTART AUTOFIT STOP 64 ]]

Code: Select all

# this disappears if you zoom in enough that hexagons are used instead of rectangles
# try enabling Use Rectangles and seeing how they become visible then as well
x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART ZOOM 4 THEME Red PASTET EVERY 1 PASTEMODE XOR PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 ]]

Zoom levels further out than 4.0, seemingly to around 2.3, on triangular grids will still use rectangular cells instead of continuing to render triangles, which results in two different grid shapes being used at different zoom levels, unlike what is the case for the hexagonal grid:

Code: Select all

x = 8, y = 5, rule = B4/S456L
$2b5o$b2o3b2o$b2o3b2o$2b5o!
[[ GRID ZOOM 2.3095 ]]

I can't reproduce this on desktop but can on a tablet - step to generation 1, use Fit Pattern, then step to generation 2 and use it again, and all the living cells will disappear:

Code: Select all

x = 121, y = 1, rule = B1z/SL
o119bo!

On default desktop resolution (this may vary) the themes help section appears to cut off the Generations shortcut. Can something be done to ensure it displays in full?

generatiodotdotdot.png (167.85 KiB) Viewed 2664 times

Hexagonal custom rules will show information about defined icons in Help > Info > Pattern but won't show the icons themselves unlike for square grid rules. Is this intended? Should icons be shown here like they are for square grids even if not used in practice? Or should these lines be removed altogether? Compare:

Code: Select all

x = 1, y = 1, rule = Fredkin_mod3_hexagonal
o!

Code: Select all

x = 1, y = 1, rule = Fredkin_mod3_triangularVonNeumann_emulated
o!

[muzik]

Build 1382's fixes appear to have fixed some other bugs elsewhere and resulted in other behavioural changes.

In this example, after the last living cells die, the triangular and square grids will zoom out and be fully centered on the grid (previously they would remain in place). The hexagonal grid, on the other hand, will abruptly bounce inward, and then zoom out in a non-centered position, rather than zooming out in a simple way with a centered outcome like the other two.

Code: Select all

# triangular
x = 1, y = 1, rule = B/S0123LE
!
[[ MAXGRIDSIZE 9 PASTET EVERY 1 PASTEDELTA 0 1 PASTE 512o! -256 -256 STARTFROM 384 AUTOSTART AUTOFIT THEME Book ]]

Code: Select all

# square
x = 1, y = 1, rule = B/S01234V
!
[[ MAXGRIDSIZE 9 PASTET EVERY 1 PASTEDELTA 0 1 PASTE 512o! -256 -256 STARTFROM 384 AUTOSTART AUTOFIT THEME Book ]]

Code: Select all

# hexagonal
x = 1, y = 1, rule = B/S0123HT
!
[[ MAXGRIDSIZE 9 PASTET EVERY 1 PASTEDELTA 0 1 PASTE 512o! -256 -256 STARTFROM 384 AUTOSTART AUTOFIT THEME Book ]]

This test case was originally used for demonstrating a history cell fading issue which build 1382 appears to have fixed. There is still one residual issue, however: the history cell at T=0 is absent in the range-1 algorithm, but present in the general-range algorithm.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ COLOR POLY Red POLYLINE -1 -1 1 -1 1 1 -1 1 -1 -1 24 PASTEMODE XOR PASTET EVERY 1 PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ COLOR POLY Red POLYLINE -1 -1 1 -1 1 1 -1 1 -1 -1 24 PASTEMODE XOR PASTET EVERY 1 PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 ]]

Since we're on the topic of rendering hexagons and triangles I may as well reiterate this specific issue: if BOUNDARY is the same colour as BACKGROUND, the out-of-bounds cells will not render on a square grids, but will on hexagonal and triangular grids (unless you zoom out or force rectangle usage), impacting performance and ruining the infinite starfield illusion:

Code: Select all

x = 1, y = 1, rule = B/S01234V
!
[[ MAXGRIDSIZE 9 STARS COLOR BOUNDARY Black ZOOM 8 X 256 Y 256 COLOR POLY Blue POLYLINE 255.5 255.5 -256.5 255.5 -256.5 -256.5 255.5 -256.5 255.5 255.5 8 ]]

Code: Select all

x = 1, y = 1, rule = B/S0123HT
!
[[ MAXGRIDSIZE 9 STARS COLOR BOUNDARY Black ZOOM 8 X 128 Y 256 COLOR POLY Blue POLYLINE 255.5 255.5 -256.5 255.5 -256.5 -256.5 255.5 -256.5 255.5 255.5 8 ]]

Code: Select all

x = 1, y = 1, rule = B/S0123LE
!
[[ MAXGRIDSIZE 9 STARS COLOR BOUNDARY Black ZOOM 8 X 256 Y 256 COLOR POLY Blue POLYLINE 255.5 255.5 -256.5 255.5 -256.5 -256.5 255.5 -256.5 255.5 255.5 8 ]]

Can period/frequency maps of triangular grid oscillators, if the oscillator is sufficiently small, be made out of actual triangles, rather than stretched rectangles? Rectangles make more sense for large objects, but for small objects it makes the symmetry of objects (as well as the continuity of gutteroids) hard to see:

Code: Select all

x = 9, y = 4, rule = B45/S23L
2b3ob2o$bo6bo$7bo$3bobo!
[[ AUTOIDENTIFY ]]

Unrelated to rendering or hexagonal/triangular stuff, but I noticed that this pattern runs as B3/S12 in Golly, but as B3/S23 in LifeViewer:

Code: Select all

x = 11, y = 11, rule = R1,C2,M0,S1..2,B3..3,NW111101111
8bo$7b3o$6b5o$9bo$5bo2bo$4bo2bo$2bo$b2o2bo$3obo$b3o$2bo!

Changing the central 0 to a 1 results in a pattern that runs as B3/S01 in Golly, but B3/S12 in LifeViewer:

Code: Select all

x = 11, y = 11, rule = R1,C2,M0,S1..2,B3..3,NW111111111
8bo$7b3o$6b5o$9bo$5bo2bo$4bo2bo$2bo$b2o2bo$3obo$b3o$2bo!

Here are other posts I found that use an incorrect RLE format that cannot be read:
viewtopic.php?f=3&t=1622&start=3575#p191331
viewtopic.php?f=3&t=1622&p=191000#p191000
viewtopic.php?f=12&t=2771&p=191001#p191001
viewtopic.php?f=12&t=4484&p=190943#p190943
viewtopic.php?f=12&t=4137&p=191247#p191247
viewtopic.php?f=12&t=4484&p=191127#p191127
viewtopic.php?f=12&t=4484&p=191547#p191547

Major grid lines appear to jump around all over the place as the camera moves if higher quality rendering is enabled:

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ AUTOSTART QUALITY GRID TRACK -1/4 1/4 GPS 20 ZOOM 16 THEME Golly ]]

Thanks a lot for the recent hexagonal/triangular fixes, by the way - this eliminates a lot of the annoyances I've been experiencing as of recently when handling such patterns.

[rowett]

Hexagonal custom rules will show information about defined icons in Help > Info > Pattern but won't show the icons themselves unlike for square grid rules. Is this intended?

Yes, the information about the defined icons comes from the parser. It's interesting to see that they were found and were valid. The icons themselves are only displayed for rules that actually support displaying icons.

In this example, after the last living cells die, the triangular and square grids will zoom out and be fully centered on the grid (previously they would remain in place). The hexagonal grid, on the other hand, will abruptly bounce inward, and then zoom out in a non-centered position, rather than zooming out in a simple way with a centered outcome like the other two.

Fixed in build 1383.

Since we're on the topic of rendering hexagons and triangles I may as well reiterate this specific issue: if BOUNDARY is the same colour as BACKGROUND, the out-of-bounds cells will not render on a square grids, but will on hexagonal and triangular grids (unless you zoom out or force rectangle usage)

I suggest you make BOUNDARY slightly different than BACKGROUND (like 0 0 1 vs 0 0 0).

Can period/frequency maps of triangular grid oscillators, if the oscillator is sufficiently small, be made out of actual triangles, rather than stretched rectangles?

No. It's a lot of work for not much gain.

Unrelated to rendering or hexagonal/triangular stuff, but I noticed that this pattern runs as B3/S12 in Golly, but as B3/S23 in LifeViewer:

Yes, there's a known issue with M0 and M1 between LifeViewer and Golly. I'll fix it at some stage.

Major grid lines appear to jump around all over the place as the camera moves if higher quality rendering is enabled:

Also known. Disable grid lines for now.

[muzik]

These two bugs were fixed in build 1382, but appear to have returned in build 1383:

Code: Select all

# this disappears if you zoom in enough that hexagons are used instead of rectangles
# try enabling Use Rectangles and seeing how they become visible then as well
x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART ZOOM 4 THEME Red PASTET EVERY 1 PASTEMODE XOR PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 ]]

...most of the history cells in the general-range example never age.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ PASTEMODE XOR PASTET EVERY 1 PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ PASTEMODE XOR PASTET EVERY 1 PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 ]]

Now that one of the autofit issues has been resolved, could some of the other longstanding issues be looked at?

Code: Select all

# pausing this will result in it zooming out to fit all the history cells despite there being no HISTORYFIT
x = 3, y = 4, rule = /2/3
.AB$AB$AB$.AB!
[[ AUTOFIT AUTOSTART ]]

Code: Select all

# pausing this will result in all of the historical cells being ignored
x = 2, y = 4, rule = B2/S
bo$o$o$bo!
[[ AUTOFIT HISTORYFIT AUTOSTART ]]

Code: Select all

# history gets ignored if a cell is deleted by pasting
x = 60, y = 3, rule = B3/S23
obo54bobo$b2o54b2o$bo56bo!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 200 PASTE o! 37 27 ]]

Code: Select all

# history gets ignored if a glider is killed
x = 10, y = 75, rule = B3/S23
obo$3bo$3bo5bo$o2bo3bobo$b3o4b2o67$4b2o$4bo$5b3o$7bo!
[[ AUTOSTART AUTOFIT HISTORYFIT KILLGLIDERS ]]

Code: Select all

# when STOP is reached the camera is instantly set in position rather than smoothly easing
x = 1, y = 1, rule = MAPAP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/w
o!
[[ AUTOSTART STOP 80 AUTOFIT ]]

Since we're on the topic of rendering hexagons and triangles I may as well reiterate this specific issue: if BOUNDARY is the same colour as BACKGROUND, the out-of-bounds cells will not render on a square grids, but will on hexagonal and triangular grids (unless you zoom out or force rectangle usage)

I suggest you make BOUNDARY slightly different than BACKGROUND (like 0 0 1 vs 0 0 0).

This would work for making the boundary visible on the square grid but what I'm looking for is the opposite: the boundary should be invisible on the hexagonal and triangular grid if the colours match, as is the case on the square grid.

On the topic of boundaries: if the bounded grid colour matches the background colours but multiple layers are active, the bounded grid cells will be darkened but the background will not, despite neither being duplicated across layers.

Code: Select all

x = 2, y = 4, rule = B2/S:T10,10+1
bo$o$o$bo!
[[ THEME Inverse COLOR BOUNDED White LAYERS 2 ]]

Also, why is the background not white in this example? The script commands specifically specify so.

Code: Select all

x = 2, y = 4, rule = B2/S:T10,10+1
bo$o$o$bo!
[[ COLOR BACKGROUND White COLOR BOUNDED White LAYERS 2 ]]

The top right boundary cell of this period/frequency map isn't adjacent to any internal cells and therefore can probably be removed. On the other side of things, it may be worth adding some more boundary cells elsewhere on the left and right boundaries of this map so that cells inside aren't diagonally adjacent to the exterior (similarly to what was done for triangular bounded grids a year or so ago).

Code: Select all

x = 33, y = 33, rule = B135/S0246HInvestigator:P39
E15.E16$E15.A15.E16$16.E15.E!
[[ AUTOIDENTIFY ]]

Here's a comparison of how it currently looks versus how I think it should look:
Current:

cellmap-hexbig-current.png (581 Bytes) Viewed 2563 times

With fixes (no extra cell, diagonal gaps filled):

cellmap-hexbig-fixed.png (662 Bytes) Viewed 2563 times

[muzik]

Is it possible to customize the colours of age states other than just using a single gradient?

It's possible in the engine but there's no way to specify the custom colours at the moment. The engine doesn't know anything about gradients - it's just given a palette of colours to use.

It will need a naming convention for the alive states that isn't the state numbers. Thoughts?

"dying 1", "dying 2", "dying 3", ... "dying n" are already the names we use for cell states from DYING to DYINGRAMP, correct? In that case, it only seems logical to me to extend that system to "alive 1", "alive 2", ... "alive 64" and "dead 1", "dead 2", ... "dead 64" for historical alive and dead cells.

Double-checking: is this naming system good enough, or should something different entirely be used?

If we do go with this, the following setup should recreate the animation from earlier:

Code: Select all

x = 20, y = 16, rule = B2/S34H
bo$o$2bo4$13bo3$13b2o$14bo$15b2o$9bo6bo2bo2$10bo$9bo!
[[ GPS 20/3 COLOR BACKGROUND 255 255 255 COLOR "alive 1" 147 254 0 COLOR "alive 2" 254 0 210 COLOR "alive 3" 108 0 254 COLOR "alive 4" 13 0 254 COLOR "alive 5" 0 45 254 COLOR "alive 6" 0 83 254 COLOR "alive 7" 1 110 254 COLOR "alive 8" 0 131 254 COLOR DEAD 255 255 255 HISTORYSTATES 0 ]]

[muzik]

If you use the "safe" rendering speed, pattern playback while the settings or help menu or graph is open will cause the background to go much darker than before, and there may also be noticeable flickering at each iteration. Also, every fifth generation or so will appear to do nothing.

Code: Select all

x = 1, y = 1, rule = Langtons-Ant
B!
#C [[ GRID ICONS GPS 2 ZOOM 32 AUTOSTART ]]

[Citation needed]

Is it possible to find out the maximum population of a Methuselah using LifeViewer?

[b-engine]

Is it possible to find out the maximum population of a Methuselah using LifeViewer?

Yes, manually.

For example, you can use graphs to find out the max population, which is 319 for R:

Code: Select all

bo$3o$o!
[[ STARTFROM 1103 GRAPH ]]

[unname4798]

Code: Select all

#R R1,C2,S,B1,NW000010000,10
o10bo11$o10bo!

B0 glitch in LifeViewer still here.
It says "Life ended after generation" even when life appeared back again:

Code: Select all

#R R1,C2,S,B1,NW000010000,10,P0,1,0
o!

[muzik]

Not sure if this is causing any issues elsewhere but there appears to be a misspelling in this code file:

suvivalchances.png (208.68 KiB) Viewed 644 times

[rowett]

Not sure if this is causing any issues elsewhere but there appears to be a misspelling in this code file:

No issue. That's just a label that Help>Memory uses. Well spotted though!