Page MenuHome

Slow Parent option doesn't work with new Depsgraph
Closed, ArchivedPublic


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.

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



Event Timeline

Philipp Oeser (lichtwerk) closed this task as Archived.May 11 2018, 3:09 PM
Philipp Oeser (lichtwerk) claimed this task.

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:

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 @Joshua Leung (aligorith) 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.

@Evandro Costa (Arkhangels): 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 @Joshua Leung (aligorith) or @Sergey Sharybin (sergey) have something to add?

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?

I can try to give @Sergey Sharybin (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 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).


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



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?

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:
Or Leander answer here:
Or Rich Sedman's example here:

None are as easy as using Slow Parent though.