Child Of vertex group fails when controled by Particle System #54108

New Issue

Serge Lyatin · 2018-02-20T17:29:32+01:00

Serge Lyatin commented

2018-02-20 17:29:32 +01:00

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
Child_Of_test.blend

**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 [Child_Of_test.blend](https://archive.blender.org/developer/F2327792/Child_Of_test.blend)

Serge Lyatin commented

2018-02-20 17:29:32 +01:00

Added subscriber: @SergeL

Philipp Oeser commented

2018-04-27 09:50:45 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-04-27 09:50:45 +02:00

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?

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?

Serge Lyatin commented

2018-04-27 10:00:04 +02:00

Yeah, rotation sliding on Z is bothering me

Philipp Oeser commented

2018-04-27 10:32:22 +02:00

OK, will have a look

Philipp Oeser self-assigned this 2018-04-27 16:11:38 +02:00

Philipp Oeser commented

2018-04-27 16:11:38 +02:00

Added subscriber: @JoshuaLeung

Philipp Oeser commented

2018-04-27 16:11:38 +02:00

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:
Child_Of_test_simpler.blend

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 @JoshuaLeung on board [in case this is real simple for him?]

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: [Child_Of_test_simpler.blend](https://archive.blender.org/developer/F3060297/Child_Of_test_simpler.blend) - 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() ](https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/constraint.c;57405054b21ccc3a1aee3ab8bcae66cf8f7ca5fb$544) later, but also getting @JoshuaLeung on board [in case this is real simple for him?]

Philipp Oeser removed their assignment 2019-03-28 20:52:29 +01:00

Philipp Oeser commented

2019-03-28 20:52:29 +01:00

Added subscribers: @ideasman42, @brecht

Philipp Oeser commented

2019-03-28 20:52:29 +01:00

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?

@ideasman42, @brecht: opinions?
[stepping down from this for the time being... sorry this has been on my desk for so long without results...]

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? @ideasman42, @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 commented

2019-04-02 19:12:42 +02:00

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

Sybren A. Stüvel commented

2020-01-20 10:52:07 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-01-20 10:52:07 +01:00

In #54108#650572, @lichtwerk wrote:
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.

> In #54108#650572, @lichtwerk wrote: > 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 commented

2020-01-20 14:40:12 +01:00

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

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

Child Of vertex group fails when controled by Particle System #54108