Page MenuHome

Missing Animation Update for Surface Resolution U & V
Closed, ResolvedPublic


System Information
Operating system: macOS 10.14.1 (18B75)
Graphics card: Intel Iris Plus Graphics 640 1536 MB

Blender Version
Broken: example: 2.79b release & 2.80
Worked: It seems to be a very old bug - never worked it seems

Short description of error
When keyframing the Surface U or V values, the viewport is not updated to reflect the changes

Exact steps for others to reproduce the error

  1. Add a Surface object type
  2. Insert a keyframe for the U or V values
  3. Change frame and insert a different value
  4. Scrub the playhead or play animation - the viewport does not update to reflect the value.

Event Timeline

Sebastian Parborg (zeddb) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Dec 14 2018, 6:48 PM

@Brecht Van Lommel (brecht) who to assign this to?

It's kind of random who to assign this to, feel free to reassign.

This is actually a topic for @Sergey Sharybin (sergey) I think… It’s not only affecting preview U/V resolution (cyclic toggle e.g. is not handled either), and it’s affecting all kind of obdata (geometry data-blocks) I think. At least am getting the same kind of non-update behavior when trying to key auto-smooth toggle and value of a mesh e.g.

@Sergey Sharybin (sergey) I guess those are missing relations in the depsgraph? This is not a regression though, so nothing like high priority task, just nice to check at some point. Or I don’t mind diving into this a bit more, if you can give me some hints of what to check.

@Brecht Van Lommel (brecht), @Bastien Montagne (mont29), the auto-smooth we should be able to fix. However, the curves/surfaces i'm not sure we can/should support.

Changing resolution on a Curve datablock goes and changes resolution on every spline. I don't think that would be a good idea to do such kind of updates from animation.
Cyclic and order i even more tricky, since they have some hidden inter-dependnecies via knots.
Cyclic will also affect handles, which might not be desirable as well.

Additionally, animating such settings makes it impossible to have motion-blur working for such objects.

Think it's easier and more predictable to simply consider those settings non-animatable rather that falling into this rabbit hole.

For the mesh settings i've created D5030.

Fine with me to make these non-animatable.