In T68970#759409, @ThinkingPolygons (ThinkingPolygons) wrote:

LOL. Clicking on a bunch of vertices one by one at a high speed is dumb imo, I'd use circle select or something else. There are much faster selection methods for this.
As stated before, not a bug.

In T68970#759388, @Brecht Van Lommel (brecht) wrote:

Please leave reopening and triaging reports to developers. This is better as a discussion on devtalk, it's not a bug.

Let's see, it's not a down-side, it's a huge mistake.

I do not know, imagine that when you are programming all the pulsations have 200ms more lag and that if you write fast you lose 1 out of every 3 pulsations.

Is it a joke? Seriously.

In T65965#753228, @Harley Acheson (harley) wrote:

Just for completeness, my own (unpopular) opinion on this checkbox alignment issue is to treat checkboxes more like other items. Think of them like toggle buttons we already use all over. Or consider them like sliders with only two positions. The alignment issue goes away, they become all more consistent, and the hit area is much larger:

Maybe I'm wrong. But commenting

I want to remember this proposal in RCS with a lot of community support

I want to remember this problem that blender actually have if the user move the N-shelf to the left. The panel is place at right of T-shelf, making hard to use it.

I like the solution of a dinamic UI. I never supported it because I though taht could be a problem to implement.

In D4721#108386, @ronan ducluzeau (zeauro) wrote:

For users of Active Tools the pivot, snap, orientation,... are part of the configuration of the active tool.

For all users, these settings are fundamentals. They are not just used by active tools. They are used by all tools.

In D4721#108378, @Jean Da Costa (jeacom256) wrote:

This is getting confuse to me.
Anyway the only thing this patch does is moving the topbar to inside the viewport, nothing is really changed from a usage point of view, only that if there are multiple editors with multiple active tools, now each region have its own topbar and even if you hide it you still have access to the same settings in the N-panel isn't that?.

In D4721#108366, @Jean Da Costa (jeacom256) wrote:

Why would we hide the tools we need? this doesn't make sense.

I think my argument is clear. Why can't an active tools user see his tool options in the same bar as other users? Why don't we hide the tools that you and me need in the n-shelf and keep the header only for active tool users?

This patch only listens claims and needs of users of modal tools. The users of active tools are relegated, ignored and separated, in one way or another, from the rest of the tool options and users. It is not taking into account their point of view or their future user experience, because currently this user is almost non-existent.

In rB9573bf432c4b06d940b4b38cc455826f47518884#227192, @Campbell Barton (campbellbarton) wrote:

In rB9573bf432c4b06d940b4b38cc455826f47518884#226613, @Gavin Scott (Zoot) wrote:

In edit mode the upper-right corner kinda looks like a train wreck now:

All these different interaction points in different sizes and shapes, and that super-prominent "Options" menu which suggests it's going to contain every "option" for the 3dview. Combined with the loss of the "Overlays" and "Shading" words in the header means the true 3dview options are lost among everything else.

Multiple changes are planned here: D4721

In reality I only ask or support to invert the positions of editor type and object interaction mode. Interaction mode in the Tool Header and Editor Type in menu header.

In D4680#107243, @ronan ducluzeau (zeauro) wrote:

@Alberto Velázquez (dcvertice) , I probably misread your comment.
But try to redo your mockup with 3D Cursor using an orientation set to View.
And tell me that is not confusing to have 2 orientation that have nothing in common next to each other.
Mixing things just because these buttons are the ones you use the most, does not make an UI simple to apprehend.
2.80 has now a setting per line with things ordered into subpanels in panels.
But Topbar would be a mess of things that are not affecting same tools.

Yes. And how many default screens are hiding things to new user since that time ? none.
You said that proposal is fine. I disagree.
To get rid of such topbar, user have to know lots of shortcuts for orientation snapping, mode switching but enougho to ignore active tools.
It will not close it.
To get rid of header, he needs to know what is into menus.
So customizing such proposal is just available to intermediate and advanced users.
On the other hand, keeping topbar just for active tool (as it was until now), allows fresh users that began under 2.79b to ignore active tools.

! In D4680#107231, @ronan ducluzeau (zeauro) wrote:
A new user discovering Blender will need everything (menus and popovers).
You already mention the problem of mode that could be hidden if active tool is hidden.
The same way, there is a potential problem of confusion between active tool gizmo orientation (it was move to popover for object gizmos but problem persists for 3D Cursor) and orientation of 3D View that will be used by operators called by a shortcut.

The order of the controls of the proposal should be kept, because mixing the tools with the old header forces to have both header in the viewer always. All this was taken into account when developing the proposal.

In D4680#106931, @Bun ny (bunny) wrote:

It does make sense to move the tool parameters below the menu bar, but for tools with lots of parameters like Sculpt and GPencil these all still feel cluttered. I think putting the Active Tools Settings panel from the Properties editor into some manner of (floating popup?) panel similar to @Alberto Velázquez (dcvertice)'s mockup makes the most sense.
My Sculpt and GPencil workspaces look like this, and I often have to inelegantly slide the area nearly closed to make more canvas space.

In D4680#106528, @Brecht Van Lommel (brecht) wrote:

Testing with buttons shuffled around:

Still doesn't solve the case where in edit mode tool settings don't really have enough space. Also not grease pencil.

Could be a great idea allow one of this tools to add arbitrary mesh. To add objects/meshes to the scene/object easily

Don't waste your time. UI team have ignored all feedback in blender 2.8.

I think that it's better hide the - until user focus on an element. Because a list of - appear more other type of symbol instead a remove symbol.

while a deselect hotkey can be useful, removing the utility of A doing both is a mistake for users who are not going to know that A is capable of doing both and are not going to look for that option. In addition to forcing all former users to retouch the hotkey (this and a hundred other hotkeys) to work as traditional Blender.

In macOS/OSX ⌘ is used like CTRL, SUPER/WINDOWS key doesn't have a lot of uses in windows except for OS shorcuts. But ⌘ is a basic key for anything in macOS and normally is the key that you use for all shorcuts, for example copy&paste is ⌘+C and ⌘+V. Because in macOS you have CTRL but no one uses it in the believe that is hard to use instead the ⌘, something that I think that it's true.

Some Mockups of that idea

In T54951#513749, @Lsscpp (lsscpp) wrote:

Labels going back in the fields?

Mockup

I think that both F3 and the accent is an absolutely hidden shorcut for new users, never in my life I would think of using both of them not for search, but simply for any hotkey, since this is not an FPS that is where that hotkey makes sense. It's hard to think that any user will use taht shortcuts to find something.

I want to remember that in a lot of laptops and almost all apple computers F3 is a really hidden hotkey because you need to press Fn and F3 to have access to F3. Nobody uses this F1-F12 shorcuts because it's a PITA. It's at least 10% of the potential users (20% in USA). Also that few people use F3 to search, it's a common shorcut for really expert users (coders mainly). The mayority of people uses Ctrl+letter (in windows the letter depend of the language of operating system in spain is B, for example).

Use that new feature to the searchbar

In T55162#507550, @William Reynish (billreynish) wrote:

From the start, 2.8 was designed to eschew Wireframe mode as a necessary feature to work in 3D. That's why we've replaced the Z key to enable see-through X-ray mode instead.

I continued working with soc-2017-normal-tools branch and I saw the problem two more times, so I can confirm the bug in the branch. By my work I only use this branch and the error happens one time each ¿4-5 hours? of work. So it's not easy to reproduce. I will try next time that I do a sculpt with dyntopo to use the master branch.

I only see that problems like a feature, If I see the facedot like in that images is because I'm doing something wrong, so it warns when your ngon is not correct for some reason and normally I use facedots like references when I move meshes and I don't need a lot of precision "¿Oh, my cursor is in the same position that the facedot? then I put the cursor correctly". And this happens all days a lot of times. Like incorrect faces that for some reason are created between two faces and don't have any area and facedots tell "hey, you have here a face that you don't want"

I'm modeler and I don't agree with this assessment at all, first of all because it's about deciding for the user and taking away features that currently help him (like select faces that you barely sees, because you select the facedot instead of click in the face) for purely aesthetic reasons.

Hey william

I'm sorry if I explained it wrong, but I didn't mean at any point that I understood that this was going to be the default template. In case someone got confused. Even if you personally think that it should be the default template (to make it more visible)

In T54963#500016, @Ludvik Koutny (rawalanche) wrote:

In T54963#500012, @Alberto Velázquez (dcvertice) wrote:

One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.
It is almost a wizard for fools, which unleashes the power of blender to any user.

What you see here is nowhere near finished :) There will be lot more, and do not worry, I do not plan to leave the quick search out. It will probably be mapped on Tab key, since it's commonly used key for quick search in software that supports it (Maya uses Tab key for quick search in Node editor, and so does Nuke).

Since it's not mandatory I'm not worry. But I don't see why to change something that no other program use like standard and make harder to all new users use tutorials based in default keymap.

But no other software have a search function like blender and no other software use spacebar to the proposed switch mode, it's not a standard. The only program that use spacebar is maya and it use that to give a lot of funtions directly to the user. And spacebar is linked to the search bar idea in a lot of assistants, for example OSX.

One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.

What about a retopo mode?

This means that current operators can be accessed without going through active tools? That is to say, it will not be possible to use extrusion, move, cut,... directly, like right now, pressing a hotkey without going through this system? Or it is a complement like in actual blender2.8 versions?

Thanks to you!

I want to comment a few bugs added since @Bastien Montagne (mont29) refactor, these problems don't appear in 9d3ad0eb5af7ab4f3fe28820f1e419e2f69c7cb9

Hi, I want to ask a few questions since a user pov and limitations that I see in actual viewport.

That behaviour don't have any sense from user pov. Bevel tool remember a value sometimes and the user cannot know the reason why that happens (only if they read this thread). It only create frustation in new users that some time before enter the bevel value in the panel and they will keep that behaviour all the modeling sesion, hours later. Only because a few users don't want to use the F3 or repeat.

This is the last time that I told, that behaviour is not correct and is not correct in any program.

I though that It is a bug tracker, not a feature request.

I have downloaded blender 2.78, 2.78a, 2.78b, 2.78c, 2.79, 2.77a, 2.76b, 2.74 from the webpage and I check it, I didn't see any option like you talk... You can download these release builds and you won't see that option. I don't go to check more builds. And I have search in google and the only mention to "remember bevel amount" is this thread.

I don't see the error, is the correct behaviour and the same since at least Blender 2.5. Also Bevel now is affected because remember the cuts in some builds. I need to test it and see if I must report the bug.

If you use the default keyconfig, without the left click, the bug doesn't exist, then the fix don't have reason
If you use the default keyconfig, with left click, the bug exist and with new configuration the user cannot make shift+select.

With this commit we don't have now the possibility to make a simple shift-select with the stylus.

The problem changing the action to the pen is the same that using "select". You cannot do multiple selection with shift+click with tip. So, it is not a solution.

After some test I can't reproduce with one monitor in macOS, so probably is only a problem in windows systems.

I have never tried two monitors/windows in linux or macOS. But I can confirm this in Windows 7 64bits in a lot of machines and configurations.

Any news about this patch? the build works well, only have some crashes, but appear stable.

All the tools have the same initial value, zero, It doesn't have memory.

I can confirm that the tool have change the behaviour but still having issues.

This idea is really great first step to create some complex tools like topology tools, addons and similar. Tools that need a specific space and hotkeys to be used.

The user tell that X, Y, Z direction annoys him, and consider it a failure/bug. Ask to change this to make similar to the rest of software (don't tell any program).

About the problems in edges when baking. The problem appear also when you bake the normals in object mode. It appear where you have seams, but if you bake the object without seams, ot at least some parts, the problem don't appear in that parts.

Great work guys!! It's really a perfect solution. I'm sure that it will change the workflow of a lot of people.

I have made some test and I have seen some problems. The result with bevel shader is perfect. When you bake the bevel in a normal map and you use it in cycles material it appear to have a "border" near to edges, and the normal output have this effect. Maybe is the normal behaviour of the a baked normal map. Here some screenshots

Also is needed the opacity control of the image

The edge path select error that make triangles still happening.

imho the actual system works well, and have some features really usefull and have few problems. The images are linked to one view (right, front,...) and don't show in perspective view, also you can use movies. You can have different references for each view and you don't have objects in scene bothering to the pipeline (You don't need to check if you have extra objects in the scene when export).

I have tested the new diff and it improve the render time from 97 to 72, from a original 23 base render.

really? Sometimes is boring when you see the devs don't implement a usefull feature. You have a impressive sculpt system inside a 3D modeling suite and you waste all your work and send it to the garbage because you don't finish the work and make the tool inusable for real work enviroment.

@Saurabh Wankhade (sauraedron) I suppose that, anyway I want test it and tell the results if this wasn't be the case.

I have tested the test files with the actual version, 2.73a, and the last in the builder blender-2.73-1dddcfb-OSX-10.6-x86_64.zip. And in all the version I only obtain two textures, not three.

Yes, I have the problem in all the builds that I have tested since 2.73

• I have tried now old version of blender. Only don't work since 2.73, in 2.72b work fine. Other versions that I have tried 2.59, 2.69, 2.71, 2.72

I have tried the same problem in other three macbooks pro mid 2014 with NVIDIA graphics and have the same problem.

I will try to explain a few more the bug.

In the collada the problem is that all the maps disapear from the list of textures and the specular are duplicated, and the material are bad imported, not of the viewport. The importer doesn't import the files properly.

Please, instead of tried the file in Linux like the other bug and tell me "update your graphics drivers" search a few in the web and you will see, and you will LEARN, that in OSX you cannot update the drivers.