diff --git a/site/cellthing.html b/site/cellthing.html index a0d08a2..ec62872 100644 --- a/site/cellthing.html +++ b/site/cellthing.html @@ -79,7 +79,7 @@ So now the engine picks a random position, then checks the cache and picks a ran I want to simulate a swarm of bees, so I create a rule for a bee moving by one cell, and enable rotate so it works in all directions. That was easy,

-
+

Oh no, the swarm is moving toward the top left instead of spreading equally. But I can see that the bees move in all four directions, so the rule seems to be rotated correctly.
@@ -95,22 +95,42 @@ In the diagram below, the bee would move left when the left (purple) cell is pic
But to move right or down, it needs the bees own position to be picked by the engine, since the rules always extend right-down. That means when the engine picks the bee's position, there are two possible rules to execute. Therefore, moving right and down both have half the probability overall compared to moving up or left.

+

the overlap checker

-TODO explain overlap checker
+In this version, the cache is not only searched for matches at the chosen position, but also overlapping. Given that, it only needs to pick positions within the world.
+

+

+Since the root issue was caused by asymmetry, I thought this implementation should be correct. This one was actually my first instinct when I created the cache, but as a friend suggested, an absolute-position based checker seemed (and indeed was) more performant and simpler, so I did that one first.
+

+

+
+

+

+Now the bees are evenly distributed, just like real bees!(false)

just one more implementation

-I wasn't happy with the performance difference
-while I was trying to figure out the reason for the directional bias in the previous implementation, I realised that the overlap checker also has biases. the probability of any given cached match to be executed is dependent on its area, which is not very intuitive. two objects of different mass fall at different speeds
+While I was trying to figure out the reason for the directional bias in the previous implementation, I realised that the overlap checker also has biases. The probability of any given cached match to be executed is dependent on its area, which is not very intuitive. Two objects of different mass fall at different speeds, and adding empty padding to a rule makes it run faster.

-TODO video different sized blocks falling
+

-TODO explain rule origin shifting
+Ideally the red, pink and blue cells should all fall at around the same rate, but the red sand always lands first and the pink last.

-go back to my other garbag
+Alright, the Final (I hope) implementation stores an origin offset for rules. This is zero for normal rules, but is automatically modified by rotation and mirroring, so that the origin always falls on the same actual rule cell. The picked position now needs to extend on all four edges, since rules may happen to have their origin point on a blank input cell, making it possible to trigger partially outside the world bounds. The amount to extend by is determined by the maximum width and height of all the rule variants, minus one since at least one cell has to be inside the bounds for the rule to have any effect.
+

+

fin

+

+If you somehow read through all that, congratulations I think? Now enjoy this fire:
+
+

+

+Download the thing and make something fun: git.crispypin.cc/CrispyPin/snad
+

+

+Or go back to my other garbage
diff --git a/site/snad/bees.mp4 b/site/snad/bees.mp4 index 8cf4af8..f0e45af 100644 Binary files a/site/snad/bees.mp4 and b/site/snad/bees.mp4 differ diff --git a/site/snad/bees_biased.mp4 b/site/snad/bees_biased.mp4 new file mode 100644 index 0000000..8cf4af8 Binary files /dev/null and b/site/snad/bees_biased.mp4 differ diff --git a/site/snad/fire.mp4 b/site/snad/fire.mp4 new file mode 100644 index 0000000..1838041 Binary files /dev/null and b/site/snad/fire.mp4 differ diff --git a/site/snad/rule_size_bias.mp4 b/site/snad/rule_size_bias.mp4 new file mode 100644 index 0000000..9f56a15 Binary files /dev/null and b/site/snad/rule_size_bias.mp4 differ diff --git a/write/cellthing.md b/write/cellthing.md index abb5dcc..af78bb6 100644 --- a/write/cellthing.md +++ b/write/cellthing.md @@ -49,7 +49,7 @@ So now the engine picks a random position, then checks the cache and picks a ran ## swarm I want to simulate a swarm of bees, so I create a rule for a bee moving by one cell, and enable `rotate` so it works in all directions. That was easy, - + Oh no, the swarm is moving toward the top left instead of spreading equally. But I can see that the bees move in all four directions, so the rule seems to be rotated correctly. @@ -63,15 +63,28 @@ In the diagram below, the bee would move left when the left (purple) cell is pic But to move right or down, it needs the bees own position to be picked by the engine, since the rules always extend right-down. That means when the engine picks the bee's position, there are *two* possible rules to execute. Therefore, moving right and down both have half the probability overall compared to moving up or left. -TODO explain overlap checker +### the overlap checker +In this version, the cache is not only searched for matches *at* the chosen position, but also *overlapping*. Given that, it only needs to pick positions within the world. + +Since the root issue was caused by asymmetry, I thought this implementation should be correct. This one was actually my first instinct when I created the cache, but as a [friend](https://gaussian.dev/) suggested, an absolute-position based checker seemed (and indeed was) more performant and simpler, so I did that one first. + + + +Now the bees are evenly distributed, just like real bees!(false) ## just one more implementation -I wasn't happy with the performance difference -while I was trying to figure out the reason for the directional bias in the previous implementation, I realised that the overlap checker also has biases. the probability of any given cached match to be executed is dependent on its area, which is not very intuitive. two objects of different mass fall at different speeds +While I was trying to figure out the reason for the directional bias in the previous implementation, I realised that the overlap checker also has biases. The probability of any given cached match to be executed is dependent on its area, which is not very intuitive. Two objects of different mass fall at different speeds, and adding empty padding to a rule makes it run faster. -TODO video different sized blocks falling + -TODO explain rule origin shifting +Ideally the red, pink and blue cells should all fall at around the same rate, but the red sand always lands first and the pink last. +Alright, the Final (I *hope*) implementation stores an origin offset for rules. This is zero for normal rules, but is automatically modified by rotation and mirroring, so that the origin always falls on the same actual rule cell. The picked position now needs to extend on all four edges, since rules may happen to have their origin point on a blank input cell, making it possible to trigger partially outside the world bounds. The amount to extend by is determined by the maximum width and height of all the rule variants, minus one since at least one cell has to be inside the bounds for the rule to have any effect. -go back to my [other garbag](/) +## fin +If you somehow read through all that, congratulations I think? Now enjoy this fire: + + +Download the thing and make something fun: [git.crispypin.cc/CrispyPin/snad](https://git.crispypin.cc/CrispyPin/snad) + +Or go back to my [other garbage](/)