Feedback on "math.noise"

Bug Reports Documentation Issues
1

The math.noise() function has an undocumented maximum input value that causes it to return 0 for all inputs above this threshold. This has caught me out multiple times.

Findings:

  • Maximum safe input I’ve found: 262,104
  • Inputs >= 262,144 (2^18): Begin degrading, with only 94% of sampled values producing non-zero results
  • Inputs >= 4,194,304 (2^22): Always return 0
  • Partial degradation: Between 2^18 and 2^22, the function progressively loses precision

This limitation affects common use cases:

  • math.noise(tick()) always returns 0 because tick() returns values ~1.7 billion
  • Large coordinate systems (e.g., procedurally generated worlds) may have regions where noise fails
  • Time-based animations using tick() directly will not work

It’d be good if you could update the docs to:

  1. Highlight what the safe range for inputs are (and confirm)
  2. Provide examples of safe usage patterns:
    • math.noise(tick() % 262104) for time-based noise
    • math.noise(tick() * 0.0001) for scaled time-based noise
    • Coordinate clamping or scaling for large spatial systems

Testing Method (using Assistant):
Tested with fractional offsets (0.01 to 0.99) at various magnitudes. Results show 98% non-zero at 2^10 through 2^18, degrading to 94% at 2^18, and 0% at 2^22 and above.

Affected URL: https://create.roblox.com/docs/reference/engine/libraries/math#noise

3 Likes
2

Hey Ed_Win5000, this is a cool one, thanks for all the investigation and reporting. To quote from our developer, “We want to split the input numbers into an integer part (for the cell index) and a fractional part (for interpolation between cells). However, as the inputs become large, most of the mantissa in the floats is used to represent the integer part and none for the fractional part, which is why it then always returns 0.”

For workarounds, the easiest one is just to use time() instead of tick(). If you must use a large number, you can do math.noise(tick() % 256) “since noise repeats exactly every 256 cells.”

The plan is to update the function to make it more precise. I’ve also added a note to the docs that will flow in over the next couple days, and we’ll remove the note when we update the function.

3 Likes
3

Thanks, that’s helpful information! It sounds as if doing % 256 within the function would solve the issue without any obvious consequences unless anyone happens to rely on the existing odd behaviour.