alternative grid generators
Description
Alternative grid generators using Voronoi's power. Just a PoC addressing #829. IDK it is useful or not.
Choose the grid algo from options.
- [ ] Bug fix
- [x] New feature
- [ ] Refactoring / style
- [ ] Documentation update / chore
- [ ] Other (please describe)
Deploy Preview for afmg ready!
| Name | Link |
|---|---|
| Latest commit | f4b3662cba0b70e5bf4a0978bb7eed25882b4e38 |
| Latest deploy log | https://app.netlify.com/sites/afmg/deploys/62b0a2e3ea2b210008b1af5c |
| Deploy Preview | https://deploy-preview-832--afmg.netlify.app/ |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Yes, it will be pretty helpful to have for some categories of users. That's actually pretty great. We had something like that before, but it was removed for some reason, probably just an experiment as well.
We can use it in production with some cleanup, I also see some weird bug that map is not getting scrolled on drag. As for grid variants, we can also add flat hex as people always request it:
- jittered square grid (current, I believe 'voronoi' is not correct, as finally all are voronoi, we can use 'jittered' or ''default' on UI)
- square grid
- hex pointy
- hex flat
map is not getting scrolled on drag
Just wanted to report that drag is working fine for me (Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0) - and mention that this feature is great!
Ok, let's add some cleanup then. I think removing (or making optional) coastline interpolation and sea-cell optimization would be also useful for some use cases (eg hex-grids).
We can use it in production with some cleanup, I also see some weird bug that map is not getting scrolled on drag. As for grid variants, we can also add flat hex as people always request it:
I believe 'voronoi' is not correct, as finally all are voronoi
It might be technically incorrect, but pretty much correct from the user's perspective. One is generic voronoi the other is a hexgrid happen to be generated using the same algo. To be honest, if we remove the cell optimizations for hexgrids, it will become technically correct because all (center) cells will be actually hexes the concrete generation method doesn't matter. The data structure is not bound to voronoi cells we could store penrose tiling or even star-tiling :).
However I agree on that the user might not know what "voronoi" is (same for "jittered grid"). How about "random" or "irregular"?
* hex flat
Okay. Probably it would be a nice touch to make the "grid" layer to match cell size by default if "hex" is selected.
Bonus: you can resample your existing maps to hexgrids! :-D
How about "random" or "irregular"?
I prefer just 'default'.
Updates:
- [x] Flat hex grid
- [x] load / save support (new data field for option)
- [x] submap support (you can remap your maps using different grid type)
First I was trying to simply swap rows and cols for flat hexes, but it seems some of the algos (eg. wind generation and icebergs) are not generic and depend on a row based layout, which is unfortunate and caused weird bugs. I rewrote the flathex algo to be row-based. Reverse id mapping for grids is also implementation specific and had to be changed. Current solution is a bit hacky but works.
Is it work in progress or somehow final result? I see it can be refactored quite a lot
Somewhat final. :) what would you like to be refractored?
Actually the whole generator could be refactored and all new features are patches. I follow the least modification principle.
But if you tell me what you don't like it can be done
Azgaar @.***> ezt írta (időpont: 2022. jún. 19., Vas 15:04):
Is it work in progress or somehow final result? I see it can be refactored quite a lot
— Reply to this email directly, view it on GitHub https://github.com/Azgaar/Fantasy-Map-Generator/pull/832#issuecomment-1159721154, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUMDVMOYK7ILOXE5QOCR4LVP4LFXANCNFSM5YESQU7Q . You are receiving this because you were assigned.Message ID: @.***>
Patched some parts, but the proper solution would an ES6 module. (Maybe I do it if I have time). Where to put modules? There is a dynamic directory but probably this is for modules loaded dynamically. Grid generators are certainly always loaded but still might be the right place. IDK, So the question is: where to put (static) ES6 modules?
Patched some parts, but the proper solution would an ES6 module. (Maybe I do it if I have time). Where to put modules? There is a dynamic directory but probably this is for modules loaded dynamically. Grid generators are certainly always loaded but still might be the right place. IDK, So the question is: where to put (static) ES6 modules?
We can move all 'generators' into a specific folder and create an 'esm' subfolder. But as we don't use bundling yet we will probably load this module via the script tag from index.html. So it can be in the same folder as other generators. Any solution will work, I don't have strong opinion here
We can move all 'generators' into a specific folder and create an 'esm' subfolder. But as we don't use bundling yet we will probably load this module via the script tag from index.html. So it can be in the same folder as other generators. Any solution will work, I don't have strong opinion here
I don't think there will be that many point-field-generators. I would draw a border of abstraction at Grid level. Grids could be defined as a tuple of map and inverse map from ids to 2D coordinates Tuple<i32 => [float,float], [float,float] => i32>. Using this abstraction we could have finite, infinite maps, transformed (projected) maps. If we add "scale" to the inputs, we could have even recursive maps (kinda level of detail maps). But one step one time.
I just wanted to know where to put the modules. I think import is working in es modules, you don't need a bundler. (of course it won't work in non-modules like index.js but we can import from our other modules without problem).
Sorry, misclicked and closed the PR. Reopened
A new user left a comment. This user must be approved by a Netlify team owner before comments can be displayed.