Mesh Sequence Cache (ABC) an hair interpolated children distribution issue (triangulate modifier seem to fix it) #92561

New Issue

Carlo Andreacchio · 2021-10-28T09:55:02+02:00

Carlo Andreacchio commented

2021-10-28 09:55:02 +02:00

System Information
Operating system: Ubuntu 20.04
Graphics card: GTX 1080

Blender Version
Broken: d7b231baa8

Short description of error
When applying a Mesh Sequence Cache (ABC) to a mesh with hair, does not respect the hair correctly. Mesh Cache (PC2) Works correctly.

The PC2 reacts the way I would have expected the object to react.
Exporting to USD also experiences the same issue as ABC.

The file has a few different objects in it, one has the original hair setup. One has an armature (with simple animation). One has this and the hair on it. One has a ABC mesh sequence cache applied to it (which is the issue). and one has a PC2 mesh cache applied to it (works fine)

Aim
We want our animators to animate, without hair on the armature, as this would slow down the file and increase file size.
Once animation is ready to light / render / comp, we want to bake out the animation to ABC, apply the mesh cache to the object with hair, and render that.

Exact steps for others to reproduce the error
bug_v001.blend
untitled.abc
untitled.pc2

Download all attached blend files (Blend, ABC and PC2)
toggle the viewport visibility of the Mesh Sequence Cache modifier on and off for the ABC Mesh Cache Object.
Notice how the hair moves
Click on the PC2 Mesh cache object (to the right)
Repeat.
Notice how the hair does not move

**System Information** Operating system: Ubuntu 20.04 Graphics card: GTX 1080 **Blender Version** Broken: d7b231baa87e **Short description of error** When applying a Mesh Sequence Cache (ABC) to a mesh with hair, does not respect the hair correctly. Mesh Cache (PC2) Works correctly. The PC2 reacts the way I would have expected the object to react. Exporting to USD also experiences the same issue as ABC. The file has a few different objects in it, one has the original hair setup. One has an armature (with simple animation). One has this and the hair on it. One has a ABC mesh sequence cache applied to it (which is the issue). and one has a PC2 mesh cache applied to it (works fine) **Aim** We want our animators to animate, without hair on the armature, as this would slow down the file and increase file size. Once animation is ready to light / render / comp, we want to bake out the animation to ABC, apply the mesh cache to the object with hair, and render that. **Exact steps for others to reproduce the error** [bug_v001.blend](https://archive.blender.org/developer/F11565384/bug_v001.blend) [untitled.abc](https://archive.blender.org/developer/F11565404/untitled.abc) [untitled.pc2](https://archive.blender.org/developer/F11565405/untitled.pc2) 1. Download all attached blend files (Blend, ABC and PC2) 2. toggle the viewport visibility of the Mesh Sequence Cache modifier on and off for the ABC Mesh Cache Object. 3. Notice how the hair moves 4. Click on the PC2 Mesh cache object (to the right) 5. Repeat. 6. Notice how the hair does not move

Carlo Andreacchio commented

2021-10-28 09:55:03 +02:00

Added subscriber: @candreacchio

Carlo Andreacchio commented

2021-10-28 09:57:13 +02:00

Files:
bug_v001.blend
untitled.abc
untitled.pc2

These are all relatively mapped, so put them all in the same folder!

Files: [bug_v001.blend](https://archive.blender.org/developer/F11565384/bug_v001.blend) [untitled.abc](https://archive.blender.org/developer/F11565404/untitled.abc) [untitled.pc2](https://archive.blender.org/developer/F11565405/untitled.pc2) These are all relatively mapped, so put them all in the same folder!

Richard Antalik commented

2021-10-29 11:41:42 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Sybren A. Stüvel commented

2021-11-01 12:19:50 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2021-11-01 12:19:50 +01:00

The mesh cache only deals with mesh data, so the importer doesn't produce curves. ABC & USD try to import hair as curves; however, this is not properly supported by Blender's modifier system. The Alembic importer in Blender 2.79 hacked around this by doing things that were banned in 2.80. To fix this properly, modifiers need to be able to output more than just mesh data. This work is tracked in #51311, and may gain some traction once Blender has a new hair object.

Yegor commented

2021-11-01 18:38:48 +01:00

Added subscriber: @YegorSmirnov

Yegor commented

2021-11-01 18:38:48 +01:00

Hm, I don't see the problem?2021-11-01_20-37-40.mp4

Hm, I don't see the problem?[2021-11-01_20-37-40.mp4](https://archive.blender.org/developer/F11662964/2021-11-01_20-37-40.mp4)

Carlo Andreacchio commented

2021-11-01 21:59:03 +01:00

In #92561#1245563, @dr.sybren wrote:
The mesh cache only deals with mesh data, so the importer doesn't produce curves. ABC & USD try to import hair as curves; however, this is not properly supported by Blender's modifier system. The Alembic importer in Blender 2.79 hacked around this by doing things that were banned in 2.80. To fix this properly, modifiers need to be able to output more than just mesh data. This work is tracked in #51311, and may gain some traction once Blender has a new hair object.

Hi @dr.sybren ,

I am not trying to bake out the curve data into the ABC file. i am only trying to bake out the mesh data. as in:

Animator animate on rig without hair
TD Bakes out animation from animator to ABC
TD applies the ABC mesh data to the mesh with hair

As in, I am trying ot use ABC, exactly like PC2. No data of hair to be stored in the ABC file.

> In #92561#1245563, @dr.sybren wrote: > The mesh cache only deals with mesh data, so the importer doesn't produce curves. ABC & USD try to import hair as curves; however, this is not properly supported by Blender's modifier system. The Alembic importer in Blender 2.79 hacked around this by doing things that were banned in 2.80. To fix this properly, modifiers need to be able to output more than just mesh data. This work is tracked in #51311, and may gain some traction once Blender has a new hair object. Hi @dr.sybren , I am not trying to bake out the curve data into the ABC file. i am only trying to bake out the mesh data. as in: - Animator animate on rig without hair - TD Bakes out animation from animator to ABC - TD applies the ABC mesh data to the mesh with hair As in, I am trying ot use ABC, exactly like PC2. No data of hair to be stored in the ABC file.

Carlo Andreacchio commented

2021-11-01 22:00:04 +01:00

In #92561#1245947, @YegorSmirnov wrote:
Hm, I don't see the problem?2021-11-01_20-37-40.mp4

Hey Yegor.

If you keep it on the frame when the file opens, and toggle the modifier on and off, you should see that the hair shifts around.

This is a test file, however on our production file, the hair on our creature is going beneath its skin, giving a 'patchy' look and not respecting how we have groomed it.

> In #92561#1245947, @YegorSmirnov wrote: > Hm, I don't see the problem?[2021-11-01_20-37-40.mp4](https://archive.blender.org/developer/F11662964/2021-11-01_20-37-40.mp4) Hey Yegor. If you keep it on the frame when the file opens, and toggle the modifier on and off, you should see that the hair shifts around. This is a test file, however on our production file, the hair on our creature is going beneath its skin, giving a 'patchy' look and not respecting how we have groomed it.

Philipp Oeser commented

2021-11-05 10:11:32 +01:00

Added subscribers: @brecht, @lichtwerk

Philipp Oeser commented

2021-11-05 10:11:32 +01:00

I can confirm as well.

@dr.sybren : this is about the hair system (interpolated children distribution) behaving awkward on a ABC driven mesh (not about real curves in ABC).

Couple of notes:

This only happens with interpolated children
Reminds me of #56408 (Hair interpolated children recalculation on every frame when attached onto an alembic imported mesh) (issues with distribution code explained)
I think the distribution is not even the same on Original Hair Setup & Armature with Hair in restpose (they should, but if you look closely I think they arent)
True, even though mesh with ABC applied seems to be exactly the same as the orig mesh in terms of coordinates (think it also should since ee8aad79c1), dristribution is not the same

Maybe @brecht can let us know if the distribution code of interpolated children is just in the status of a Known Issue?

That being said, there is one possible way to get consistent output throughout the pipeline (at least as far as I can tell) -- so Original Hair Setup, Armature with Hair & ABC Mesh Cache With Hair could all look the same:

Use a Triangulate modifier before the particle system in each step of the pipeline
Enable Use modifier stack on the particle system
(You'd probably have to adjust grooms on existing Hair Setups [slightly] to compensate unfortunately)

bug_v001_triangulate_use_modifier_stack.blend

The usage of the triangulate modifier also reminds me of #91777 (Mesh is not being deformated correctly via Mesh Deform Modifier (quads, tris behave better)) (which is nice to know in itself)

I can confirm as well. @dr.sybren : this is about the hair system (interpolated children distribution) behaving awkward on a ABC driven mesh (not about real curves in ABC). Couple of notes: - This only happens with interpolated children - Reminds me of #56408 (Hair interpolated children recalculation on every frame when attached onto an alembic imported mesh) (issues with distribution code explained) - I think the distribution is not even the same on `Original Hair Setup` & `Armature with Hair` in restpose (they should, but if you look closely I think they arent) - True, even though mesh with ABC applied seems to be exactly the same as the orig mesh in terms of coordinates (think it also should since ee8aad79c1), dristribution is not the same Maybe @brecht can let us know if the distribution code of interpolated children is just in the status of a `Known Issue`? That being said, there is one possible way to get consistent output throughout the pipeline (at least as far as I can tell) -- so `Original Hair Setup`, `Armature with Hair` & `ABC Mesh Cache With Hair` could all look the same: - Use a `Triangulate` modifier before the particle system in each step of the pipeline - Enable `Use modifier stack` on the particle system - (You'd probably have to adjust grooms on existing Hair Setups [slightly] to compensate unfortunately) [bug_v001_triangulate_use_modifier_stack.blend](https://archive.blender.org/developer/F11727422/bug_v001_triangulate_use_modifier_stack.blend) The usage of the triangulate modifier also reminds me of #91777 (Mesh is not being deformated correctly via Mesh Deform Modifier (quads, tris behave better)) (which is nice to know in itself)

Philipp Oeser changed title from ~~Blender 3.0 - Mesh Sequence Cache (ABC) does not work correctly with hair~~ to Mesh Sequence Cache (ABC) an hair interpolated children distribution issue (triangulate modifier seem to fix it)

2021-11-05 10:12:39 +01:00

Philipp Oeser commented

2021-11-05 10:20:10 +01:00

Note this will probably all change for the better with #68981 (New curves object type)

Brecht Van Lommel commented

2021-11-09 13:58:56 +01:00

I don't think this is a known issue. As far as I know as long as the mesh topology coming from the Alembic file is stable, and the fix from ee8aad79c1 to keep stable original coordinates is giving stable ORCO, then the child particle distribution should remain stable too,

Why it's failing in this file is not immediately clear to me, needs some deeper investigation.

I don't think this is a known issue. As far as I know as long as the mesh topology coming from the Alembic file is stable, and the fix from ee8aad79c1 to keep stable original coordinates is giving stable ORCO, then the child particle distribution should remain stable too, Why it's failing in this file is not immediately clear to me, needs some deeper investigation.

Carlo Andreacchio commented

2021-11-10 02:19:05 +01:00

Just to clarify, this has happened in a more prominent way on a production scene. The scene provided is myself recreating the issue to give an example of what is going wrong, and not the worst case of it.

Sybren A. Stüvel commented

2021-11-11 11:27:05 +01:00

Is this something that was recently introduced? Did it ever work well for you @candreacchio in older versions of Blender?

Carlo Andreacchio commented

2021-11-11 11:36:21 +01:00

i can test this weekend if it would be useful. but no this is the first time we are trying it with hair.

Philipp Oeser commented

2021-11-11 11:48:04 +01:00

2.80 introduced the jump on enabling the modifier, in 2.79, you can enable/disable without the jump:
bug_v001_279.blend
(but then again in 2.79 the distribution never really looks the same, so Original Hair Setup, Armature with Hair & ABC Mesh Cache With Hair all look [slightly] different -- and in 2.79, the triangulate modifier workaround does not seem to help)

2.80 introduced the jump on enabling the modifier, in 2.79, you can enable/disable without the jump: [bug_v001_279.blend](https://archive.blender.org/developer/F11793443/bug_v001_279.blend) (but then again in 2.79 the distribution never really looks the same, so `Original Hair Setup`, `Armature with Hair` & `ABC Mesh Cache With Hair` all look [slightly] different -- and in 2.79, the triangulate modifier workaround does not seem to help)

Kévin Dietrich commented

2021-11-16 00:55:02 +01:00

Added subscriber: @kevindietrich

Kévin Dietrich commented

2021-11-16 00:55:02 +01:00

After some investigation the problem appears to be that the ORCOs as expected by the particle system have to be in the 0...1 range, at least this is what the particle system is using to create & store ORCOs when none exist on the Mesh (see https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/particle_distribute.c$1000). However, the ORCOs as read from Alembic or as generated via MOD_deform_mesh_eval_get are not normalized.

This little patch fixes the issue:

diff --git a/source/blender/modifiers/intern/MOD_util.c b/source/blender/modifiers/intern/MOD_util.c
index d57e92b4b35..514ffde3683 100644
--- a/source/blender/modifiers/intern/MOD_util.c
+++ b/source/blender/modifiers/intern/MOD_util.c
@@ -219,8 +219,9 @@ Mesh *MOD_deform_mesh_eval_get(Object *ob,
     }
 
     if (use_orco) {
-      CustomData_add_layer(
-          &mesh->vdata, CD_ORCO, CD_ASSIGN, BKE_mesh_orco_verts_get(ob), mesh->totvert);
+      float(*orcodata)[3] = BKE_mesh_orco_verts_get(ob);
+      BKE_mesh_orco_verts_transform(mesh, orcodata, mesh->totvert, false);
+      CustomData_add_layer(&mesh->vdata, CD_ORCO, CD_ASSIGN, orcodata, mesh->totvert);
     }
   }
   else if (ELEM(ob->type, OB_FONT, OB_CURVE, OB_SURF)) {

So, if all ORCOs should be stored in 0...1 range, then I can make a patch to ensure that all areas (like Alembic, USD, etc.) are also outputting normalized ORCOs.

But also, it seems like the code in MOD_deform_mesh_eval_get is ignoring a potential CD_ORCO layer on the mesh? At least one should be read from the Alembic file but it is never used.

After some investigation the problem appears to be that the ORCOs as expected by the particle system have to be in the 0...1 range, at least this is what the particle system is using to create & store ORCOs when none exist on the Mesh (see https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/particle_distribute.c$1000). However, the ORCOs as read from Alembic or as generated via `MOD_deform_mesh_eval_get` are not normalized. This little patch fixes the issue: ``` diff --git a/source/blender/modifiers/intern/MOD_util.c b/source/blender/modifiers/intern/MOD_util.c index d57e92b4b35..514ffde3683 100644 --- a/source/blender/modifiers/intern/MOD_util.c +++ b/source/blender/modifiers/intern/MOD_util.c @@ -219,8 +219,9 @@ Mesh *MOD_deform_mesh_eval_get(Object *ob, } if (use_orco) { - CustomData_add_layer( - &mesh->vdata, CD_ORCO, CD_ASSIGN, BKE_mesh_orco_verts_get(ob), mesh->totvert); + float(*orcodata)[3] = BKE_mesh_orco_verts_get(ob); + BKE_mesh_orco_verts_transform(mesh, orcodata, mesh->totvert, false); + CustomData_add_layer(&mesh->vdata, CD_ORCO, CD_ASSIGN, orcodata, mesh->totvert); } } else if (ELEM(ob->type, OB_FONT, OB_CURVE, OB_SURF)) { ``` So, if all ORCOs should be stored in 0...1 range, then I can make a patch to ensure that all areas (like Alembic, USD, etc.) are also outputting normalized ORCOs. But also, it seems like the code in `MOD_deform_mesh_eval_get` is ignoring a potential CD_ORCO layer on the mesh? At least one should be read from the Alembic file but it is never used.

Anton Raves commented

2021-11-16 08:01:41 +01:00

Added subscriber: @Memento

Anton Raves commented

2021-11-16 08:01:45 +01:00

Removed subscriber: @Memento

Sybren A. Stüvel commented

2021-11-16 11:49:10 +01:00

Maybe @brecht knows more about how ORCOs should be stored? Also I find it strange that, if ORCOs should always be stored normalized, that they aren't normal when they're read from Alembic -- after all, they should have already been normal when they were written.

Brecht Van Lommel commented

2021-11-16 15:42:06 +01:00

They are currently stored normalized. I'd actually like to change that to not be the case, but it's not a trivial change.

In other applications this is often called Pref (P for position, and ref for reference like a a reference pose in rigging). So for interop, I think it would be best to read/write orcos as an unnormalized Pref attribute in Alembic and USD. That could be done without changing how it's stored internally.

They are currently stored normalized. I'd actually like to change that to not be the case, but it's not a trivial change. In other applications this is often called `Pref` (`P` for position, and `ref` for reference like a a reference pose in rigging). So for interop, I think it would be best to read/write orcos as an unnormalized `Pref` attribute in Alembic and USD. That could be done without changing how it's stored internally.

blender-admin commented

2021-11-22 12:04:37 +01:00

This issue was referenced by 77694b571f

This issue was referenced by 77694b571f5bd297ea7228b30f591ebbd333e0ea

blender-admin commented

2021-11-22 12:04:37 +01:00

This issue was referenced by 02ab4ad991

This issue was referenced by 02ab4ad991906f817698d3810c3d464cfaedcaff

Carlo Andreacchio commented

2021-11-24 22:14:47 +01:00

Will this be committed for the next blender release?