- User Since
- Jan 13 2014, 10:21 AM (210 w, 22 h)
Sep 13 2017
Glad to see this being discussed here. I agree with @Jac Rossiter (Jakro) that you'd want UV seams in the middle of the bevel whenever possible. Now ofcourse that's not the case with an odd number of edges, but it's still an ideal to strive for in my opinion.
As for other edge attributes, it seems to me that hard edges & bevel weight make sense being on the outside of the bevel, so as to avoid compromising the bevel's curvature (either by bevel the middle of it, or by having a sudden gap in normal continuity there).
Aug 7 2017
There has been talk of removing the x and + next to scene/screen data blocks, and moving it to a context menu, or inside of the scene/screen browser. Has there been a definitive decision made on this?
I'm all in favour, for visual clarity and usability (not being able to delete something that can't be undone so easily!), and just curious to see where we stand on that.
May 10 2017
Can this be looked at again? As @Paulo José Oliveira Amaro (pauloup) said, intention aside this feels like a bug to the user, and could be improved upon. Would this be a big task?
May 9 2017
I tested this on 2.78a and can confirm.
Mar 22 2017
This looks great!
This may be outside of the scope of this project, but would a vertex group/material mask be feasable?
The intended effect would be for only the masked area to be mirrored (with a possible invert function, as a few other modifiers have)
Dec 22 2016
Since the UI team has met up now, has this been discussed?
Dec 5 2016
Nov 30 2016
When 'Global Options' is set to false, do we revert to the current situation where everything has to be adjusted separately? Because if so, a more elegant solution may be for the user to manually enable sections.
So you can have one section to control global colours, and the user can add an 'Properties panel' override, which enables/unhides that section.
Nov 15 2016
Any development on this? It seems a shame to leave such a useful feature in limbo!
Aug 1 2016
So it seems the save confirmation is the proverbial baby that was thrown out with the bathwater? Brecht just added that back in together with the delete, even though the save confirmation was decided on and nobody had an issue with it.
I also take issue with solving a keymap issue (which is something the user can change!) with an intrusive solution that also impacts those that remap their hotkeys.
So, since there was concensus, can we get rid of the save confirmation again, at least?
Jun 3 2016
Apr 21 2016
This is looking great!
I may have found an issue: You get an empty menu when nothing is selected (or active), which is the case if you delete the cube in the default scene.
Apr 18 2016
Apr 1 2016
Mar 25 2016
Fantastic to hear!
Mar 22 2016
To give some context as to a possible use for this:
Mar 16 2016
It's my understanding that I'd need to build Blender for this, right?
If so, I've never done that, and I'm not set up to do so. Any chance of a (Windows) Build to test?
If not, I'd gladly just screenshare or something if it's feedback on the implementation you're after moreso than testing stability.
Mar 10 2016
Mar 9 2016
I think both would be best, and if possible: a toggle for Normalised coordinates (from the tooltip: 'Display UV Coordinates from 0.0 to 0.1 rather than in pixels) as in the UV editor would be great.
Mar 7 2016
Feb 27 2016
Feb 26 2016
@Jonathan Williamson (carter2422): As the author of this, are you aware of a reason for this? There was consensus on the Save and Delete commands, was there any pushback from anyone outside of this design task, or what happened?
As William Reynish mentioned at one point: this isn't a case of nothing being better than 'F', it's a case of everything suggested so far being better.
Feb 22 2016
Thanks for adding this, Campbell!
Feb 16 2016
Feb 15 2016
Any news on this?
Jan 7 2016
Nov 28 2015
Where in these links do you see anything to indicate what I said was incorrect?
Nov 26 2015
This was set to 'resolved', but the Save and Delete commands were actually never 'liberated' from their confirmation, while as far as I can tell there was concencus to do so.
Oct 22 2015
May 11 2015
May 1 2015
I can confirm that this fails, and has for some time. I always used the workaround @Bastien Montagne (mont29) provided.
The attitude of 'this might not even be worth investigating' is a bit odd, I think. It's something that's broken, and something that's one of the first things a user sees after having upgraded.
Apr 30 2015
Apologies, but I've created a new bug report about this, as I didn't find this in the search earlier.
It's T44566, and I've also attached a .blend there.
I can't edit it anymore, or I'd make it a subtask!
And as I didn't mention it in my report (can't edit), I'm on Windows 7, 64bit, with an Nvidia GTX 670 (driver: 347.52)
Mar 11 2015
Feb 24 2015
I understand, I was only suggesting we'd clean this up.
Feb 23 2015
I agree, but I'd suggest moderation as an alternative to a warning.
Hirokamatsuiko is just using this as a place for his (unrelated) feature requests, so in the interest of readability you might consider deleting his posts.
This isn't an open forum, so I think we can place higher demands on what's accepted and what isn't.
Jan 27 2015
Yes, V2 get's my vote as well. I instantly realise which was which.
Nov 22 2014
I'm aware of all the downsides, but I don't see a better solution to column's loss of function beyond certain sizes.
Even on top of the reorganisation and other proposals that are being proposed in here (and that's necessary, I'm not debating that!), I think this would be a good evolution of the UI. At best it's never seen by most users because through the reorganisation they rarely need or want to see more information than we can easily serve them with, but it's just a fact that one of the big selling points of Blender's UI system (flexibility and scalability) is being underutilised in a few window-types, and I don't see the downsides to offering this extra flexibility that's only seen when a window's become stretched far beyond what could be considered 'useful'.
Nov 18 2014
The most logical way would be to adjust the grid itself. Otherwise I think we're overcomplicating a feature that's really only about snapping to the grid. The 0.1-version is just a nice extra that's consistent program-wide and the user would expect to have it.
Fantastic! I've been hoping someone would tackle this, thanks so much.
Nov 12 2014
I've used multiple columns like this for a long time. It's an improvement over this:
And it will only show up once the user has dragged his properties panel horizontally way past what's useful. It's a choice.
Nov 11 2014
Nov 10 2014
I really, really like having paint-select be standard when dragging within the mesh, box or lasso select when dragging outside of the mesh.
Even if this isn't the default behaviour, I'd like to be able to set this up. Here's a gif of how I've got selection set up in another program:
I'm going into feature request territory here, under the assumption 'if something deserves to be done, it deserves to be done well'.
Nov 6 2014
Nov 3 2014
I think spheres for 'connected' and 'enable', and a flat circle for '2d projected' could be a decent solution for now, but am I wrong in thinking there's a chance it'll be for nothing? As I see it, there's concensus among at least a few of the UI team members that the current setup could be imnproved upon, with one solution being proposed by @Paweł Łyczkowski (plyczkowski) here: https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit#heading=h.qbvifmkpio8p
Oct 30 2014
Well, I certainly agree 100%. I'd love to get pre-selection highlighting in Blender, but so far the official word's been 'no'.
Oct 23 2014
His comments, to my mind, read like 'I like what we have, and changing it would be too much effort'. Which I suppose as an opinion is fine, but it comes across as dismissive of the work done, after over a hundred posts in here.
@Tom (t.ask) : Don't forget this isn't blenderartists.org, this is an official UI design task that the UI team is discussing here for an issue that they feel is worth their time.
That we're allowed to join in is I think great, but I'd refrain from essentially saying it's wasted effort.
The emboss theme setting has already been branched off here T42228 and now we can focus on discussing updating the rest of the widget style in here.
Oct 22 2014
Oct 12 2014
Oct 1 2014
You shouldn't mistake this for a Blender support website. If Sergey or one of the other busy developers don't give you an answer, try blenderartists.org or better yet: http://blender.stackexchange.com/
Sep 23 2014
If it doesn't impact the speed of searching, this seems like a definite improvement!
I really like this! I too find the thumbnails to be too small. The keybinding seems nice too, but it does clash with the default for zooming interfaces, which is ctrl-mmb-drag.
I agree, this makes sense. In fact, in other software I regularly use a setting which makes a single grid align to the axis closest to the camera angle, but that's outside of the scope of this patch, ofcourse.
I think this makes it more complex and less user-friendly.
Sep 22 2014
Sep 21 2014
Sep 18 2014
What's the use of the UI team if these things happen? Have they weighed in on this at all?
I prefer the version with only icons. I feel their meaning is clear enough (as they're reiterated all throughout Blender's interface), and the fact that it saves space allows for more open spacing which makes for clear at-a-glance reading.
Sep 15 2014
@Paweł Łyczkowski (plyczkowski) It would still have the labels, ofcourse. This was only to show the widget itself, in comparison to its old version.
This combined version will show less decimals, but I think the current system of showing 5 decimals even when there shouldn't be any is very noisy looking without imparting useful information.
When there are no decimals, just display a number as 5, not 5.0 or 5.00000
Ah yes, agreed. That would be outside of the scope of this task.
I sure can :D
It looks cleaner, but you're giving up customisability, while taking up more space.
I realise those parts can't be grabbed, but that's a regression in functionality. This could be forgiven if it would solve other issues, but I don't fully believe that it does. I also don't enjoy auto-collapsing (one panel at a time), as I find it cumbersome in practice. I can elaborate on that at a later time.
Noise is perhaps the wrong word, and I see no reason to drag this out over a matter of preference, but I feel the white on dark grey is too contrasting.
@Warren Bahler (russcript) It is. Can someone move these past few comments there?
The last proposed design is really visually noisy though. I don't feel this is an improvement over the currently implemented design at all.
Sep 13 2014
I'm in favour of the colour-less versions, like this one made by @Sergei Smyslov (Luarvik)
and this one by @Campbell Barton (campbellbarton)
I like the cleaner look, and the added ease of use of being able to collapse an entire section of related functions, but this way we do lose the ability to re-order panels absolutely how we want them.
I'm also not really a fan of the 'only one panel at a time' solution, as it's currently found in Zbrush for instance. It's a logical solution for an overabundance of panels, but it feels clumsy and only combats the symptoms, not the underlying cause.
Sep 7 2014
Sep 5 2014
Sep 4 2014
Many of the problems with the Properties Panel could be solved by reconsidering what needs to be there, and in what form.
Sep 3 2014
Can we move this discussion to a seperate task? By which I mean any discussion that isn't about the flat style, and by 'we' I mean 'someone from the UI team' :D
I think some really good points are being made, and it'd be nice if there was an official task where these were the main course.
Aug 10 2014
I haven't seen anything to suggest that nodes will ever fully take over, where did you see this?
edit: In fact, Jonathan's comment indicates that they're considering these designs, but will first implement drag and drop for the short-term advantage.
Another pro to the listbox that I haven't seen mentioned (but I may have missed it) is that the controls for adding new modifiers and deleting existing ones are always visisble, which isn't currently the case.
It also makes us inherit any development happening on the listbox, such as this improvement that was implemented: https://dl.dropboxusercontent.com/u/17715/BL_outliner_eyes.gif (example not from blender)
Jul 9 2014
I didn't consider this problematic, are we sure that it is?
The snapping system knows at what treshold to snap, why can't it at the same time just go into ortho? And optionally the regular, named viewport view (top/left/etc) when it qualifies? Although I understand if that's a problem.
May 21 2014
I agree with @Paweł Łyczkowski (plyczkowski), this is a good solution.
Apr 16 2014
I'm not sure what you're saying, sorry. If you're wondering where it would be in the interface, it would be an option in the Operator Panel after primitive creation.
Mar 2 2014
Campbell: Are you absolutely certain? I've tested it on multiple setups, including just now on someone elses pc with a freshly downloaded Blender. It doesn't switch to ortho, but maybe that's intentional?
That's what I thought at least, and I'd propose that it should change to ortho.
Feb 24 2014
Not sure if this is the right place, but: