Might have to change direction again on the ice crystal generator. A few problems:
- My output doesn’t look good. Very little in the way of dendrites, instead I’m getting nearly uniform front.
- The code listing in the paper had errors which I believe I corrected but it doesn’t make me confident relying so heavily on it as a reference (since I don’t understand the maths well enough to implement it directly).
- It runs way too slowly for the idea I have in mind.
Also, now that I look at the outputs from the paper again, I’m not sure it’s exactly what I’m going for. It’d probably need a lot of tweaking which, again, I don’t understand the maths well enough. Deadline looms.
I came across another paper by Arthur Reiter which is less flexible but has very promising outputs. It’s simpler and should run faster and I’ve found someone’s implementation on Github.
Here’s the paper: https://patarnott.com/pdf/SnowCrystalGrowth.pdf
Here’s the repo by Marko Hostnik: https://github.com/mare5x/reiter-snowflakes
…
Okay, it took longer than I’d like to admit for me to get the hex grid to draw.
Now for the actual crystalization.
…
It works!
Getting the algorithm to work was actually easier than drawing a grid of hexagons to an image. Go figure. Hexagons really do add a ton of complexity but I’m happy with the output already.
Unfortunately still quite slow but I haven’t done any optimization whatsoever so we’ll see if there’s yet hope.
…
So here is what I’m looking at for calls and times (self).
This is on a 60x60 grid so 3,600 hexagons to visit. Definitely some low-hanging fruit to improve performance here.
| func | ms | calls | total |
|---|---|---|---|
| has_frozen_neighbor | 689 | 7884 | 5432076 |
| get_oddq_direction | 562 | 5305 | 2981410 |
| is_on_edge | 458 | 5507 | 2522206 |
| get_s | 282 | 6208 | 1750656 |
| is_receptive | 110 | 8073 | 888030 |
| get_u_part | 66 | 7064 | 466224 |
| sum_neighbors_u | 72 | 1009 | 72648 |
| set_s | 5 | 1009 | 5045 |
is_receptive()is being called multiple times per hex.has_frozen_neighbor()is being called multiple times per hex.get_oddq_direction()is rebuilding an Array and six Vector2is on every call so it’s mad slow.
But first, let’s measure where we’re at. Right now it takes 2.5-2.6 seconds to perform 30 steps. That’s the average taken from generating the first 120 steps.