Dynamic paint sub-steps don't work when brush is driven #40597

New Issue

Garrett · 2014-06-12T23:10:44+02:00

Garrett commented

2014-06-12 23:10:44 +02:00

System Information
OS: Ubuntu 14.04
Linux kernel: 3.13.0-24-generic
Graphics:
VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1)

Blender Version
Broken: blender-2.70-aed67dc-linux-glibc211-x86_64

Short description of error

When a paint brush's motion is controlled by a driver, the "sub-steps" setting has no effect. Perhaps this is related to this bug: https://developer.blender.org/T34685

Exact steps for others to reproduce the error

Open new .blend
Delete default cube, create a plane, scale it up and create a sphere.
Create an empty and keyframe the empty to move quickly
Add a single driver to the cube's location and have it driven by empty location
Set sphere to be dynamic paint brush
UV Map the plane (TAB+U+ENTER), set plane to be dynamic paint canvas and set "Format" to be "Image Sequence". (Error occurs with "Format: Vertex" as well)
With sub-steps at 0, hit "Bake Image Sequence" and notice that you get a dotted line
Now set sub-steps to 20, hit "Bake Image Sequence" and notice you get the same dotted line instead of a smooth continuous line.

Here's a .blend with steps 1-7 completed: paint_bug.blend

**System Information** OS: Ubuntu 14.04 Linux kernel: 3.13.0-24-generic Graphics: VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1) **Blender Version** Broken: blender-2.70-aed67dc-linux-glibc211-x86_64 **Short description of error** When a paint brush's motion is controlled by a driver, the "sub-steps" setting has no effect. Perhaps this is related to this bug: https://developer.blender.org/T34685 **Exact steps for others to reproduce the error** 1) Open new .blend 2) Delete default cube, create a plane, scale it up and create a sphere. 3) Create an empty and keyframe the empty to move quickly 4) Add a single driver to the cube's location and have it driven by empty location 5) Set sphere to be dynamic paint brush 6) UV Map the plane (TAB+U+ENTER), set plane to be dynamic paint canvas and set "Format" to be "Image Sequence". (Error occurs with "Format: Vertex" as well) 7) With sub-steps at 0, hit "Bake Image Sequence" and notice that you get a dotted line 8) Now set sub-steps to 20, hit "Bake Image Sequence" and notice you get the same dotted line instead of a smooth continuous line. Here's a .blend with steps 1-7 completed: [paint_bug.blend](https://archive.blender.org/developer/F94062/paint_bug.blend)

Garrett commented

2014-06-12 23:10:44 +02:00

Changed status to: 'Open'

Garrett commented

2014-06-12 23:10:44 +02:00

Added subscriber: @Garrett-8

Fazekas Laszlo commented

2014-06-16 22:31:54 +02:00

Added subscriber: @totoro-4

Fazekas Laszlo commented

2014-06-17 07:18:42 +02:00

In blenkernel/intern/dynamicpaint.c : subframe_updateObject() tries to update only the objects related to the moving brush, ie. parents, constraint targets etc. The driver targets are not processed here yet. Also maybe ADT_RECALC_ALL needed instead of ADT_RECALC_ANIM here.

Lukas Tönne was assigned by Sergey Sharybin

2014-06-17 09:19:26 +02:00

Sergey Sharybin commented

2014-06-17 09:19:26 +02:00

Added subscribers: @LukasTonne, @miikah, @Sergey

Sergey Sharybin commented

2014-06-17 09:19:26 +02:00

@LukasTonne, maybe you'll nail the issue down real quick? It doesn't seem to be a thing with ADT_RECALC_ALL, changing this doesn't really change anything.

Also summoning @miikah here since he's an original author of the dynamic paint and might have time here to have a look.

@LukasTonne, maybe you'll nail the issue down real quick? It doesn't seem to be a thing with `ADT_RECALC_ALL`, changing this doesn't really change anything. Also summoning @miikah here since he's an original author of the dynamic paint and might have time here to have a look.

Lukas Tönne commented

2014-06-17 09:53:28 +02:00

Well, the ADT_RECALC_ALL flags do what they are supposed to do: they evaluate the drivers on every subframe. However, the problem is that the expression itself uses another object (Empty) as input var. This object is not in turn updated for every subframe, so it only gets "jumpy" full-frame transform values out of it and the driver subframes don't matter.

Can't think of a proper solution here, basically it comes down to a depsgraph problem again. The dynamic paint system would have to evaluate the depsgraph to get all the data it needs in every subframe, and the drivers would have to correctly register all dependencies (Sphere needs Empty transform to be evaluated first).

The current method of directly evaluating a single object's animdata works in the most common cases, but it easily fails when more objects get involved. We had (and still have) a similar issue with particle emitter interpolation, which also does direct anim eval and fails for driven objects etc..

Well, the `ADT_RECALC_ALL` flags do what they are supposed to do: they evaluate the drivers on every subframe. However, the problem is that the expression itself uses another object (Empty) as input `var`. This object is not in turn updated for every subframe, so it only gets "jumpy" full-frame transform values out of it and the driver subframes don't matter. Can't think of a proper solution here, basically it comes down to a depsgraph problem again. The dynamic paint system would have to evaluate the depsgraph to get all the data it needs in every subframe, and the drivers would have to correctly register all dependencies (Sphere needs Empty transform to be evaluated first). The current method of directly evaluating a single object's animdata works in the most common cases, but it easily fails when more objects get involved. We had (and still have) a similar issue with particle emitter interpolation, which also does direct anim eval and fails for driven objects etc..

Lukas Tönne commented

2014-06-17 10:08:54 +02:00

Changed status from 'Open' to: 'Archived'

Lukas Tönne closed this issue

2014-06-17 10:08:54 +02:00

Lukas Tönne commented

2014-06-17 10:08:54 +02:00

Have to put this on TODO for now. Only "solution" afaict would be doing complete scene updates for subframes, which would make dynamic paint really slow in general just to solve this driver limitation.

The depsgraph refactoring should provide a real solution eventually. In the meantime try to avoid drivers and use parenting and keyframe anim if possible.

Have to put this on TODO for now. Only "solution" afaict would be doing complete scene updates for subframes, which would make dynamic paint really slow in general just to solve this driver limitation. The depsgraph refactoring should provide a real solution eventually. In the meantime try to avoid drivers and use parenting and keyframe anim if possible.

Fazekas Laszlo commented

2014-06-17 11:04:19 +02:00

As I see it already does something with the constraint dependencies: scans the constraint list and call itself for all the target objects found. Perhaps this was the solution for the mentioned #34685 bug. It seems this function tries to replace the depsgraph with its own version... But I can imagine how complicated to do the same for all the possible drivers in the object...

Fazekas Laszlo commented

2014-06-17 11:12:14 +02:00

And by the way, I suspect this function has no protection against infinite dependency loops...
And @miikah, I think you can use copy constraint too. It's working with the null object here.

And by the way, I suspect this function has no protection against infinite dependency loops... And @miikah, I think you can use copy constraint too. It's working with the null object here.

Miika Hamalainen commented

2014-06-17 11:58:48 +02:00

@LukasTonne Yeah, definitely not worth updating whole scene over single corner case.

@totoro-4 No, I can't see how it would generate infinite loop.

Anyway, that was intended to be just a hacky solution to get subframes working somehow until there was a bit more suitable way to handle it. I guess there still isn't. IIRC it originally only updated parent objects. Then it turned out it also has to update constraints, curves, armatures etc. It's clear we need a depsgraph based solution to make it work correctly in all cases.

@LukasTonne Yeah, definitely not worth updating whole scene over single corner case. @totoro-4 No, I can't see how it would generate infinite loop. Anyway, that was intended to be just a hacky solution to get subframes working somehow until there was a bit more suitable way to handle it. I guess there still isn't. IIRC it originally only updated parent objects. Then it turned out it also has to update constraints, curves, armatures etc. It's clear we need a depsgraph based solution to make it work correctly in all cases.

Fazekas Laszlo commented

2014-06-17 14:05:04 +02:00

@miikah: sorry, I was not absolutely sure about that, but now I see you limited the recursion levels... a lot recalculations are possible but it's ok.

But is it really necessary to calculate subframes precisely? I mean this is only for the continuous lines... Is the result wrong if you just interpolate the object's position between the frames?

@miikah: sorry, I was not absolutely sure about that, but now I see you limited the recursion levels... a lot recalculations are possible but it's ok. But is it really necessary to calculate subframes precisely? I mean this is only for the continuous lines... Is the result wrong if you just interpolate the object's position between the frames?

Fazekas Laszlo commented

2014-06-17 16:20:02 +02:00

Another limitation: not interpolates between shape keys.

Perhaps the full recalculation is the solution, it is robust and since this is a bake mode the user can wait more (maybe the current algorithm is actually slower than the full recalculation in some special cases).
But I agree not to make this right before the release.

Another limitation: not interpolates between shape keys. Perhaps the full recalculation is the solution, it is robust and since this is a bake mode the user can wait more (maybe the current algorithm is actually slower than the full recalculation in some special cases). But I agree not to make this right before the release.

Miika Hamalainen commented

2014-06-17 17:24:54 +02:00

@totoro-4 It has been like that for 3 years already. I'm sure it can wait until depsgraph refactor is complete. :)

Full recalculation could be acceptable for the image sequence mode, but I would rather keep it consistent and use same system for dynamic paint as whole. Also the performance drop would bee too massive in larger scenes, where instead of having to update couple of related objects it would have to redo everything.

@totoro-4 It has been like that for 3 years already. I'm sure it can wait until depsgraph refactor is complete. :) Full recalculation *could* be acceptable for the image sequence mode, but I would rather keep it consistent and use same system for dynamic paint as whole. Also the performance drop would bee too massive in larger scenes, where instead of having to update couple of related objects it would have to redo everything.

Zach Fine commented

2022-03-25 20:28:58 +01:00

Added subscriber: @zachnfine

Zach Fine commented

2022-03-25 20:28:58 +01:00

Could we possibly get this just for baking? I'm trying to animate the burns on surfaces of a laser whose position is driven partly by a noise modifier, and it's moving too fast to leave good contiguous lines as marks. Substeps do nothing in this case.

I thought maybe as a workaround I could dupe the project, set the output time stretch to 500, bake 5x the normal amount of frames, and then I'd use ffmpeg or some other program to combine every 5 frames into 1 (or retime it to run at 500% speed with frame blending set to on, in any compositing or editing application), and then I'd have an image sequence to use with the original project that'd be roughly equivalent to that which would have been generated using substeps. But no such luck, the noise modifier seems to be frame rather than time based and doesn't respect the time stretch.

It wouldn't bother me if substeps caused the whole project to render slowly as I only need substeps set to 5 (or 20) when I'm baking the dynamic paint simulation. After that I could set it back to 0 and I'd still have the already-output baked image sequence to work with in my shader.

Could we possibly get this just for baking? I'm trying to animate the burns on surfaces of a laser whose position is driven partly by a noise modifier, and it's moving too fast to leave good contiguous lines as marks. Substeps do nothing in this case. I thought maybe as a workaround I could dupe the project, set the output time stretch to 500, bake 5x the normal amount of frames, and then I'd use ffmpeg or some other program to combine every 5 frames into 1 (or retime it to run at 500% speed with frame blending set to on, in any compositing or editing application), and then I'd have an image sequence to use with the original project that'd be roughly equivalent to that which would have been generated using substeps. But no such luck, the noise modifier seems to be frame rather than time based and doesn't respect the time stretch. It wouldn't bother me if substeps caused the whole project to render slowly as I only need substeps set to 5 (or 20) when I'm baking the dynamic paint simulation. After that I could set it back to 0 and I'd still have the already-output baked image sequence to work with in my shader.

Sergey Sharybin commented

2022-03-28 11:49:37 +02:00

This is kind of a fundamental issue of how dynamic paint is fit into the overall design and, unfortunately, there is no easy fix even if you limit the scope to just baking.

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

Dynamic paint sub-steps don't work when brush is driven #40597