Cancel button missing for baking / generating point caches
Please consider adding a cancel button to bring the baking and generation progress in line with the rendering progress in the statusbar.
Problem:
Progress bar for generating point caches is missing a cancel button / cancel UI element.
Solution:
Add a cancel button as used in the render progress bar
Examples: with UI element to cancel the task without UI element, can be canceled via pressing ESC only
Dropdown triangle in Properties > Physics > Dynamic paint need a bit of spacing
Problem:
The dropdown triangle UI element in the canvas or cache list of dynamic paint is very close to the lists content. Therefore making it hard to see and understand that it reveils a seach / filter function.
Solution:
Add a few pixel more top spacing in order to bring it in line with the top & bottom spacing of the other drop down triangles. As show in the following example:
Alternative options for the UI layout:
Add an additional toggle button to show / hide the filter on the right below the add / remove buttons.
Add some more space to the list view in general. Two lines would be enough to let it breath a bit more.
Both Edge Rail and Boundary are options for the inset tool where remembering them comes in handy. Thus I propose to expose them in the Active Tool and Workspace Settings in the Properties Panel.
Here are proposals about global functions in outliner for heavyweight (~1000 collections) setups.
A) Normal state - initial state of outliner
B) Ability to use ctrl+LMB outliner isolation as toggle, with restoring previous global state.
First ctrl+LMB press remembers inital state of scene visibility, and isolates collection, second - restores previous state of scene, stored by firts ctrl+LMB.
This will allow to quickly figure out what is stored in any collection.
C) Ability to invert visibility - to figure out what is hidden in scene. Red line is drawn in UI.
D) Ability to swap any column with visibility. This will allow to view and edit render/other state of objects of entire scene as visibilty for better scene handling and control. Column, that was swapped with visibility column became purple.
E) Ability to make everything visible via single toggle hotkey (maybe * key), to make sure what it contains during setup.
Placing the 3d cursor with shift + right click should inherit the properties from the tool settings (e.g. orientation set to geometry in tool, should orient to geometry with shift + right click as well).
âŚis anyone related to development reading still?
Big thanks for the prudence of whoever figured out that layer (collection) number hotkeys should be kept! Adds up to a huge amounts of man-hours saved across the globe by maintaining eficiency.
One important time saving bit of it was left though - âMove to layerâ now is not synced due to âScene Collectionâ being #1.
So itâd be great if Scene Collection (as view all) would be made #1, or, even better, if possible -
given that fast, repetitive object/collection shuffle is primarily used between collections, not for removing from all collectiond (that probably happens, but doesnât compare to the bulk of key presses) Move To Collection -> Scene collection should be excluded from hotkeys or changed to something else, like â~â or â0â or â-â, if natural menu choice hotkey order can technically be broken at all.
Edit: Yeah, the second option opens a can of worms with sub-collections⌠So probably just shifting general collection hotkey by 1 and making #1 something like âview allâ, would be a better idea.
Perhaps this should work like this:
X-ray =1 - full solid, non transperent.
X-ray =0.999 - as it is now at a value of 1
X-ray = less than 0.999 - becomes transparency, linearly
I sent a bug a couple of days ago and received a similar response. If you click very fast with the left click keymap you can lose 30-50% of the clicks and not select anything.
ITâs because a conflict with Box Select, just change a parameter that basically does not create problems, at least not as serious as losing up to 50% of your selections and put a huge lag to the input. But it was decided that way and it will stay that way.
We have that lag also in the context menu, by design, of course.
Time to solve the problem 3minutes. God knows how much, a couple of years, to annoy well the UX of thousands of users and that blender seems laggy.
PD: It remember me when I send my first bug, years ago, and I talked about mirror tool, that invert the normals (something that nobody will expect) and the response was the same.
yours or should i say the other guyâs complain about fast selection, is not really a bug but related to the settings of the default keymap, itâs something that was mentioned on the developement phase and many like me including the Artists from Blender Studio raised the issue,the devs fixed it by exposing the options in the preferencesâŚetc and we showed him how to do it, the problem is the new users will have to tweak it manually in the input editor or use a different keymap like RCS.
I donât know if it fit in a âbugâ definitionâŚBut more unexpected behaviour than in a program that it is about from selecting things, that these are not selected depending on the speed with which you move the mouse, there can not be.
Whether the problem originates an error in the code, a faulty design or a bad configuration. More when it is the main virtue of blender up to 2.79 and the default keymap.
I donât know if itâs been said here, but I find it annoying when you work on transparent materials to be rendered on cycles, when you switch to view shading, not to have options to change the transparent from opacity to alpha blend or alpha hashed without having to switch engines.