I think the issue is that "Subdivide edges" and "Subdivide Collapse" are two Refine method modes that has different names but behave completely the same, which forms a collision (functionality duplication).

Also Im not sure that squarifying is more useful than rectifying in practice.

Hi!
Briefly tested Jan 19 build on a cube.
One of the problems is that grid unwrap of a part of an island rips off and send unselected part of an island to the UV space. I think it is expected that unselected part of an island will remain unchanged or so.
Video example:

Such cases are extremely rare, it is hard to find the exact actions sequence. So, this is because of invalid mesh data.
Is it possible to detect such data with a special function?

In D9415#464288, @Germano Cavalcante (mano-wii) wrote:

• rebase onto master

For some reason unrelated to the patch the builds for windows are failing in the buildbit.

There is another possible solution to empty LMB release - do not snow snap marker after pressing B and before mouse release. Such an action will make LMB release after grabbing gizmo not empty.

Tried January 18, 04:50:55 build.
It is usable, but the main problem is an empty LCS release that does nothing, which is quite disturbing.
I think it is a nice strategy to go modals in complex cases like basepoint snapping (modals has benefits in complex cases because of a better flexibility and resulting expandability than active tools), but, AFAIK empty actions are not presented anywhere else across application.
I would like to suggest this behavior:

In D9415#464021, @Dalai Felinto (dfelinto) wrote:

as oppose to keep dragging the gizmo.

It will be more comfortable. I wonder if it is intuitive enough though.

Tested on windows. The general mechanics looks and feels nice for both modals and active tools, tried grab, rotate, scale, extrude (G.E.A.R.S.)
Lovely!

In D9415#463474, @Germano Cavalcante (mano-wii) wrote:

@Julien Kaspar (JulienKaspar) In terms of a system design, it is possible to roughly say that 3dsmax realization is an AutCAD chassis with 30% Photoshop, while Blender is an AutCAD chassis with 15% Photoshop.

I think this will allow to focus on your selection during operations, which is useful during working with dense meshes and objects with complex irregular structures and tiny details at the distances that not exceed the size of a gizmo.
How it is supposed to look when using two axis transform (for example, XZ)?

A tiny bit if context.
I think such a behaviour was made to provide correspondance to viewport action - for example it is useful for navigating bones.
I think it is reasonable to add a recursive method to the both viewport and outliner parenting hierarchies as ctrl+] or ctrl+shift+]
(Shift part stands for "expanding" and ctrl part stands for "recursive")
Alt hotkey usually mean "antiaction".

To depict what I mean about rotating/scaling, here is an example of a Referenced transforms.
Referenced transforms is a type of transformations driven by value defined by existing geometry instead of a number.
RT is quite common CAD technique obtained by basepoint snapping:

In T66484#1471650, @Dalai Felinto (dfelinto) wrote:

Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point.

We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode.

The point is that after 3dsmax switch to hotkeys in noun way, it was assumed that it was because stable solution in the verb way is not physically possible.
Before Blender proved it is wrong. It was completely unexpected that it is not just possible, but in mesh editing software paradigm also has a massive practical benefits in operations speed call, supports for sequence flexibility and toolset expandability.

Thank you for the feedback. Silence always is a bit hard to interpret.

@Julien Kaspar (JulienKaspar) I hope my explanations sounds clear or at least logical. Are they?
I assume that there are lots of devs familiar with Photoshop and its principles, but it seems like there are no devs that has Autocad background, so it makes it hard to explain principles from it clearly, even if they shaped the entire software industry, so they often are reinvented like they are something new.

I think it is needed to clarify historical aspect of active tool and modal systems for better understanding of a difference between them.

Interesting video, lots of fair points (knife, circle selection, drag threshold tradeoff, etc)
I am familiar with lots of context and different realizations and can probably say a lot about that, but I want to avoid walls of text.
In short about RCS/LCS.

• Rightclick originally was supposed to justify using gizmos because of a differentiation of an access to gizmo and to mesh by using different mouse keys.
• Leftclick is supposed to be used without gizmos - in modal GX5 RZ30 input way - because of a predictable workflow collisions with gizmos (drag threshold, partial mesh blocking, etc), some of them are mentioned in the video.

Industry standards has gone quite rough third way - there is supposed to use LCS with gismos and just have those collisions all the time.
It is quite possible to work like that if it is the only way you learned - for example, this is the way I personally worked in 3dsmax because there were no other options available, so for a long time I thought that it was ok.

A question though - what will happen to outliner's menu functionality?

In T68915#1453361, @Robert Rioux (riouxr) wrote:

Both! :-) Fast, easy to use, fully featured.

In T68915#1453057, @Robert Rioux (riouxr) wrote:

I just found this out. k-Cycles nailed it. All I could wish for and more.

https://www.youtube.com/watch?v=M-MZ3sMtE5A&t=565s

In D6505#350296, @wasd (arcticwasd) wrote:

Just make an option to make it

1. fixed width (defined by user)
2. always visible

Screenshot of an error

Well, yes, the concept of viewport statistics has had the same readability issues since its invention - its readability is highly dependent on the contents of the viewport. This is the reason status bar statistics (which always has uniform background) is a versatile solution with nice readability in 100% of possible cases.
Also I agree that progress bar is the UI solution that allow to visually estimate remaining time, and at the moment when the progress bar disappears, it clearly indicates the completion of the task, so you don't have to read anything anywhere.

Current Issues

Show all visible geometry in the UV window

The point of any active element is being user-defined, if active element is changed not by user, it is equal to "losing active element".

Looks interesting.
So 4/256 value will represent 4 pixels per 256 pixels side margin value, and all mipmap padding sizes that has the same fraction?
Sounds versatile.

Looks interesting!
I guess, the next step value conversion to pixels?

Okay. I thought that +/- for filenames will be replaced with +/- for filepaths or so.

In rB78bfaf1a4fe1a71408e4dab7268b1af1ed1b88f4#354979, @Dalai Felinto (dfelinto) wrote:

In rB78bfaf1a4fe1a71408e4dab7268b1af1ed1b88f4#354962, @Paul Kotelevets (1D_Inc) wrote:

Filepath, not filename?
For filenames it was actually useful as well.

Is there a place in particular (i.e., a property) for which you miss having this?

Filepath, not filename?
For filenames it was actually useful as well.

I used Texel density checker addon to calculate UV filling precentage, can be useful.
https://github.com/mrven/Blender-Texel-Density-Checker
Also I want to mention that the default (convex shapes) method is more useful during cutting UV seams and unwrapping process, because it gives a clearer picture how your resulting islands looks like (individual shapes of islets after a convex packing are better humanly recognizable than after a concave one). So it is reasonable to use the default convex packing during UV unwrapping process to check islands shapes and use concave packing at the end to form the final result.

In T68889#1423173, @Chris Blackbourn (chrisbblend) wrote:

Nice! Loving the fireplace! I've got both models in the debugger, should be a good challenge :D

In T68889#1422526, @Chris Blackbourn (chrisbblend) wrote:

@Paul Kotelevets (1D_Inc) Can you share that geometry in a .blend file?

In T68889#1422526, @Chris Blackbourn (chrisbblend) wrote:

@Paul Kotelevets (1D_Inc) Can you share that geometry in a .blend file?

Comparison with Packmaster addon, in case if it will be useful.

In T68915#1422004, @Nebulous (Nebulon1212) wrote:

I think maybe there's some over-thinking going on here.

The example from LightWave is simple and it works. Speaking as someone who has worked in the trenches and used to be part of the film union, I can tell you that a typical case for light-linking is not as complicated as some might think it is.

Usually, you just need to exclude a wall from the light solution. The approach of unchecking the offending light from the object's properties panel is the correct approach.

Starting from the light properties and unchecking objects is a backwards approach.

Keep in mind that the majority of the features in LightWave were direct requests from Hollywood studios for getting the job done efficiently, and yes -- that includes Digital Domain.

In D15395#426119, @Guillermo (guishe) wrote:

Hi @Paul Kotelevets (1D_Inc).
What the patch wants to add is a scroll similar to the properties tab, to prevent categories from becoming unreadable.
With the current behavior you can use the [mouse wheel up/down] to navigate between categories, in the patch the scroll is added instead. This navigation doesn't disappear at all, now in the patch it can be done by holding [ctrl] and [mouse wheel up/down]. This navigation is not entirely new, seeing the code I saw that in the panels you can navigate between the categories by pressing [ctrl] and [mouse wheel up/down].

I have some doubts about this concept.
What controls are proposed for scrolling tab list and switching between tabs when mouse hovers it? (they are not clear not from description, not from video)
I would probably prefer current mouse scroll behaviour for switching tabs as the default one (because it allow to navigate faster) but with the ability to clearly see active tab's name in the top of N panel to see which tab is currently opened. This will allow to reduce reading and searching vertical text in tabs, and will also make it less important when it is collapsed or shortened with max tab length.

But I also like U+2BC8 because of slightly bigger spacing

25B8 looks accurate

In T99275#1396722, @Santy Berrones (santbg) wrote:

I was looking for reference on how other systems work and C4D works with 1 click to select everything in a hierarchy.
🫣 Don't judge me just looking for reference to clarify an idea.

In T99275#1396560, @Julio Cargnin Pereira (juliocargnin) wrote:

Glad to see this taking shape! Thank you!

There is one little suggestion I'd like to request:
when extending the selection with SHIFT key could we have it implemented in a way that the last selected click make the target active instead of keeping the first as the active? I think this would be more consistent with other areas in Blender (set active on last click). What you guys think?

I think bisect need 1pt (elevarion) 2pt (vertical plane by edge) and 3pt (full plain) snapping
https://youtu.be/xS7KMHCms7U

In T99275#1393315, @slwk1d (Slowwkidd) wrote:

Even though I still think that selecting the hierarchy with just 1 click on the whole item (icon + name), and not just the icon would be even more intuitive

Gizmo persistent visibility originally was one of the well known industry standard issues (unnecessary visual noise that influence composition) which was succesfully fixed in Blender.

In T99275#1392620, @M. Grady Saunders (mgradysaunders) wrote:

Here is main routine.

In T69577#1392484, @Ryan Inch (Imaginer) wrote:

In T69577#1392122, @Paul Kotelevets (1D_Inc) wrote:

There is another potential issue I found with collections selection.
Ctrl+Shift+LMB supposes to add/remove nested (the entire branch) to/from a selection, but it fact it inverts existing one.
If some nested collections are already selected they inverts their state instead of following root collection's state, which can be confusing, especially if the branch's root collection is collapsed.
How do you think?

Yup, that looks like a bug. I'll see what I can do.

In T99275#1392146, @M. Grady Saunders (mgradysaunders) wrote:

Apologies for the radio silence, was out and about over the weekend.

No worries, there are no deadlines in such kind of tasks anyway)
Hierarchical functionality can ve solved only at the moment they solved.

In T69577#1391923, @Ryan Inch (Imaginer) wrote:

Yes, I can confirm, but this isn't a new bug. Linked (cumulative) collections have never been displayed (supported) properly, and it's not an easy bug to solve, but I suppose it's time to tackle it.

Aw, okay, a known issue then. Probably, I forgot about it.

I hope gizmo visibility behaviour when gizmo is used will be optional as well.

Hi! Nice update, it is very useful to have color information corresponding to the outliner!
One of possible further Specials can be "Paint objects colors from collections colors" to have the ability to view painted collection distribution right in the viewport by using object color viewport shading.
As a result it will look something like that:

In T99275#1390191, @M. Grady Saunders (mgradysaunders) wrote:

See the following video.

In T99275#1389842, @M. Grady Saunders (mgradysaunders) wrote:

In T99275#1389496, @M. Grady Saunders (mgradysaunders) wrote:

Having read the specs laid out by Julian and Pablo, I've revised my diff for this task. I'll update with arcanist momentarily, after I clean things up a little. But here is a quick demo (now with voiceover)

In T99275#1389558, @Julien Kaspar (JulienKaspar) wrote:

@Paul Kotelevets (1D_Inc) I agree but I think for the sake of this task we can ignore this inconsistency. If the keys are swapped or not doesn't affect the functionality of this design, and merely follows existing design decisions.

I'd propose to have a separate discussion about the Shift and Ctrl key assignments.

Hm.
I am not agree with the original Ctrl and Shift selection assignment in the outliner - it was assigned in the way it contradicts to the rest of Blender, and probably should be swapped.
For example,

• Shift is originally used for adding/removing individual items to a selection, for example, in object mode, edit mode, dope sheet, curve editor, node editor and so one.
• and Ctrl is used for range selection, for example in edit mode, dope sheet and curve editor.

In T99275#1386006, @Santy Berrones (santbg) wrote:

You might consider that a single click on the icon selects everything in the Collection, and to deselect click on the empty space.
Unless there are any drawbacks it is more intuitive and has no hidden hacks or shortcuts.

Yes, it was discussed that dynamic context management system paradign doesnot fit light linking, since names are important there, so context of this system should be static (name-based).

In T99275#1382614, @Pablo Vazquez (pablovazquez) wrote:

In T99275#1382603, @Paul Kotelevets (1D_Inc) wrote:

Maybe something like Shift+doubleclick?
How about deselecting? Maybe something like Alt+doubleclick?

That could work.

Nice topic. A couple of questions though:

Any temporary solutions has a problem of crating legacy that is always hard to enhance and maintain.

As a result of a discussion it was decided to make a better explanation of a problem from user perspective.

As a result of a discussion it was decided to make a better explanation of a problem from user perspective.
Link to the post

In D15028#405023, @Germano Cavalcante (mano-wii) wrote:

Also, if you are going to provide such a massive weapon as "fake everything", should not you at least provide the "unfake everything" defuse?