arlyon / bluenoise-rs

Ergonomic blue noise (poisson disk sampling) for the masses.

Hello!

My name is Alex, I am a London-based, open source enthusiast. I work on arlyon/async-stripe, vercel/turbo, and arlyon/stailwc. If you're in London and want to chat about open source, rust, or build systems get in touch!

bluenoise-rs's Issues

Handling invalid input

There are a few input values that cause panics in rand or from bad maths. It would be nice to protect users from these.

• width <= 0 cause range errors in rand
• height <= 0 cause range errors in rand
• max_samples == 0 cause divide by zero errors
• very high widths / heights or very low min_radius causes multiplication overflow errors when creating the grid vector.

The first three are easy to handle. The last one, not so much. Integer overflow is obviously not great but what if we were to fix it? Attempted allocation for > 2^64 Vec2 is a good hundred exabytes. I am for preventing an overflow panic, but I am very against handling 'too large' grids because we don't want to impose arbitrary limits.

One option is to create a proper builder, with a build method returning something along the lines of Result<BlueNoise, BuildError>.

"An Improved Version of Bridson's Algorithm" is incorrect

The algorithm described in Extreme Learning is incorrect: it does not generate blue noise.

Blue Noise is uniform in high frequency with no low frequency component. While the blog post claims that we need not sample the annulus uniformly, the post provides no justification for this claim. By sampling non-uniformly, the algorithm preferentially generates samples that are (r + epsilon) units apart at the expense of the interval (r + epsilon,2r). This is trading correctness for speed.

Potential accuracy issues due to loss of precision

The article here (http://extremelearning.com.au/an-improved-version-of-bridsons-algorithm-n-for-poisson-disc-sampling/) describes the use of some epsilon value seen here as a work around for floating point precision issues, by adding some small value to the radius when generating new points. I have enabled a lint to highlight locations where we lose precision thanks to clippy::cast_possible_truncation. Maybe by eliminating these we can also eliminate the epsilon?

It should be noted that this epsilon will probably cause the algorithm to perform strangely on small ranges / radii so as a workaround making it a function of the radius is probably a good mitigation.

Wrapping blue noise could maybe be generated faster

WrappingBlueNoise's algorithm is currently implemented as a minor variation on BlueNoise's algorithm, with sampling and distance calculations wrapping around the edges of the box. Since the distance calculation happens very frequently (up to 25 times per sample), it may be worthwhile to optimize it.

This could be done by putting a 2-thick border of cells around the grid, so that points near the edges of the grid are duplicated on the opposite edge. This would allow WrappingBlueNoise's distance calculations to be identical to those of BlueNoise. This approach would use more memory to make insert_point() slower and distance() faster.