Inconsistent behavior in Dynamic Paint when moving Canvas towards Brush (keyed vs unkeyed) #78556

New Issue

Evandro Costa · 2020-07-03T00:05:14+02:00

Evandro Costa commented

2020-07-03 00:05:14 +02:00

System Information
Operating system: Windows 10
Graphics card: rtx2080

Blender Version
Broken: 2.83.0, branch: master, hash: 211b6c29f7
Working (partly): 2.79 (paints correctly until operation is confirmed)

Short description of error
If one press play and in the viewport moves the canvas towards a static brush object, the effect only happens inside the collision area, but it doesn't remain, and instantly returns to normal as soon as the collision ends.

Expected behavior: Moving canvas towards brush acts the same as moving brush towards canvas, in realtime playback mode (without keyframes set and with 0 canvas Sub-Steps)
Current behavior: (inconsistent) Moving canvas in playback mode only paints temporarily the intersection between canvas and brush, returns to normal after the intersection ends. If the movement is keyframed instead, it works as expected, painting normally.

GIF of the problem:

Exact steps for others to reproduce the error
Dynamic Paint.blend

Open file
Start animation playback
Grab {key G} brush and move it through canvas by hand - animation is updated smoothly
Grab {key G} canvas and move it through brush by hand - animation not updated smoothly

Possibly related links
Fix #62882: Make Dynamic Paint update weights in viewport
Dynamic Paint Sub-Steps not working when Canvas is moving (problem occurs even with 0 sub-steps, so it's not really the same issue)

**System Information** Operating system: Windows 10 Graphics card: rtx2080 **Blender Version** Broken: 2.83.0, branch: master, hash: 211b6c29f771 Working (partly): 2.79 (paints correctly until operation is confirmed) **Short description of error** If one press play and in the viewport moves the `canvas` towards a static `brush` object, the effect only happens inside the collision area, but it doesn't remain, and instantly returns to normal as soon as the collision ends. **Expected behavior:** Moving canvas towards brush acts the same as moving brush towards canvas, in realtime playback mode (without keyframes set and with 0 canvas Sub-Steps) **Current behavior:** (inconsistent) Moving canvas in playback mode only paints temporarily the intersection between canvas and brush, returns to normal after the intersection ends. If the movement is keyframed instead, it works as expected, painting normally. **GIF of the problem:** ![DynamPaint.gif](https://archive.blender.org/developer/F8660528/DynamPaint.gif) **Exact steps for others to reproduce the error** [Dynamic Paint.blend](https://archive.blender.org/developer/F8660531/Dynamic_Paint.blend) - Open file - Start animation playback - Grab {key G} brush and move it through canvas by hand - animation is updated smoothly - Grab {key G} canvas and move it through brush by hand - animation not updated smoothly **Possibly related links** [Fix #62882: Make Dynamic Paint update weights in viewport ](https://developer.blender.org/D6072) [Dynamic Paint Sub-Steps not working when Canvas is moving ](https://developer.blender.org/T48797) (problem occurs even with 0 sub-steps, so it's not really the same issue)

Evandro Costa commented

2020-07-03 00:05:14 +02:00

Added subscriber: @EvandroFerreiradaCosta

Germano Cavalcante commented

2020-07-03 19:43:35 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-07-03 19:43:35 +02:00

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

Germano Cavalcante closed this issue

2020-07-03 19:43:35 +02:00

Germano Cavalcante self-assigned this 2020-07-03 19:43:35 +02:00

Germano Cavalcante commented

2020-07-03 19:43:35 +02:00

I don't see this as a bug because the brush paints the weights per frame and not all the desired weights in a single frame.

It is used for animation, so it is important to have a consistent result.

If it doesn't readjust in each frame, I see more problems than solutions.

Anyway, thanks for the report, but the issue reported here is a request for modified/improved behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors.

For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

I don't see this as a bug because the brush paints the weights per frame and not all the desired weights in a single frame. It is used for animation, so it is important to have a consistent result. If it doesn't readjust in each frame, I see more problems than solutions. Anyway, thanks for the report, but the issue reported here is a request for modified/improved behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors. For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Evandro Costa commented

2020-07-04 01:23:54 +02:00

Thanks for looking into the issue.
Are you saying that is it working as intended that moving a canvasthrough abrushactsdifferentlythan moving abrush through acanvas**, with playback active?
Or is it NOT an intended behavior?

I agree that it should have a consistent result, that's why (as I demostrated with the gif and file), the result of moving one through the other should be the same as in the reverse direction.
Right now this only happens correctly if keyframes are set, but doesn't happen correctly and consistently when only moving objects in the viewport with playback.

The solution is not to stop readjusting in each frame, this would be crazy. The solution is to see why, with hitting play, moving a canvas through a brush acts differently than the opposite way.

(I don't see this as a feature request because the feature is already there, it's just not working in a consistent manner.)

Thanks for looking into the issue. Are you saying that is it working *as intended* that moving a ***canvas***through a***brush***acts**differently**than moving a***brush* **through a***canvas***, `with` playback active? Or is it NOT an intended behavior? I agree that it should have a consistent result, that's why (as I demostrated with the gif and file), the result of moving one through the other should be the same as in the reverse direction. Right now this only happens correctly if keyframes are set, but doesn't happen **correctly and consistently** when only moving objects in the viewport with playback. The solution is not to stop readjusting in each frame, this would be crazy. The solution is to see why, with hitting play, moving a canvas through a brush acts differently than the opposite way. (I don't see this as a feature request because the feature is already there, it's just not working in a consistent manner.)

Germano Cavalcante commented

2020-07-04 04:19:56 +02:00

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

Germano Cavalcante reopened this issue

2020-07-04 04:19:56 +02:00

Germano Cavalcante removed their assignment 2020-07-04 04:19:56 +02:00

Germano Cavalcante commented

2020-07-04 04:19:56 +02:00

I may have misunderstood the problem.
The description makes it look like the problem is comparing with playback and without playback.

I will take a better look later.

I may have misunderstood the problem. The description makes it look like the problem is comparing with playback and without playback. I will take a better look later.

Evandro Costa commented

2020-07-04 20:39:37 +02:00

Thanks! I have worded the issue in a way that became too confuse. So confuse in fact that I myself made several mistakes in my last reply to you. I have now edited the mistakes, I'm sorry.
But the first post, the error description, steps and the GIF, were correct in describing the problem, so I don't have to change them.

The problem happens with playback active... The difference appears (during playback) between moving canvas through brush and vice-versa, and with or without the canvas having a keyframeset.

You can check it by downloading the blend file, pressing play, and moving canvas through brush and vice-versa. Then activate the canvas keyframes in the dopesheet and repeat the process.

So during playback:
Without canvas keyframes:

move brush through canvas = works correctly
move canvas through brush = works problematically (during intersection only, as if playback was not happening)
With canvas keyframes:
both work correctly as expected.

(I now understood what you meant by the painting only happening correctly in a per-frame basis because without playback active the effects of dynamic paint happen only temporarily during the intersection, which is expected)
Again, I'm sorry for making this so confuse and making several mistakes in my last reply. And thanks for taking a second look!

Thanks! I have worded the issue in a way that became too confuse. So confuse in fact that I myself made several mistakes in my last reply to you. I have now edited the mistakes, I'm sorry. But the first post, the error description, steps and the GIF, were correct in describing the problem, so I don't have to change them. The problem happens **with** playback active... The difference appears (**during playback**) between moving canvas through brush and **vice-versa,** and **with or without** the canvas having a **keyframe**set. You can check it by downloading the blend file, pressing play, and moving canvas through brush and vice-versa. Then activate the canvas keyframes in the dopesheet and repeat the process. So during playback: *Without canvas keyframes:* - move brush through canvas = works correctly - move canvas through brush = works problematically (during intersection only, as if playback was not happening) *With canvas keyframes:* - both work correctly as expected. (I now understood what you meant by the painting only happening correctly in a per-frame basis because without playback active the effects of dynamic paint happen only temporarily during the intersection, which is expected) Again, I'm sorry for making this so confuse and making several mistakes in my last reply. And thanks for taking a second look!

Richard Antalik commented

2020-07-08 01:14:16 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-07-08 01:14:16 +02:00

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

Richard Antalik commented

2020-07-08 01:14:16 +02:00

I think this is because grabbing canvas will invalidate dynamic paint cache. Since this is working in 2.79 I will confirm, but this may be technical limitation of cache system so it may not be a bug.

Evandro Costa commented

2020-07-08 21:44:26 +02:00

Thanks for checking the issue as well Richard!
If it happens to be the case that this is due to a technical limitation, I'd appreciate if you would advise me if creating a feature/improvement request on the proper venues would be helpful, or worthless, in case this is a part of Blender code that is not and would not be so easily changed. Thanks!

Thanks for checking the issue as well Richard! If it happens to be the case that this is due to a technical limitation, I'd appreciate if you would advise me if creating a feature/improvement request on the proper venues would be helpful, or worthless, in case this is a part of Blender code that is not and would not be so easily changed. Thanks!

Jacques Lucke commented

2020-08-13 12:46:27 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2020-08-13 12:46:27 +02:00

Changed status from 'Confirmed' to: 'Archived'

Jacques Lucke closed this issue

2020-08-13 12:46:27 +02:00

Jacques Lucke self-assigned this 2020-08-13 12:46:27 +02:00

Jacques Lucke commented

2020-08-13 12:46:27 +02:00

I think @iss is right: grabbing the canvas invalidates the cache. This also matches the comment /* Manual edits to any dependency (or self) should reset the point cache. */ in deg_builder_relations.cc.
It would be nice if we could better support moving objects in the viewport, while the simulation runs. Most (all?) simulations we have currently do expect that objects are not moved by the user while the simulation runs, and will reset the cache otherwise. There is a special RELATION_FLAG_FLUSH_USER_EDIT_ONLY flag, which seems to handle this case exactly.

It's unlikely, that someone will be working on this for the existing simulation systems anytime soon. It is also a bit related to the goal of separating simulation and scene time (which would allow more interactive interaction with a running simulation).

I think @iss is right: grabbing the canvas invalidates the cache. This also matches the comment `/* Manual edits to any dependency (or self) should reset the point cache. */` in `deg_builder_relations.cc`. It would be nice if we could better support moving objects in the viewport, while the simulation runs. Most (all?) simulations we have currently do expect that objects are not moved by the user while the simulation runs, and will reset the cache otherwise. There is a special `RELATION_FLAG_FLUSH_USER_EDIT_ONLY` flag, which seems to handle this case exactly. It's unlikely, that someone will be working on this for the existing simulation systems anytime soon. It is also a bit related to the goal of separating simulation and scene time (which would allow more interactive interaction with a running simulation).

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

Inconsistent behavior in Dynamic Paint when moving Canvas towards Brush (keyed vs unkeyed) #78556