-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incremental generation & other ideas #2
Comments
What I am currently doing myself is implementing tile based Poisson disk distributions [1], but I would be interested on implementing these features to my library too. [1] Lagae, Ares, and Philip Dutré. "An alternative for Wang tiles: colored edges versus colored corners." ACM Transactions on Graphics (TOG) 25.4 (2006): 1442-1459. |
I made initial implementation of incremental generation: https://github.com/WaDelma/poisson/tree/incremental |
I've pushed my test code in a clean branch of my repo: https://github.com/cdlm/poisson-surface.rs/blob/wadelma/src/main.rs If you run it, you will see points appear all over the window. But in Mike Bostock's implementation, new points only appear in the neighbourhood of existing ones, and the point set grows from there. I guess that's what your |
The Ebeidas et al algorithm that I have implemented works differently to Bridsons' algorithm that Bostock/Davies have implented. Where Bridsons' algorithm starts from one point and adds points randomly based on it, the Ebeidas' algorithm can been seen as optimisation of naive dart throwing algorithm where new points don't directly relate to old ones. What Ebeidas' algorithm does is that it splits the space in to a grid in which each cell can only contain at most one sample (their dimensions are chosen depending on the radius). In one iteration certain amount of samples are tried to random position of random cell of the grid. After those tries each cell is subdivided to half for each dimension same way as in quadtree/octree and cells that are covered by existing samples are discarded. This is continued until there is no cells left. If you need same kind of effect as in the Bridson's, then Ebeidas isn't really useful as it's basically just fast way of doing dart throwing... :/ Potentially I could add Bridson's algorithm to this library, so both algorithms would be under same API... |
I think they are both really close: my implementation of Bridson's algo (not the Rust one) also uses a similar grid for proximity lookup, and a list of active "seed" points or cells. So the data is the same or really similar, and only the behavior differs. |
I started implementing arbitary point insertion, but I stumbled upon design choise I am not sure about. |
Nice ! I have little time to play with this these days, sadly… but I hope to come back to it |
Np. Was fun to work with it (and completely redesign the API 3 times xD). Btw I also implemented Bridsons algorithm. |
As you've seen I started my own implementation as a toy, to learn Rust. My idea was to make an interactive / generative art sort of thing, so there were a few features I imagined:
Vec
Do any of those match your use-case? Any clues on how they could be best implemented?
The text was updated successfully, but these errors were encountered: