Page MenuHome

Color Ramp node keyed colors and keyed positions jumps to the next color stop when adding or removing color stops
Confirmed, LowPublicKNOWN ISSUE

Description

Blender Version
Broken: 2.7x, 2.8x

Short description of error
The keyed color and position should be assigned to the color stop itself, not it's order. As of now it follows the order of stops, so the keyed color and position jumps from one color stop to next one when a color stop is added or removed.

Exact steps for others to reproduce the error

  • open blender
  • go the shader editor
  • make a new material
  • add a color ramp node
  • Press "i" with the mouse hovering the black bar to key the color.

now the white color stop and do the same, key the color by pressing "i" over it.
now select the black color stop and remove it by clicking the "-"

  • press space bar to play, the keyed color will jump from the black one that was removed to the white one.

The same happens if you key the color stop's position instead of it's color.
It also jumps when adding in a color stop instead of removing one.

Event Timeline

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Jun 19 2020, 5:29 AM
Germano Cavalcante (mano-wii) triaged this task as Low priority.
Germano Cavalcante (mano-wii) updated the task description. (Show Details)
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".Jun 19 2020, 5:36 AM

I can imagine why this happens.
Perhaps a diver/keyframe takes a stop reference as being index + position.
When you delete a stop you change the index of the rest, but the references in the drivers are not updated.

I imagine the confusion can be greater if a driver changes the order of stops.

Perhaps updating references can add a lot of overhead to the code. So it is not guaranteed that it is worth fixing it.

Jacques Lucke (JacquesLucke) changed the subtype of this task from "Bug" to "Known Issue".Tue, Sep 15, 11:29 AM

It's unlikely that this will be worked on soon. So I'll reclassify this as known issue.

It might be worth considering whether we could give each stop some kind of unique id that is referenced by fcurves and drivers, instead of referencing them by index. That might be much easier to do than to update all references when a new stop is inserted or one is removed.