This is part of the tasks in T56571.
I'm still not satisfied with the increase in code complexity (difficulting maintenance and slightly reducing efficiency).
But at least it can be useful as a reference.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- arcpatch-D3742 (branched from blender2.8)
- Build Status
Buildable 2164 Build 2164: arc lint + arc unit
Event Timeline
Comment Actions
Hey, this seems great! However, I get an error when compiling:
fatal error: '..\windowmanager\gizmo\wm_gizmo_wmapi.h' file not found
Did you remember to include all the files in your commit?
Comment Actions
This should be done in a way that doesn't require the gizmo user to do much (possibly besides asking the dial to show these marks, although it could be enabled by default when snapping).
Could this patch be made to work for the spin tool since this is typical use of the dial3d gizmo.
Transform code is doing some bad hacks which makes it not a good example to test new gizmo features.
Getting transform to work can be done after.
Comment Actions
Hi, I just tested this, and it seems to work perfectly. Nicely done.
There's a slight quirk though: When using Spin tool, If you keep holding down Ctrl even after finishing your spin, the tick marks stay visible.
Comment Actions
- Since the transform operator will be worked differently. I decided to simplify the patch to work only with the spin tool.
Comment Actions
Hm, well that's a shame - it seemed to work well for the rotate gizmo too. But if you can implement that a different way, then that's great too.
| source/blender/editors/gizmo_library/gizmo_types/dial3d_gizmo.c | ||
|---|---|---|
| 95 | This isn't output as far as I can see, its a snap setting. Would move under has_drag | |
| 443–444 | This should use the angle_increment setting for snapping. Not hard coded value. | |
| source/blender/editors/transform/transform_gizmo_3d.c | ||
| 1255 | Should be const. | |
| source/blender/editors/transform/transform_gizmo_3d.c | ||
|---|---|---|
| 1278–1284 | Looks like the lines aren't linking up with the actual snapping, ideally snapping and marks should match up. | |
Comment Actions
- Use a preprocessor directive to set a constant value for the incremental angle used on transform ops e gizmo
Comment Actions
- Use the same multiplication factor of angle_increment in` angle_delta` when WM_GIZMO_TWEAK_PRECISE.
- Use the preprocessor diretive SNAP_INCREMENTAL_ANGLE as default value of "incremental_angle" in gizmo.
- Remove redundant initialization of the "incremental_angle" in the gizmo of the transform ops. (it is not used in the modal).
- Gizmo UI name: "Angle to snap in steps" -> "Incremental Angle"
Comment Actions
This is already working really well.
The only thing is, the pie section doesn't start from where you drag. Instead, the pie section starts from a seemingly arbitrary direction, as you can see here:
It'd be nice if the pie section could start from where you drag. Does that make sense?
Comment Actions
Nicely done. The only last thing, is that now this pie display also appears when just pressing R without using the gizmo.
I think that's probably too disturbing. On top of that, the display of them is glitchy in that context.
I think the best solution would be to just not show this when not using the gizmo to rotate.
Comment Actions
It's odd to me how drawDial3d() works. It doesn't really belong into transform_gizmo_3d.c, because it is not a gizmo. It just uses a gizmo draw-util and reuses the logic to get the gizmo color. I can live with that but it's still weird design. What does drawDial3d() belong to now? Gizmo or transform code? There's stuff like applying DPI and setting GPU state in it, which in case of gizmos, is and should be handled by the gizmo backend.
Anyway, what worries me more is that this depends on wm.h being included in transform/, which is a bad-level include. (I think it happened to be included but unused before this commit.)
It seems fine to let operators know if they were invoked through a gizmo. Gizmos could invoke operators like WM_OP_INVOKE_DEFAULT | WM_OP_GIZMO_DRIVEN, the operator stores op->flag |= OP_IS_GIZMO_DRIVEN which the transform code can check to set a t.is_gizmo_driven. Or something like that.
It could also just be an internal operator property "is_gizmo_driven".
Comment Actions
If I remember correctly, the initial idea was to keep the gizmo visible and only update its properties during the modal.
But this solution has some limitations:
- updating the properties of gizmos is somewhat inefficient.
- Transform operators are not always invoked through gizmo.
To avoid this multiple dependence on drawing functions, perhaps a redesign would be needed in which operators would have a default gizmo_group assigned and should avoid draw_callbacks.