Regression: Wrong orientation on shrinkwrap constrained instanced collection #119992

New Issue

Robert S · 2024-03-28T00:18:06+01:00

Robert S commented

2024-03-28 00:18:06 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.23

Blender Version
Broken: version: 4.1.0, branch: blender-v4.1-release, commit date: 2024-03-25 20:42, hash: 40a5e739e270
Worked: 4.0.2

Short description of error
To my knowledge, the only way to make part of a sphere using simple deform is to first rotate the original object in the manner shown in the attached example. However, any shrink wrapped constrained instance placed on that spherical object gets the wrong orientation in 4.1.

Exact steps for others to reproduce the error

Open the attached example
The cone is shrinkwrap constrained onto the curved surface.
In 4.0, the cone is upright, but in 4.1, the cone is sideways.

Expected: Cone points upright

Result: Cone is pointing sideways.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.23 **Blender Version** Broken: version: 4.1.0, branch: blender-v4.1-release, commit date: 2024-03-25 20:42, hash: `40a5e739e270` Worked: 4.0.2 **Short description of error** To my knowledge, the only way to make part of a sphere using simple deform is to first rotate the original object in the manner shown in the attached example. However, any shrink wrapped constrained instance placed on that spherical object gets the wrong orientation in 4.1. **Exact steps for others to reproduce the error** 1. Open the attached example 2. The cone is shrinkwrap constrained onto the curved surface. 3. In 4.0, the cone is upright, but in 4.1, the cone is sideways. Expected: Cone points upright Result: Cone is pointing sideways.

hmm.blend

979 KiB

Robert S added the

labels 2024-03-28 00:18:06 +01:00

YimingWu commented

2024-03-28 04:08:39 +01:00

Can confirm the difference between 4.0 and 4.1/4.2.

Working: 4.0.3 63e9cead5f, broken: 4.1 ea7c0a4a46

Can confirm the difference between 4.0 and 4.1/4.2. Working: 4.0.3 63e9cead5ff0, broken: 4.1 ea7c0a4a46a8

YimingWu added

and removed

labels 2024-03-28 04:08:59 +01:00

Iliya Katushenock added

and removed

labels 2024-03-28 07:51:30 +01:00

Philipp Oeser commented

2024-03-28 08:49:58 +01:00

Running a bisect...

YimingWu commented

2024-03-28 09:20:55 +01:00

Broken by aca27e5462 @HooglyBoogly

Broken by aca27e5462fc814148338cc5fc1cc736c54 @HooglyBoogly

Philipp Oeser commented

2024-03-28 10:26:47 +01:00

Cones are getting upright when the object is Shade Smooth.

It might very well be that the reported is actually the intended behavior (which feels a little strange, but at least it used to behave like that for ages).

Then came along 5876573e14 which seems to have had a mistake :

CustomData_get_layer_named(&mesh->edata, CD_PROP_BOOL, "sharp_face"))

it gets sharp_face from the edge domain [which I believe is never found] -- so code would from 5876573e14 onwards always go into the codebranch of

/* Interpolate smooth normals if enabled. */

and never into the branch of

/* Use the face normal if flat. */

Now aca27e5462 somewhat corrected the situation again (since it changed the domain from mesh->edge_data to mesh->face_data again when getting sharp_face), so now we are entering the "Use the face normal if flat" branch again.

Cant really comment (yet) on the fact that "proper" flat facenormals seem to give such an unexpected shrinkwrap result (to me it seems the cones should stay upright), but at least these are my findings regarding code history.

Cones are getting upright when the object is `Shade Smooth`. It might very well be that the reported is actually the intended behavior (which feels a little strange, but at least it used to behave like that for ages). Then came along 5876573e14f4 which seems to have had a mistake : `CustomData_get_layer_named(&mesh->edata, CD_PROP_BOOL, "sharp_face"))` it gets `sharp_face` from the edge domain [which I believe is never found] -- so code would from 5876573e14f4 onwards always go into the codebranch of `/* Interpolate smooth normals if enabled. */` and never into the branch of `/* Use the face normal if flat. */` Now aca27e5462 somewhat corrected the situation again (since it changed the domain from `mesh->edge_data` to `mesh->face_data` again when getting `sharp_face`), so now we are entering the "Use the face normal if flat" branch again. Cant really comment (yet) on the fact that "proper" flat facenormals seem to give such an unexpected shrinkwrap result (to me it seems the cones should stay upright), but at least these are my findings regarding code history.

Hans Goudey self-assigned this 2024-03-28 16:11:08 +01:00

Hans Goudey commented

2024-03-28 16:29:07 +01:00

Thanks for the investigation @lichtwerk. Looks like the transform was always ignored for face normals since b4b224dc08. (Note the missing BLI_space_transform_invert_normal for that case).

Thanks for the investigation @lichtwerk. Looks like the transform was always ignored for face normals since b4b224dc083c0e490eebc5c98646d791a41b8563. (Note the missing `BLI_space_transform_invert_normal` for that case).

👍 1

Hans Goudey referenced this issue from a commit

2024-03-28 18:45:33 +01:00

Fix #119992: Object transform ignored for shrinkwrap and flat shading

Hans Goudey closed this issue

2024-03-28 18:45:34 +01:00

Blender Bot added

and removed