Fix the gizmo position when the Subdivision Surface modifier is set to 'On Cage'
80%
Development Status:
Open
Upvote4Downvote1
z
zy
2 Apr 2026
5 Comments
p
pxy-gnomes
I believe this issue also affects the 3D Cursor: if we want to Set it to a Selection... it gets a terrible, often useless Offset (unfortunately). If anyone knows how to use that behavior in favor of 3D artwork-making, please tell me urgently! because I strongly suspect it's 90% detrimental in most case scenarios...!😹
Now... What about a 'Doppelganger' 3D Cursor for such cases? So, the user would be able to know the Position of the original element as well as the Modified element; However, I don't think Gizmos would benefit from such approach... maybe?
1
k
khellstr
Quite likely impossible.
It would be possible to place the gizmo on the subdivided mesh, in the correct place. But if you then tried to use that gizmo to modify the base mesh, it would cause a dependency loop.
To place the gizmo to the correct place, you have to calculate the mesh, but if you use that same gizmo to edit the mesh, you can't calculate that mesh before you make the edits.
1
p
pxy-gnomes
But I'm sure there should be smart ways to solve that kind of issue in Development.
For example, in Rigging inside Blender, in the domain of the Custom Shapes / Widgets, there is the "Override Transform" (Bone Target) Option.
The 'literature' and experience in Rigging indicates, that feature is capable of mimicking the solvation of paradoxical issues of Rigging such as, precisely, Dependency Cycles/Loops. The Widget of a Bone "Parent", gets 'glued' to a Target Bone "Child"; then, as we might still be able to Pose the Parent Bone with the Widget, it is possible that some of its "Visual" Transforms are presented in the 3D Viewport Editor, equivalent to the Child Bone (if we give it different, independent Automations). It would look like the Child is actively Transforming its own Parent in a plausible Dependency Cycle; but only the Widget (which might be an analogue to a Gizmo), representative of the Parent Bone, but actually, of the 'Modified' Parent Bone, is appearing in a Modified fashion, as the real stuff (the Parent Bone) is not Transforming at all from its Child, of course.
Then, lately, Blender added additional features (2 Options), to the Transform Override system: "Affect Gizmo" and "Use As Pivot"; these implementations are very interesting, but it's a bit hard to understand without a real cause or if one has never needed such a feature before. It's sort of a spontaneous way of forcing changing of the "Space", when Posing an affected Widget, without the user needing to change Pose Options, such as 3D Cursor Transform Pivot Point everytime for example.
All of these, I believe might be close enough to the Gizmo issue; if true, that would mean, Blender team already has some sort of blueprint or design strategy for a plausible solution.
1
A
AcideRominé
A buffer could avoid the dependency cycle but I guess it introduces a lot of new issues. I don't know if someone with more knowledge can confirm...
b
bestelix
This and many other issues could be resolved with something like a snapshot modifier.
In 3ds max is called "Edit poly" and flattens the stack before it to a new editable geometry. This allows for nondestructive mesh edit to a level impossible yet in blender.
The geometry nodes cache or conversions do not work either in edit mode.
5 Comments
I believe this issue also affects the 3D Cursor: if we want to Set it to a Selection... it gets a terrible, often useless Offset (unfortunately). If anyone knows how to use that behavior in favor of 3D artwork-making, please tell me urgently! because I strongly suspect it's 90% detrimental in most case scenarios...!😹
Now... What about a 'Doppelganger' 3D Cursor for such cases? So, the user would be able to know the Position of the original element as well as the Modified element; However, I don't think Gizmos would benefit from such approach... maybe?
Quite likely impossible.
It would be possible to place the gizmo on the subdivided mesh, in the correct place. But if you then tried to use that gizmo to modify the base mesh, it would cause a dependency loop.
To place the gizmo to the correct place, you have to calculate the mesh, but if you use that same gizmo to edit the mesh, you can't calculate that mesh before you make the edits.
But I'm sure there should be smart ways to solve that kind of issue in Development.
For example, in Rigging inside Blender, in the domain of the Custom Shapes / Widgets, there is the "Override Transform" (Bone Target) Option. The 'literature' and experience in Rigging indicates, that feature is capable of mimicking the solvation of paradoxical issues of Rigging such as, precisely, Dependency Cycles/Loops. The Widget of a Bone "Parent", gets 'glued' to a Target Bone "Child"; then, as we might still be able to Pose the Parent Bone with the Widget, it is possible that some of its "Visual" Transforms are presented in the 3D Viewport Editor, equivalent to the Child Bone (if we give it different, independent Automations). It would look like the Child is actively Transforming its own Parent in a plausible Dependency Cycle; but only the Widget (which might be an analogue to a Gizmo), representative of the Parent Bone, but actually, of the 'Modified' Parent Bone, is appearing in a Modified fashion, as the real stuff (the Parent Bone) is not Transforming at all from its Child, of course.
Then, lately, Blender added additional features (2 Options), to the Transform Override system: "Affect Gizmo" and "Use As Pivot"; these implementations are very interesting, but it's a bit hard to understand without a real cause or if one has never needed such a feature before. It's sort of a spontaneous way of forcing changing of the "Space", when Posing an affected Widget, without the user needing to change Pose Options, such as 3D Cursor Transform Pivot Point everytime for example.
All of these, I believe might be close enough to the Gizmo issue; if true, that would mean, Blender team already has some sort of blueprint or design strategy for a plausible solution.
A buffer could avoid the dependency cycle but I guess it introduces a lot of new issues. I don't know if someone with more knowledge can confirm...
This and many other issues could be resolved with something like a snapshot modifier. In 3ds max is called "Edit poly" and flattens the stack before it to a new editable geometry. This allows for nondestructive mesh edit to a level impossible yet in blender. The geometry nodes cache or conversions do not work either in edit mode.