F-curve noise modifiers can create functions with values outside the defined range (0 to 1, -0.5 to 0.5) #123875

New Issue

Benjamin-McDowall · 2024-06-28T08:41:12+02:00

Benjamin-McDowall commented

2024-06-28 08:41:12 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 555.99

Blender Version
Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: e1743a0317bc
Worked: N/A
(Oldest installable archived version, 3.3.17, branch: master, commit date: 2024-03-18 13:37, hash: 1057a9e58afe, also has issue)

Short description of error
F-curve noise modifiers can create functions with values outside the defined range described by the manual.
Values outside of the defined range then get clamped to the maximum value of the range.

Exact steps for others to reproduce the error
Open Blender
Insert/select any object and insert location and/or rotation keyframes
Open a new window and set it to graph editor
Select any F-curve and add a noise modifier
Set the scale and strength to whatever
Set the phase to 47, 29, 90, 31, 68, or 25 (personally confirmed, there very well may be more)

Skim 0.5 times strength and -0.5 times strength values and look for clamped flat spots

[Based on an attached .blend file (as simple as possible)]

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 555.99 **Blender Version** Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: `e1743a0317bc` Worked: N/A (Oldest installable archived version, 3.3.17, branch: master, commit date: 2024-03-18 13:37, hash: `1057a9e58afe`, also has issue) **Short description of error** F-curve noise modifiers can create functions with values outside the defined range described by the manual. Values outside of the defined range then get clamped to the maximum value of the range. **Exact steps for others to reproduce the error** Open Blender Insert/select any object and insert location and/or rotation keyframes Open a new window and set it to graph editor Select any F-curve and add a noise modifier Set the scale and strength to whatever Set the phase to 47, 29, 90, 31, 68, or 25 (personally confirmed, there very well may be more) Skim 0.5 times strength and -0.5 times strength values and look for clamped flat spots [Based on an attached .blend file (as simple as possible)]

Issue example.blend

1.1 MiB

0001-0480.mp4

4.7 MiB

_ Shipment inspection [F__Commissions_Renders_Shipment inspection.blend] - Blender 4.1 6_26_2024 3_18_30 PM.png

492 KiB

_ Shipment inspection [F__Commissions_Renders_Shipment inspection.blend] - Blender 4.1 6_28_2024 12_59_53 AM.png

2.2 MiB

_ Shipment inspection [F__Commissions_Renders_Shipment inspection.blend] - Blender 4.1 6_28_2024 1_11_18 AM.png

1.8 MiB

_ Shipment inspection [F__Commissions_Renders_Shipment inspection.blend] - Blender 4.1 6_26_2024 3_18_30 PM.png

_ Shipment inspection [F__Commissions_Renders_Shipment inspection.blend] - Blender 4.1 6_28_2024 12_59_53 AM.png

_ Shipment inspection [F__Commissions_Renders_Shipment inspection.blend] - Blender 4.1 6_28_2024 1_11_18 AM.png

Benjamin-McDowall added the

labels 2024-06-28 08:41:13 +02:00

YimingWu commented

2024-06-28 10:02:00 +02:00

Looks like the clamping is happening in orgBlenderNoise (code for that part is at least 22 yeas old), and the F-Curve modifier doesn't do any clamping.

Considering this noise function will be called by other functions as well and used in various different places, we probably should not change this since it may break existing files slightly when they do reach the clamping positions. And since it's breaking in orgBlenderNoise, the strength scale won't really do anything either. I'd say this is known issue, but maybe animation guys can clarify

Looks like the clamping is happening in `orgBlenderNoise` (code for that part is at least 22 yeas old), and the F-Curve modifier doesn't do any clamping. Considering this noise function will be called by other functions as well and used in various different places, we probably should not change this since it may break existing files slightly when they do reach the clamping positions. And since it's breaking in `orgBlenderNoise`, the strength scale won't really do anything either. I'd say this is known issue, but maybe animation guys can clarify

YimingWu added

and removed

labels 2024-06-28 10:02:22 +02:00

Nathan Vegdahl commented

2024-06-28 10:30:10 +02:00

My understanding is that Perlin noise is supposed to stay within bounds by construction, without need for clamping. However, it doesn't surprise me that the old "Blender Noise" fails to adhere to that. This is undesirable even for the other applications of noise in Blender (e.g. procedural textures in shaders, etc.), but I think those other areas of Blender have already moved on to other noise implementations(?).

I'll look into this. The fix might be to just switch to one of the newer noise implementations (with a flag to use the old one for backwards compatibility).

My understanding is that Perlin noise is supposed to stay within bounds by construction, without need for clamping. However, it doesn't surprise me that the old "Blender Noise" fails to adhere to that. This is undesirable even for the other applications of noise in Blender (e.g. procedural textures in shaders, etc.), but I think those other areas of Blender have already moved on to other noise implementations(?). I'll look into this. The fix might be to just switch to one of the newer noise implementations (with a flag to use the old one for backwards compatibility).

Nathan Vegdahl self-assigned this 2024-06-28 10:31:11 +02:00

Nathan Vegdahl commented

2024-06-28 12:17:49 +02:00

As far as I can tell, all the other areas of Blender are using the new Perlin noise implementations in BLI_noise.hh (not to be confused with BLI_noise.h where the old implementations are). And the newer implementations are done properly, preventing the generated values from going out of bounds by construction.

(Edit: actually, it looks like there are a handful of other places that do still use the old broken Perlin noise. Just not with a direct function call to BLI_noise_turbulence().)

Additionally, the newer fractal Perlin noise implementation has more knobs to turn, which allows for a wider range of noise patterns. So it would probably be valuable to switch to the new implementation even just for that.

So I think what we should do is add a drop-down menu to the noise modifier, similar to the drop-down in the noise shader node, with an option for old broken noise and an option for new correct noise. The new correct noise should use the perlin_fbm() function from BLI_noise.hh with 1D input and the normalize parameter set to true.

Since the current noise is indeed broken, I do think this counts as a bug. Although the fix is also kind of adding a feature.

I'll be happy to tackle this myself eventually, but if someone else gets to it first that would also be great. So I'll unassign myself until I'm actively working on it.

As far as I can tell, all the other areas of Blender are using the new Perlin noise implementations in `BLI_noise.hh` (not to be confused with `BLI_noise.h` where the old implementations are). And the newer implementations are done properly, preventing the generated values from going out of bounds by construction. (Edit: actually, it looks like there are a handful of other places that do still use the old broken Perlin noise. Just not with a direct function call to `BLI_noise_turbulence()`.) Additionally, the newer fractal Perlin noise implementation has more knobs to turn, which allows for a wider range of noise patterns. So it would probably be valuable to switch to the new implementation even just for that. So I think what we should do is add a drop-down menu to the noise modifier, similar to the drop-down in the noise shader node, with an option for old broken noise and an option for new correct noise. The new correct noise should use the `perlin_fbm()` function from `BLI_noise.hh` with 1D input and the `normalize` parameter set to `true`. Since the current noise is indeed broken, I do think this counts as a bug. Although the fix is also kind of adding a feature. I'll be happy to tackle this myself eventually, but if someone else gets to it first that would also be great. So I'll unassign myself until I'm actively working on it.

Nathan Vegdahl removed their assignment 2024-06-28 12:18:01 +02:00

Bart van der Braak added

and removed

labels 2024-08-14 12:58:18 +02:00

Christoph Lendenfeld self-assigned this 2024-10-17 19:36:56 +02:00

Christoph Lendenfeld referenced a pull request that will close this issue

2024-10-29 17:01:39 +01:00

Fix #123875: FCurve noise modifier producing values out of range #129535