Page MenuHome

Child Of vertex group fails when controled by Particle System
Confirmed, LowPublicKNOWN ISSUE


System Information
Win10 64bit

Blender Version
Broken: 2.79

Short description of error
Child Of constraint fails on rotation from PS

Exact steps for others to reproduce the error
Open file, play animation on every layer

First layer: Empty with Child Of constraint is controled by Plane's transform animation -> works OK
Second layer: Empties with Child Of are controled by Plane's Particle System (via Explode) -> Location is maintained, but rotation is non-synchronized
Third layer (example of how previous case is expected to work): Empties parented to 3 vertices are controled by same PS - OK

Event Timeline

Sorry this report hasnt been answered in quite a while.

Just to be sure:
I see a difference in layers 2 and 3:

  • for me layer 2 shows empties following face orientation (Z-axis is sticking to the facenormal correctly, but rotation around Z is sliding)
  • layer 3 shows empties with Z-axis is sticking to the facenormal correctly, and rotation around Z is not sliding

So we are talking about the (sliding around Z-Axis) rotation in layer 2, right?

Yeah, rotation sliding on Z is bothering me

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 50.

This doesnt seem to be related to a ParticleSystem in particular.
It just works well with object transformations on the target (same as your First Layer example), but not so well with object data transformations...

Here is a simpler testcase:

  • select plane, rotate in objectmode -> constraint works as expected
  • go into editmode (all verts selected), rotate them all --> constraint shows issue described above

Will check whats going on in contarget_get_mesh_mat() later, but also getting @Joshua Leung (aligorith) on board [in case this is real simple for him?]

Checked this again and atm it just averages positions and normals of participating verts.
A rotation is derived from the resulting averaged normal alone - thus not being 'stable'.

While I guess it is possible to improve the situation (at least if enough verts are actually in the group -- then by constructing a virtual tri and doing something similar to ob_parvert3?),
I would first like to check if this is considered a bug, or if should be postponed as TODO?

@Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht): opinions?
[stepping down from this for the time being... sorry this has been on my desk for so long without results...]

Brecht Van Lommel (brecht) lowered the priority of this task from 50 to Low.Apr 2 2019, 7:12 PM

Not sure about the right behavior, would consider quite low priority.

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".Jan 20 2020, 10:52 AM

A rotation is derived from the resulting averaged normal alone - thus not being 'stable'.

This is inherently limited, as there are infinitely many rotations that map one vector onto another one. As such this is a design limitation, and I'll mark this as Known Issue.

Brecht Van Lommel (brecht) changed the subtype of this task from "Bug" to "Known Issue".Jan 20 2020, 2:40 PM

I guess it was accidentally changed to the wrong subtype then.