Pie Menu Development for Blender

Archive Blender Development
1

Hi! I’m delighted by Blender 2.8’s support for pie menus (which I’ve implemented for other systems), and I’d like to help improve them.

So I’ve been reading the Python and C++ source code in Blender, and also playing with Raa’s amazing Pie Menu Editor and reading its source code to learn how it works. It’s a great example to learn Blender user interface programming from, since it does so many more things than just editing pie menus.

I would appreciate suggestions of other exemplary code and add-ons to look at as examples of how to program Blender. Especially an example of how to make a custom view with boxes and arrows you can drag around, like the graph editor.

To get started learning the code, I’ve tried taking a stab at fixing a bug, “Pie menu breaks if spawned near window edge”: #49029 - Pie menu breaks if spawned near window edge - blender - Blender Projects

I’ve made a patch that implements one approach to solving this problem using mouse warping that I’ve tried and like.

But it needs to be tested on other platforms, which I don’t have set up myself. And I hope it does not astonish users too much. Plus there should be a user option to enable and disable it, of course.

One possible way to handle the window edge problem is to “warp” the cursor by the same offset as you had to move the menu to keep it on the screen.

I’d appreciate other developers and users trying it and letting me know if it works and feels ok, please.

It seems to work on a Mac, but I don’t know how well this technique will work on other platforms (especially X-Windows with its slimy asynchronous nature).

I would appreciate some feedback about what features and changes to pie menus are important to Blender users.

Here are some examples of pie menus I’ve implemented in the past, demonstrating how they handle the screen edge condition, mouse-ahead display pre-emption, shaping windows, laying out the items, providing feedback, and enabling interface designers to create and edit pie menus.

This is a demo of an X10 pie menu window manager (X10 is what came before X11, of course :wink: that shows screen edge handling (starting at 3:50):

This is a demo of ActiveX pie menus, that shows mouse ahead display pre-emption (and some weird experiments in alternative shapes and layout techniques):

I’m especially interested in enabling users to edit their own pie menus, which is why I would like to build on top the great work that Raa’s has already done with his Pie Menu Editor.

Another important feature pie menus should support is providing live in-world feedback during tracking, especially when they use the distance to control a parameter, like font size, color, etc.

These are pie menus for Unity3D:

Here are some old JavaScript pie menus for Internet Explorer 5:

Here is a tour-de-force demo of the pie menus and visual programming language in The Sims:

And pie menus in SimCity:

These are pie menus for the NeWS window system, written in PostScript, for window management and Emacs:

Here’s a playlist of lots of different kinds of pie menus on various platforms throughout the years.

Here’s a talk I just gave about the history of pie menus:

And I’ve written lots of stuff about them on my Medium page:

Pie Menus: A 30 Year Retrospective

7 Likes
2

I’ve tried your patch. On windows 10, the mouse warping works, but the pie menu immediately disappears.

Pasting code in a comment is not the ideal method (you missed a #include). Consider submitting as a patch https://developer.blender.org/maniphest/task/edit/form/4/

1 Like
3

Wow, never knew pie menus were that old. I think this topic didn’t get much attention because pie menus are not that popular in blender. Before 2.8 they existed only through addons and most users never used them. Now they are here by default but no way to tweak them without coding or addon, which makes them very limited. So “enabling users to edit their own pie menus” by default with easy to use and native implementation, would be the biggest improvement to pie menus in my opinion.

2 Likes
4

i wrote my opinion on pie menu on paper cut thread
There are reasons why I find them annoying, and there are also reasons why I think they are advantageous.
I wrote my point of view, as experience of using and where I think they could be improved …

1 Like
5

Just read your post, but did you know about these settings? Because they seem like exactly what you need, you can tweak animation and radius there

pie_menu
pie_menu.png1124×734 147 KB

1 Like
6

obviously … and thank goodness it is so … otherwise I would not have digested the pie menus well

1 Like
7

Thank you very much for testing my patch! I will submit patches with that form in the future so I don’t miss anything and it’s easier for you to test.

Is it selecting the item on the side of the menu of the screen edge it moved it away from, or just doing nothing?

I’ll have to set up a Blender development environment once I finish unpacking and setting up my PC. Then I’ll give it a try when I have a chance.

I was afraid there might be platform specific differences with mouse warping. My guess is that there is a race condition because the mouse up event is already in the queue with the pre-warp coordinates, so it thinks the cursor has moved away from the (now repositioned) menu center when it processes the up event.

As I mentioned in the issue “Pie menu breaks if spawned near window edge” ⚓ T49029 Pie menu breaks if spawned near window edge , one way around this problem is to implement full blown “mouse ahead display pre-emption”, which delays showing the menu and warping the cursor until you stop moving the cursor. If you’re not moving the cursor and just click up the menu (button down/up without moving), it immediately displays the menu and warps the cursor if necessary, and there’s no warping problem because the mouse button is up and the cursor didn’t move between down and up. But if you’re moving the cursor when you click, it waits till you stop moving, and only then warps and shows the menu (when the cursor is still, so it’s safe from the race condition). And if you press, move and release without hesitating, it will never show the menu or warp the mouse (display pre-emption).

In general, mouse warping can be confusing, and should generally be discouraged, and it should not be done lightly without a good reason for it, nor without obvious visual feedback. In the case of pie menus that must be moved to fit on the screen, it’s a last resort to mitigate an edge condition, less bad than the alternative of selecting the wrong item.

I think warping in this case is better than alternative approaches involving timeouts (like the UI_PIE_INITIAL_DIRECTION delay technique), since they slow down fluid interaction, impose arbitrary invisible time limits and inexplicable mode changes, and users have no way of sensing when the timeout will expire or changing its duration on the fly.

In one of the videos of an earlier implementation of pie menus in Blender by Uncle_Entity, I noticed that it moved the menu back on the screen, but didn’t warp the mouse, although it adjusted the “virtual” mouse coordinates to behave as if it started out in the offset menu center. That seemed more confusing to me than warping, though.

Instead of using fixed timeouts, I’ve found that triggering actions (like deferred popups or expanded feedback) on when the mouse stops moving (which can be detected by an imperceptibly short timeout) works better, since it’s directly under the user’s control and they can kinesthetically feel if they’re moving and stop moving whenever they want, so there’s an immediate cause-and-effect instead of just waiting around for a while.

Of course it’s necessary to use other solutions when mouse warping isn’t possible, like with tablets and touch screens. (Having a robot arm or that warped your finger or hand into the desired location by pushing it would be way too intrusive! :wink:

I was pleasantly surprised and do like the way the mouse warps around the edge of the screen while you’re dragging, rotating or otherwise manipulating an item in Blender, so you don’t have to stop dragging and scroll. I think “pleasant surprise” is technically a mild violation of the “Principle of Least Astonishment”, but it’s pleasant since it helps me do what I wanted to do more easily.

In the ideal world, it would be nice if it were possible to tell if the input events were coming from a warpable device or not, on the fly. Especially since it’s possible to use both a mouse and a touch screen or tablet at the same time. Then you could have device specific parameters for warping, click, and motion detection (since sensitive tablets have more jitter and hardly ever stay absolutely still), and use different screen edge mitigations depending on the device.

8

I love Pie Menus too, and I guess I should work on fixing the bugs I have found or just report them but most of them are already reported. :stuck_out_tongue:

Now to throw around some suggestions…

First,
Why not assume all devices to be warpable, and just remove common artifacts.
Also warping would have varying affects based on input device parameters like probably resolution, sensitivity, multi touch, and even the OS settings.

Second,
I think a more organic or dynamic design for Pie Menus will be better than hard coded ones, so that it makes use of the extra screen space, some have, or just make itself scarce if the screen space is low. Adjustable for the Mouse speed? Probably even have support for multi touch if the device supports it.?

Third,
I believe allowing high customizability and ability to create new Pie Menus on the fly is indispensable. It just makes the whole workflow feel soo much more personal. And I don’t want the user to have to know how to code to do it. This was a big problem when I help my friends learn Blender they couldn’t make new Pie Menus cause they weren’t good with coding.

Also,
As for reference Code Base, try

This is JacquesLucke’s Nodes Playground Branch it might have some graph stuff in the commits you might want to see.

I only recently got started with the Blender Development so not sure about the code base yet… :disappointed_relieved:

1 Like
9

Also. I will claim a node-based PIE menu editor if you continue.

1 Like
10

Please write up more bugs and suggestions, and I will too. That will help us discuss which issues are most important to work on, and gather together examples and links to other relevant pie menu implementations, prototypes and research papers, to compare alternative approaches, and come up with new ideas.

It’s important to air the issues and hear from people are actually using them in Blender (including people who don’t like them), especially for me since I am new to using Blender itself! But I can help avoiding mistakes of the past and highlighting ideas that worked well. I want to help programmers and users understand the design issues and have the tools so they can make their own pie menus.

In response to your suggestions:

First: What do you mean by remove common artifacts? I agree that warping behaves differently not just according to the platform but also according to the input device, mouse sensitivity and acceleration, screen size and resolution, and OS settings, so it gets pretty tricky.

That suggests pie menus (and Blender’s interface in general) should support optional features that users can enable/disable and adjust for different platforms and input devices, since you might have any number of very different devices attached at once, and it would make sense to use them all together. But I don’t understand enough how Blender’s input system works to know if per-device settings would be possible.

Bill Buxton wrote an excellent paper on input devices in 1983, called “Lexical and Pragmatic Considerations of Input Structures”, which categorizes input devices and how their unique properties map to the problem domain, and discusses a lot of important concepts like pragmatics, chunking and closure, device independence, taxonomy of devices, and the nulling problem. These are very important issues for thinking about designing user interfaces for multiple kinds of input devices:

https://www.billbuxton.com/lexical.html

lexical: issues having to do with spelling of tokens (i.e., the ordering of lexemes and the nature of the alphabet used - symbolic or iconic, for example).

pragmatic: issues of gesture, space and devices.

Figure 1: Taxonomy of Input Devices.

Continuous manual input devices are categorized. The first order categorization is property sensed (rows) and number of dimensions (columns). Subrows distinguish between devices that have a mechanical intermediary (such as a stylus) between the hand and the sensing mechanism (indicated by “M”), and those which are touch sensitive (indicated by “T”). Subcolumns distinguish devices that use comparable motor control for their operation.

Second: Simon Schneegans’ beautiful work on Gnome-Pie, the Coral-Menu, and the Trace Menu will blow your mind and inspire you with his organic, dynamic, yet practical designs, especially his easy to use user-editable drag-and-drop Gnome-Pie application launcher design tool.

I can’t understate how much I like Simon Schneegans’ Gnome-Pie: http://simmesimme.github.io/gnome-pie.html

Not only is it all slick, beautiful, and elegantly animated, but it’s properly well designed in all the important ways that make it Fitts’s Law Friendly and easy to use, and totally deeply customizable by normal users! It’s a spectacularly useful tour-de-force that Linux desktop users can personalize to their heart’s content.

Simon Schneegans’ Gnome-Pie: Gnome-Pie is a slick application launcher which I’m creating for Linux. It’s eye candy and pretty fun to work with. It offers multiple ways to improve your desktop experience.

Check out the amazing demo:

I also love his bachelor thesis work on the Coral-Menu and the Trace-Menu:
http://simmesimme.github.io/news/2012/10/10/bachelor-thesis

Simon Schneegans’ Bachelor Thesis: For the same reason they are effective. But by far the most remarkable advantage is their continuous learning curve. Users may become extremely fast just by using the menu. Every time they make a selection, they get faster and more accurate. At some point it is not necessary to read the labels anymore, because the user remembers the direction of an entry. With “normal” linear menus that is not possible. The maximum selection speed with a mouse is very limited and soon obtained.

The Coral-Menu: The first prototype is targeted at users who often search for items due to their manifold menu usage. It displays hierarchies with ease. Even very deep hierarchies are easy to explore. Many items are displayed by increasing the pie’s radius and stacking the labels which are displayed next to their sector on top of each other. The following clip demonstrates the behavior. As you can see, the items of sub-menus are indicated by little dark blobs at their parents. This menu is quite fast to use because of the mouse making a smooth movement.

The Trace-Menu: The second prototype addresses itself to users who often make use of the same menus. Thus they know where to find an entry and want to select it blazingly fast. In contrast to the Coral-Menu each sub-menu is a complete 360-degree-Pie-Menu with one entry being the parent menu. The hierarchy is visualized by a path between the visited menus. This menu features a so-called “Marking-Mode”: The user may draw the path (the “trace”) to the desired entry with one continuous gesture. Watch the following clip and you will understand this behavior — the Marking-Mode is used for the very last selection.

Third, that is the holy grail, indeed! Check out how Gnome-Pie works with drag-and-drop! I think it’s also important to balance having good defaults, with having too many options and no way for users to discover the purpose of those options or to know when and how to use them. I think it’s important to educate users in the issues around pie menu design, and also for the tools to promote good practices, yet be configurable enough for knowledgeable users to make exceptions to the general rules of thumb when they’re appropriate.

For example, eight is an ideal number of slices for many reasons, but sometimes it’s appropriate to have a dozen or even more (using the menu more like a dial or channel changer, like selecting from a circular palette of discrete color samples around the outside edge of a continuous brightness/saturation/hue color wheel).

But seven items (or any odd number, but seven in particular) is a horrible number of slices, and you should throw in an extra empty slice to bring it up to eight.

Here’s another paper called "An empirical evaluation of some articulatory
and cognitive aspects of “marking menus” which measured the performance of marking menus with different numbers of items, which determined that 7 slices are actually slower than 8 slices:

Notice how in general the more items a menu has, the slower the response time and higher the error rate, except that 7 items is actually a little bit slower than 8 items, and 11 items is a little bit slower than 12 items, and 11 items has a much higher error rate than 12 items:

It also compared different kinds of input devices. Check out the “Stroke Analysis” section to see the graph of how different the marks with stylus (most accurate), mouse (less accurate), and trackball (very inaccurate) were. Each of those input devices should have different “click detection distance”, “inactive radius”, “motion stop detection time”, and other tracking parameters, as well as different screen edge handling (because the stylus is an absolute positioning device that you can’t warp, but you can warp the mouse and trackball since they’re relative positioning devices).

3 Likes
11

Oh neat: it looks like Blender’s input system knows about tablets and absolute versus relative positioning devices! So pie menus can figure out if warping the mouse will work.

wm_event_system.c wm_event_add_ex

if (ELEM(event->type, MOUSEMOVE, INBETWEEN_MOUSEMOVE)) {
    /* We could have a preference to support relative tablet motion (we can't detect that). */
    event->is_motion_absolute = (
            (event->tablet_data != NULL) &&
            (event->tablet_data->Active != GHOST_kTabletModeNone));
}
12

man, the last two demonstration videos are amazing pie menus!
currently the current blender pie menus find them hateful and uncomfortable …
but if they were like those in the videos you posted they would be wonderful and well-liked!

2 Likes
13

One step would be to make it possible to draw (and animate) the pie menus in Python. Is that currently possible?

Another cool feature would be to be able to draw pie menus with 3d models and dynamic meshes!

Then you could put little spinning 3d models of the items in your pie menu of favorite items.

These Unity3D pie menus show that idea, but with very simple spinning cubes ( https://en.wikipedia.org/wiki/Programmer_art ).

Not only could menu items be 3d objects, but also the pie menu “shell” could draw dynamic 3D meshes with all kinds of cool shapes and styles, like the pie menus in Kodu Game Lab:

2 Likes
14

One of the biggest problems with pie menus blender at the moment is that they have no discoverability. Unless you already know everything about them there is no way to find out they exist. They need a dedicated settings page with a list of the pie menus, the hotkeys that call them and the list of available actions centralised in a specific page. It would be great to allow customisation of the available pie menus, especially for tablet users. Pie menus are great when keyboard availability is limited.

3 Likes
15

There is a 3D View pie menu addon, with a full list of pies, hotkeys and ability to turn them on and off, I think integrating that functionality into the user preferences would be the best bet for discoverability and allowing users that are anti-pie or dislike a specific menu to disable them.

I developed an addon that built upon the 3D view pie menu framework and doubled the amount of available pie menus. Now I can choose whether the “N” (view) panel is docked in the 3d view or in a pie menu as well as panels from the properties editor, toolshelf, etc.

1 Like
16

Hello!

I’ve used Autodesk Maya for the better part of 9 years now and I’ll be the first to complain about it.
But one thing maya does really well is pie menus, or “marking menus” in their terminology.
I apologize for bringing up such a direct competitor, but after having gone through your examples, I still think Maya has the best functional implementation of pie menus.
Simon Schneegans’ Coral and Trace-Menu above are very similar.

A friend and I are in the middle of customizing a pie menu for blender that would mimic Maya’s in a few aspects. So far we have borrowed a lot of the python code from 2.80’s context sensitive right click menu.
But much of the functionality that makes Maya’s great is not available to tweak from python in Blender.

Why Maya’s pie menus are great:

  1. A lot of functionality behind very few hotkeys.
  2. Most work can be done with minimal interface in the way of the content.
  3. Menu are context sensitive to your selection, yet the layout is consistent with its functionality.
  4. Fast enough to rely on muscle memory and UI is not necessary for it to function

First two points are obvious, but I’ll explain 3 and 4 in detail a bit.

For context sensitivity and consistent functionality let’s consider the merge function.
If you select vertices, faces or edges and call the context sensitive pie menu in maya, you get 3 different pie menus with slight variation. But all have the merge function at the north position.
To the east you have split or bevel function.
This consistency makes it easier to get these menus into the muscle memory.

Working in maya, I rarely even get to see the pie menu interface.
I have learned the positions and sub-menu positions and when calling the pie menu it is instantly tracking the general path of the mouse. Most actions can be done with a flick of the mouse before the UI ever is displayed.

You can try our draft pie menus here: https://gist.github.com/bastianlstrube/010f9e22c15ce05b42ec464acee2369d

Call the context sensitive menu by holding shift + right-mouse
But to revisit the merge function. With a selection of vertices, doing the quick flick to the north, you’re met with a regular submenu where you have to click the option of merging at center, pivot or collapse.
In maya, a flick to the north would simply do merge at center. Flick to North, then North-East would merge at object pivot. North, then East; merges at world origin.
All these actions can be made in a split second without ever seeing the pie menu interface.

I hope our attempts to make blender a little mayan will not offend anyone. Everyone I know who work in animation is blown away by blenders recent development. I think a little addon that would welcome the people used to Mayas interface would open the doors for a LOT of professionals from both animation and VFX industry where Maya is currently standard.

5 Likes
17

this trace menu is really amazing !!! dream to see this in blender !

3 Likes
18

I appreciate your feedback about what you like about the Maya marking menus – that’s just what I wanted to know, and very important to hear, in order to improve the pie menus in Blender – not offensive at all, just the opposite! Please keep the great feedback and ideas coming!

2 Likes
19

Tried your key confing, the only thing I get from Shift Rclick is dragging the 3D cursor :slightly_frowning_face:

20

Did you put the PIE_*.py files in …/2.80/scripts/startup/
Then use the preferences menus ‘import’ to open the keyconfig file.
And select the keyconfig from the dropdown menu?

It works for me. But as mentioned, I’m a little new in blender. Not sure I’ve set the scripts up correctly.

Also, We’ll try to get a video recorded of maya’s menus on Monday so you can see it moving.