Skip to content
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

noiseMode(SIMPLEX)? #6152

Open
kaitabuchi314 opened this issue May 22, 2023 · 11 comments
Open

noiseMode(SIMPLEX)? #6152

kaitabuchi314 opened this issue May 22, 2023 · 11 comments

Comments

@kaitabuchi314
Copy link

Topic

I think Simplex Noise would be a very good enhancement. It seems p5.js is not working on it. If you want to make sure that the previous projects don't break.

A fix for this may can be done like centering rectangles, I fell that it would be a good idea to have maybe a noiseMode(SIMPLEX) and noiseMode(PERLIN), this would allow a decision by the user, if they want Perlin Noise they could use noiseMode(PERLIN), or just leave it out (It could be the default for compatibility), or if they want to use (better) Simplex Noise they could use noiseMode(SIMPLEX).

Here are some reasons Simplex is better (Thanks ChatGPT):

  1. Improved computational efficiency.
  2. Higher quality and smoother results.
  3. Improved isotropy and higher-dimensional performance.
  4. Easier implementation and understanding.
@limzykenneth
Copy link
Member

Hi @thecodingcookery, I think this should count as a feature request and as such with all feature request, we require that an explanation of how this feature increases access to p5.js from different angles of diversity, you can read more about it here. I'll leave this issue open for anyone to chip in on the access statement. Thanks.

@hellonearthis
Copy link
Contributor

Yes, this would make for a good feature, epically since the simplex patent expired on January 8, 2022

If you do submit a feature request @kaitabuchi314 you could consider these points.

The addition of simplex noise to the p5.js library from an accessibility standpoint.

  • Improved Visual Accessibility: Simplex noise provides smoother, more visually appealing results compared to Perlin noise. This characteristic is especially important for users who may have visual impairments or sensitivities. By incorporating Simplex noise into p5.js, individuals with different visual abilities will have access to a wider range of visually pleasing and inclusive generative art experiences.

  • Enhanced Performance and Optimization: Simplex noise is computationally efficient, making it particularly valuable for users who may be working on resource-constrained devices or have limited processing power. Its improved performance can benefit users with diverse computing capabilities, ensuring a smooth experience across a broader range of devices.

  • Easier Implementation and Understanding: The implementation of Simplex noise is generally considered to be simpler and more intuitive than that of Perlin noise. By adding Simplex noise to p5.js, you lower the barrier of entry for newcomers and make it easier for developers of all levels of expertise to create complex and engaging graphics. This fosters inclusivity within the p5.js community and encourages a wider range of people to explore creative coding.

  • Diverse Artistic Possibilities: Simplex noise offers a distinct aesthetic quality that differs from Perlin noise. By introducing Simplex noise into p5.js, you empower artists, designers, and creative coders to experiment with new visual styles and artistic expressions. This diversity of possibilities further enriches the p5.js ecosystem and encourages a more inclusive community of creators.

@kaitabuchi314 kaitabuchi314 mentioned this issue Jun 8, 2023
17 tasks
@limzykenneth
Copy link
Member

@hellonearthis Only very recently realised there's a patent on Simplex Noise, which was quite surprising (to me), probably also why it wasn't used in Processing and p5.js before.

I'm happy with this feature being implemented in this case. I feel noiseType() is more semantic but noiseMode() will probably be the more familiar and better option.

Tagging math stewards @jeffawang and @AdilRabbani if you wanted to review this before approving this for implementation in a PR.

@Qianqianye
Copy link
Contributor

Thank you all for working on this issue. I am inviting the current Math stewards to this discussion @limzykenneth, @ericnlchen, @ChihYungChang, @bsubbaraman, @albertomancia, @JazerUCSB, @tedkmburu, @perminder-17, @Obi-Engine10, @jeanetteandrews. Would love to hear what y'all think. Thanks!

@Vishal2002
Copy link
Contributor

Is it still open to contribute ? Love to discuss the problem and work on the solution

@Vishal2002
Copy link
Contributor

@kaitabuchi314 Do you need a separate function named noiseMode() which takes what type of noise the user need?

@Vishal2002
Copy link
Contributor

Vishal2002 commented Jan 17, 2024

@limzykenneth Sir the patent is over and I think now we are good to go with the implementation of this feature. While looking for the Simplex noise with js I found this repo [(https://github.com/josephg/noisejs)]. Hope this helps in implementation.

@limzykenneth
Copy link
Member

In view of the 2.0 RFC in #6678, I think for this change we'll just directly implement it as part of 2.0 with Simplex noise being the default noise implementation and not providing the older Perlin noise (nor noiseMode). For those that need the older Perlin noise implementation, a addon style patch file can be used to patch into the older behaviour.

@mattdesl
Copy link
Contributor

The current p5 noise function has some quirks that I think would be worth ironing out:

  • Simplex will probably be faster than Perlin, so I think it is a good default choice
  • It would be good to support higher dimensions like 4D noise
  • I personally think the noise() function should be 'raw' — as far as I understand, p5 currently provides some kind of fractal/octave and level of detail when using noise, which makes it hard to use practically. This should be moved into a new function like fractalNoise2D(x, y, levelOfDetail)
  • Currently the approach of argument overloading the noise function for differnet dimensions may impede its performance compared to separate functions for 2D/3D/etc. However this might be something that stays unchanged given the goals of ease of use and accessibility. It would be worth benchmarking to determine the cost.
  • The random seed should be aligned to the noise in my opinion, so that fixing the random seed also fixes the noise randomness, rather than requiring two seeds to be set. This is something I have noticed many students get tripped up about when they first start using noise.
  • In my own gen artworks I have occasionally found it useful to have an "instance mode" so that a new noise functions can be created independently of the global seed. Example below:
// global noise tied to randomSeed
const v = noise2D(x,y);

// instance noise with specific seed
const noise = Noise2D(mySeed)
const v2 = noise(x, y);

If a larger proposal is required for these changes let me know, but I feel they would be good candidates for a v2 overhaul of the noise functions.

In terms of implementation, I would recommend using an existing library, these are two modules that I like:
https://github.com/jwagner/simplex-noise.js
https://github.com/joshforisha/fast-simplex-noise-js (more modular, note my perf improvement here)

@limzykenneth
Copy link
Member

@mattdesl All really good points, thanks! I think as you mentioned there are probably space to flesh out some of the details as a larger proposal, I think if you prefer a proof of concept implementation may be helpful tool. A couple points below:

I personally think the noise() function should be 'raw' — as far as I understand, p5 currently provides some kind of fractal/octave and level of detail when using noise, which makes it hard to use practically. This should be moved into a new function like fractalNoise2D(x, y, levelOfDetail)

For this I would actually go the other way round and have a rawNoise() function instead. This is because not having that kind of fractal behavior is a very massive breaking change, not only potentially breaking user's code but also breaking many of the tutorials out there that expects this.

The random seed should be aligned to the noise in my opinion, so that fixing the random seed also fixes the noise randomness, rather than requiring two seeds to be set. This is something I have noticed many students get tripped up about when they first start using noise.

There may be a case where a specific random stream is being relied upon in the RNG but a different noise stream is being relied upon for seeded noise so I'm not sure about aligning the seed here. Or someone may want to seed their noise but not seed their RNG to get some uncontrolled randomness that works with fixed noise.

@davepagurek
Copy link
Contributor

It would be good to support higher dimensions like 4D noise

Just adding a +1 for this! If that's easier to add with a simplex noise implementation, then that would be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Proposal
Development

No branches or pull requests

8 participants