Changed behaviour in RGB Curves node interpolation #81743

New Issue

Simon Thommes · 2020-10-15T18:17:44+02:00

Simon Thommes commented

2020-10-15 18:17:44 +02:00

System Information
Operating system: Linux-5.4.0-7642-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 455.28

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-15 08:00, hash: f1aa55b6e9
Worked: 2.90.1

Short description of error
The interpolation behaviour of the RGB Curves node seems to have changed. This makes shaders inconsistent between versions.
I am not sure when this changed, the behaviour I am comparing it to is from 2.83.5.
Edit: 2.90.1 still seems to show the same behaviour as 2.83.5

Exact steps for others to reproduce the error
Attached file behaves differently for different versions of Blender:
RGB_Curves_interpolation_test.blend

**System Information** Operating system: Linux-5.4.0-7642-generic-x86_64-with-debian-bullseye-sid 64 Bits Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 455.28 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-15 08:00, hash: `f1aa55b6e9` Worked: 2.90.1 **Short description of error** The interpolation behaviour of the RGB Curves node seems to have changed. This makes shaders inconsistent between versions. I am not sure when this changed, the behaviour I am comparing it to is from 2.83.5. Edit: 2.90.1 still seems to show the same behaviour as 2.83.5 ![image.png](https://archive.blender.org/developer/F8995145/image.png) **Exact steps for others to reproduce the error** Attached file behaves differently for different versions of Blender: [RGB_Curves_interpolation_test.blend](https://archive.blender.org/developer/F8995138/RGB_Curves_interpolation_test.blend)

Simon Thommes commented

2020-10-15 18:17:44 +02:00

Added subscriber: @SimonThommes

Sybren A. Stüvel self-assigned this 2020-10-15 18:35:22 +02:00

Sybren A. Stüvel commented

2020-10-15 18:35:32 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Julian Eisel commented

2020-10-15 18:46:06 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2020-10-15 18:46:06 +02:00

Oh gosh...

@dr.sybren I'm pretty sure this is caused by da95d1d851. It modifies correct_bezpart() which is also called as part of by curve-map curve evaluation, not just for FCurves.

Now here comes the fun: We use curve-maps in many places - modifiers, brush falloffs, particles, motion-blur shutter, ... Most of it stored in files. We may have broken compatibility for many files.

Oh gosh... @dr.sybren I'm pretty sure this is caused by da95d1d851. It modifies `correct_bezpart()` which is also called as part of by curve-map curve evaluation, not just for FCurves. Now here comes the fun: We use curve-maps in many places - modifiers, brush falloffs, particles, motion-blur shutter, ... Most of it stored in files. We may have broken compatibility for many files.

Sybren A. Stüvel commented

2020-10-15 19:33:42 +02:00

Argh, that must be why that code is place right under a comment /** \name F-Curve Calculations and declared in BKE_fcurve.h.

I also found that same commit while bisecting, so it's definitely caused by that.

The changes in correct_bezpart() assumed that the pre-existing curves were corrected by the versioning code. This wasn't done for non-FCurve curves, hence the changed results. The good news is that this means that the in-file data hasn't been modified (at least not by the versioning code), and that thus a rollback of the changes in correct_bezpart() will produce the correct results again. At least it does so for the test file Simon uploaded.

I'll put the old (pre- da95d1d851) function into curve.c and call it BKE_curve_correct_bezpart(), and name the FCurve-specific function BKE_fcurve_correct_bezpart().

Argh, that must be why that code is place right under a comment `/** \name F-Curve Calculations` and declared in `BKE_fcurve.h`. I also found that same commit while bisecting, so it's definitely caused by that. The changes in `correct_bezpart()` assumed that the pre-existing curves were corrected by the versioning code. This wasn't done for non-FCurve curves, hence the changed results. The good news is that this means that the in-file data hasn't been modified (at least not by the versioning code), and that thus a rollback of the changes in `correct_bezpart()` will produce the correct results again. At least it does so for the test file Simon uploaded. I'll put the old (pre- da95d1d851) function into `curve.c` and call it `BKE_curve_correct_bezpart()`, and name the FCurve-specific function `BKE_fcurve_correct_bezpart()`.

blender-admin commented

2020-10-15 19:38:20 +02:00

This issue was referenced by 91af828e8b

This issue was referenced by 91af828e8bfaa04cbd49f1859e06a1f76749102d

Sybren A. Stüvel commented

2020-10-15 19:50:04 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sybren A. Stüvel closed this issue

2020-10-15 19:50:04 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Changed behaviour in RGB Curves node interpolation #81743