Slow Parent option doesn't work with new Depsgraph #55026

New Issue

Evandro Costa · 2018-05-10T17:34:41+02:00

Evandro Costa commented

2018-05-10 17:34:41 +02:00

System Information
Windows 10, GTX780

Blender Version
Broken: 2.79 5bd8ac9 with --enable-new-depsgraph
Worked: 2.79 5bd8ac9 with old depsgraph

Short description of error
Using Blender 2.79 with new Depsgraph activated on launch makes the Relations Extras option "Slow Parent" stop working. The "Offset" parameter to determine how many frames of delay the parent relationship will have simply have no effect at all, and the Child object will follow without any delay at all.

Exact steps for others to reproduce the error
Open 2.79 using a bat file with steps to enable New Depsgraph (look online for instructions). Create two objects, parent one to another, and set the Child object to have a Slow Parent under the Relations Extras section of the Object Data tab. Set an Offset value that is greater than 1 and move the parent object around. You should see the Child object move delayed in relation to it's parent (do the same steps on 2.79 default launch), but this doesn't work with New Depsgraph activated.

I'm aware that blender 2.8 will work based on this/a new Depsgraph also... therefore I think it's important to make sure that the reason the Slow Parent stops working under the new Depsgraph is known, so that on 2.8 this problem doesn't persist.
This Slow parenting option is very useful for certain cases where one would need to do transformations to the Child position in it's Local Space using a Constraint for example. If you use Drivers instead to emulate Slow Parent, the constraints are kind of ignored because Drivers have priority over constraints I think.

slowparent.blend
Edit: Sample (working) file uploaded. Use the "--enable-new-depsgraph" command on a new blender instance to see that the slow parenting option breaks.

**System Information** Windows 10, GTX780 **Blender Version** Broken: 2.79 5bd8ac9 with --enable-new-depsgraph Worked: 2.79 5bd8ac9 with old depsgraph **Short description of error** Using Blender 2.79 with new Depsgraph activated on launch makes the Relations Extras option "Slow Parent" stop working. The "Offset" parameter to determine how many frames of delay the parent relationship will have simply have no effect at all, and the Child object will follow without any delay at all. **Exact steps for others to reproduce the error** Open 2.79 using a bat file with steps to enable New Depsgraph (look online for instructions). Create two objects, parent one to another, and set the Child object to have a Slow Parent under the Relations Extras section of the Object Data tab. Set an Offset value that is greater than 1 and move the parent object around. You should see the Child object move delayed in relation to it's parent (do the same steps on 2.79 default launch), but this doesn't work with New Depsgraph activated. **I'm aware that blender 2.8 will work based on this/a new Depsgraph also... therefore I think it's important to make sure that the reason the Slow Parent stops working under the new Depsgraph is known, so that on 2.8 this problem doesn't persist.** This Slow parenting option is very useful for certain cases where one would need to do transformations to the Child position in it's Local Space using a Constraint for example. If you use Drivers instead to emulate Slow Parent, the constraints are kind of ignored because Drivers have priority over constraints I think. [slowparent.blend](https://archive.blender.org/developer/F3333196/slowparent.blend) Edit: Sample (working) file uploaded. Use the "--enable-new-depsgraph" command on a new blender instance to see that the slow parenting option breaks.

Evandro Costa commented

2018-05-10 17:34:41 +02:00

Added subscriber: @EvandroFerreiradaCosta

Philipp Oeser commented

2018-05-11 15:09:53 +02:00

Added subscribers: @Sergey, @JoshuaLeung, @lichtwerk

Philipp Oeser commented

2018-05-11 15:09:53 +02:00

Changed status from 'Open' to: 'Archived'

Philipp Oeser closed this issue

2018-05-11 15:09:53 +02:00

Philipp Oeser self-assigned this 2018-05-11 15:09:53 +02:00

Philipp Oeser commented

2018-05-11 15:09:53 +02:00

Pretty sure "slow parent" wont come back. There are a couple of comments in code that give an idea:

/* slow parenting /
/ XXX: evil old crap */

New codepath (new depsgraph) simply ignores this.

old route:
BKE_object_where_is_calc_time_ex() and therefor solve_parenting() and therefor where_is_object_parslow()

new depsgraph:
BKE_object_eval_parent()

note the comment for BKE_object_eval_parent() as well

/* Evaluate parent /
/ NOTE: based on solve_parenting(), but with the cruft stripped out */

Also quoting @JoshuaLeung from here:

"slow parent", etc. etc. things were all the various heads of the multi-headed "time" beast. Data was getting calculated, and recalculated multiple times as a result of this, and really, it meant that it was never clear exactly what time each piece of data was displaying its state for.

@EvandroFerreiradaCosta: If you have trouble setting up an alternative to this, please ask around in stackexchange or similar (or even here if there is a bug involved)

But, I dare to archive this, unless @JoshuaLeung or @Sergey have something to add?

Pretty sure "slow parent" wont come back. There are a couple of comments in code that give an idea: > /* slow parenting */ > /* XXX: evil old crap */ New codepath (new depsgraph) simply ignores this. old route: `BKE_object_where_is_calc_time_ex()` and therefor `solve_parenting()` and therefor `where_is_object_parslow()` new depsgraph: `BKE_object_eval_parent()` note the comment for `BKE_object_eval_parent()` as well > /* Evaluate parent */ > /* NOTE: based on solve_parenting(), but with the cruft stripped out */ Also quoting @JoshuaLeung from [here: ](https://wiki.blender.org/index.php/User:Aligorith/Depsgraph_Limitations) > "slow parent", etc. etc. things were all the various heads of the multi-headed "time" beast. Data was getting calculated, and recalculated multiple times as a result of this, and really, it meant that it was never clear exactly what time each piece of data was displaying its state for. @EvandroFerreiradaCosta: If you have trouble setting up an alternative to this, please ask around in stackexchange or similar (or even here if there is a bug involved) But, I dare to archive this, unless @JoshuaLeung or @Sergey have something to add?

fra are commented

2019-01-17 10:40:53 +01:00

Added subscriber: @FrancescoArena

fra are commented

2019-01-17 10:40:53 +01:00

hi, with blender 2.80.41 date: 2019-01-16 21:59, hash: e57ee5934a the error persists (win8.1).
we must wait for the new depsgraph to fix this problem or I misunderstood?

hi, with blender 2.80.41 date: 2019-01-16 21:59, hash: e57ee5934a30 the error persists (win8.1). we must wait for the new depsgraph to fix this problem or I misunderstood?

Philipp Oeser commented

2019-01-17 10:46:54 +01:00

I can try to give @Sergey another poke to share thoughts on this, but still pretty sure this wont come back.
Actually, I am pretty sure this thing could be removed in 2.8 [since old depsgraph is gone]?

I can try to give @Sergey another poke to share thoughts on this, but still pretty sure this wont come back. Actually, I am pretty sure this thing could be removed in 2.8 [since old depsgraph is gone]?

Sergey Sharybin commented

2019-01-18 12:46:39 +01:00

I personally find the old behavior rather unpredictable, hard to work with and unreliable. Here are just some notes:

Slow parent doesn't handle situation correctly when parent depends on an animated object.
The way slow parent is implemented is not thread safe. It works in simple cases, but once parent is also used for something else the evaluation will become unpredictable.
Changing current frame of the scene gives different results, depending on from which frame user came from (rather, what was the entire history of changing frames).
Tools will have weird affect on the children (try to change frame in the attached file and then rotate the child object).
Implementation is not compatible with motion blur.

The latter one has same roots as compatibility with Copy-on-Write environment which is default in 2.8 and brings a lot of other possibilities (as in, we can not go away from CoW, or make it optional).

I wouldn't mind if this feature was properly implemented, but there is still some group work to be finished first. For until then i would prefer to have the option removed from the interface and commented out in the code (or even removed, since it will be re-implemented in a different way anyway).

I personally find the old behavior rather unpredictable, hard to work with and unreliable. Here are just some notes: - Slow parent doesn't handle situation correctly when parent depends on an animated object. - The way slow parent is implemented is not thread safe. It works in simple cases, but once parent is also used for something else the evaluation will become unpredictable. - Changing current frame of the scene gives different results, depending on from which frame user came from (rather, what was the entire history of changing frames). - Tools will have weird affect on the children (try to change frame in the attached file and then rotate the child object). - Implementation is not compatible with motion blur. The latter one has same roots as compatibility with Copy-on-Write environment which is default in 2.8 and brings a lot of other possibilities (as in, we can not go away from CoW, or make it optional). I wouldn't mind if this feature was properly implemented, but there is still some group work to be finished first. For until then i would prefer to have the option removed from the interface and commented out in the code (or even removed, since it will be re-implemented in a different way anyway).

Metin Seven commented

2019-03-22 18:36:48 +01:00

Added subscriber: @MetinSeven-1

Metin Seven commented

2019-03-22 18:36:48 +01:00

Hi,

If Slow Parent has been removed, is there an easy other way to establish the delay effect for children, driven by one object?

Thanks,

Metin

Hi, If Slow Parent has been removed, is there an easy other way to establish the delay effect for children, driven by one object? Thanks, Metin

softyoda commented

2019-04-15 16:35:08 +02:00

Added subscriber: @softyoda

softyoda commented

2019-04-15 16:35:08 +02:00

Hello, I would be disappointed to know that the slow parent would probably not be present in the new version of blender, indeed, although originally it was used a lot for cameras on the BGE, it still remains very useful in some cases, such as here, or I try to animate a car with hydraulic suspensions that react to the animated terrain.

Here is a GIF of the technique used under blender 2.79 (excuse the beauty of the modeling, it's a demonstration) :

If you want to know the technique, here is the tutorial in picture

You can maby implement in another option, maybe a slow parent node in animation node?

Hello, I would be disappointed to know that the slow parent would probably not be present in the new version of blender, indeed, although originally it was used a lot for cameras on the BGE, it still remains very useful in some cases, such as here, or I try to animate a car with hydraulic suspensions that react to the animated terrain. Here is a [GIF ](https://dev-files.blender.org/file/data/uh7gsl5pp54tdsq6rb3x/PHID-FILE-aotbenywo6l5rb74wx5y/test.gif) of the technique used under blender 2.79 (excuse the beauty of the modeling, it's a demonstration) : ![test.gif](https://archive.blender.org/developer/F6948176/test.gif) If you want to know the technique, here is the tutorial in picture ![tuto.jpg](https://archive.blender.org/developer/F6948234/tuto.jpg) You can maby implement in another option, maybe a slow parent node in animation node?

Evandro Costa commented

2019-04-15 22:18:52 +02:00

is there an easy other way to establish the delay effect for children, driven by one object?

As far as I know, on 2.79 you had another option, which is not so easy...using python scripts or scripted expressions on drivers... I was really interested in this stuff a couple years back:

Check Rich Sedman answer here:
https://blender.stackexchange.com/questions/61780/moving-objects-create-wind/61804#61804
Or Leander answer here:
https://blender.stackexchange.com/questions/106612/while-loop-drivers-and-additive-movement
Or Rich Sedman's example here:
https://blender.stackexchange.com/questions/108373/adding-a-delay-for-a-driver

None are as easy as using Slow Parent though.

> is there an easy other way to establish the delay effect for children, driven by one object? As far as I know, on 2.79 you had another option, which is not so easy...using python scripts or scripted expressions on drivers... I was really interested in this stuff a couple years back: Check Rich Sedman answer here: https://blender.stackexchange.com/questions/61780/moving-objects-create-wind/61804#61804 Or Leander answer here: https://blender.stackexchange.com/questions/106612/while-loop-drivers-and-additive-movement Or Rich Sedman's example here: https://blender.stackexchange.com/questions/108373/adding-a-delay-for-a-driver None are as easy as using Slow Parent though.

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

Slow Parent option doesn't work with new Depsgraph #55026