System Information
Win7 64bit
Blender Version
Broken: 2.79
Short description of error
Motion created from modifying vgroup doesn't work with Rigid Body Simulation.
For comparison disable Vertex Weight Proximity and first Displace, but enable second Displace (with animation keyframes). It is working and I was expecting something similiar to the first case.
Exact steps for others to reproduce the error
Hit play button and nothing works.
Well it seems Vertex Weight Proximity is not the problem, another modifiers like Subsurf or Triangulation placed before second Displace also break simulation
Can confirm the behavior, unable to say if this expected behavior though. @Sergey Sharybin (sergey) ?
The issue in code i saw was related on a fake dependency cycle, which is now fixed in rB099a4104788.
Now i can open the file and there is a playback going on.
Not sure what is the intent of using empty as a source for modifier, it has no geometry component. This is something best for @Bastien Montagne (mont29) to verify. Other than that don't think i can reproduce an error.
So if there is still an issue, probably better to submit a new report with new file and exact description what's expected and what's happening.
@Bastien Montagne (mont29), If the modifier is intended to be used with Empties as well, probably best to put DEG_OB_COMP_GEOMETRY dependencies under condition? if it's not, there seems to be a way o filter Mesh objects only.
Using an empty (or center point of any object) is a valid usecase of this modifier, will check on those relations tagging.
Deg warning about DEG_OB_COMP_GEOMETRY relation is now fixed, but the rigid body simulation remains completely broken in 2.8 currently here (neither of the two displace modifiers work, only really moving red object works currently).
But same happens in 2.7?
This sounds like a feedback loop between rigid body simulation which needs geometry for the collisions, but geometry needs transform for modifier stack. While we can avoid some dependency cycles here, the order of updates might be wrong from users perspective. And the only user-controllable solution here would be to go node based.
Yes, this is indeed a chicken & egg issue (and yes, it also happens in 2.7x). Guess we can close that as known limitation for now, then.