Regarding wireframe and the new See-through option. William R. says that they are taking into consideration the possibility to use presests for 3d view visualization. So many options to choose right now. The good old wireframe mode could come back as a preset that sets front/rear wires + seethrough at 0 transparency
2 Likes
When is a good timeā¦
@cekuhnen āsimplistic UI that needed a lot of smart thinkingā
Yes that is a problem, I will not deny it.
Melvi, the latest builds are nearly a week old. The blender institute is moving, so they havenāt updated their builds yet.
I have two questions:
- Why are the snapping tools on the top bar, if they only relate to the 3D view? Sure, some other editors have their own set of snapping tools, but they are different.
- What if you have one tool active in the 3D view, and another tool active in another editor. What does the top bar display? If the top bar only works for the 3D view, shouldnāt it be a part of the 3D view?
1 Like
Isnt it better to have global snapping instead area based?
Someone earlier said the exact opposite. Itās a matter of tastes I guess.
Usually to take care of these situations, applications preferences are used. In Blender though there are moltitude of corner cases that need a preference to be set. Iād say that also the preference window has to be carefully planned (I know thereās already a mockup) to avoid confusion and to allow for an even more granular āpreferences experienceā.
1 Like
The node editor has snapping to node elements.
Why would you have snapping to node elements in the same menu, as snapping to 3D models? Also, if you are snapping to grid in the 3D view, that doesnāt necessarily mean, that you want to snap to grid in the node editorā¦
Itās probably not that bad, but when working in 3D view, it might look a bit silly if the snapping menu is populated with options that have nothing to do with what youāre working at.
Maybe they could write in brackets, what the snapping option relates toā¦ like āVertex (3D view)ā or āNode X/Y (node editor)ā and similarā¦ I donāt knowā¦
1 Like
I donāt know how it will be handled, as Julian Eisel said here in the comments, how do you manage the difference between Node Editor Snapping and 3D View Snapping ?
Sorry, wanted to reply to @Blenditaway
The preference i meant could just be use global snapping (vs workarea snapping)
Eather you make the xy snapping in global tool bar availible or make automaticlyyy or orā¦?
Hereās an idea:
When, for example, you have the Active grab/move tool, wouldnāt it be nice that the initial click would set the origin/pivot, based on the snapping settings?
So, the workflow would be:
You have a cube selected, and the grab/move tool active, youād click on one corner of the cube, to make that corner the pivot, then you drag the cube to another object, and that corner will snap to something elseā¦
1 Like
I explained my thoughts about the top bar on this topic.
IMO the current one is a 3d view and should be either reduced to a 3D view only element (meaning not a top bar on the whole blender window) either a global top bar which have common tools and options.
I personally prefer the global top bar, because in theory it could handle more things, be really task oriented if worked that way.
An example about the snaping tool in that paradigm : the snapping options could be all in the same place and only display the options available on the opened editor. Meaning that i.e. there is no node editor opened, there will be no node specific snaping options displayed.
1 Like
William Reynish posted a first non final proposal for keymap changes, I think these first implementation of the pie menus will be very useful. All of it is pretty consistent.
Agreed, those things (proportional editing, snapping, orientationā¦) are totally contextual.
I canāt find the quote, but Ton mentioned performance issues, which is true:
Is it me, or 2.79 is faster?
Well, itās still a WIP on dev time 
2 Likes
About the proposal keymap changes, I send this 
Something pointed out on that RCS topic, is that the ESC key cancels a lot of things and, in some scenarios, can cancel several actions in one single keystroke (and most of the time itās not wanted). While a āsolutionā could be to make the Esc key cancels only the āactiveā action (if that is possible ?), I think that Esc key actions should be reduced at least for some elements.
I propose that ESC key should not be able to cancel any action or task which can be/is processed in background and/or have a specific stop/cancel button (or could have one) to stop it.
This includes :
- Rendering
- Baking
- Animation playback (already have itās own shortcuts anyway)
dunno if itās dum. ĀÆ\_(ć)_/ĀÆ
I agree for the animation playback, but instead of not cancel rendering for example, if there is multiple tasks to cancel, we could be able to choose the task to cancel in a menu ?
Sometimes the UI becomes unresponsive, so using the keyboard should be faster and safer.
Since Blender is single window, I think that thereās no easy way to choose which part of the UI you want to cancel its operations.
1 Like
Maybe, but this have to be coded. And TBH I bet that a little keymap change have more chances to be actually done for 2.8.
1 Like