I think I can still reproduce this issue, eg. changing the "Dress" property in hailey.blend above. q_q Do I re-open?

Some of those sound like symptoms, not the root cause.

I can think of cases when I'd rather not have to bother adding my operator to a menu just to make it searchable, particularly when developing the addon mainly for myself or my friends or my team, or when the addon is a single operator that doesn't really belong anywhere in the UI, etc. Is there really no other way to allow us to set shortcuts from the search menu? How come? Are we sure we're fixing the root of the problem here?

Probably same underlying issue as T73593?

@Pablo Dobarro (pablodp606) Can you comment here on whether these issues really need to wait until Attribute Edit project progresses? To me it feels like that could be years - that's years of 7 extra actions to enter and leave weight paint mode. (On top of the already standard 3-5 actions.)

Here is a fairly simplified file and video:

Sculpt Mode, Texture paint and Vertex Paint will run on the exact same code

Update on user perspective:

It's been pointed out to me this may be a duplicate of T56635, but that one was closed as resolved. Maybe this should be merged into that one, and that one be re-opened? I'm not 100% sure it's the same issue, but definitely seems very similar.

It seems that a version of this functionality has made it into master, as the panel split operator is now cancellable, which is great! Whoever did that, thank you!

Ideally the renaming that occurs is not mindless and "just because", but made to improve the quality of the code - which in turn will make it easier for new and existing developers to understand the code, which will result in a better Blender. Ofc your point of increasing workload for branch/patch maintainers is valid and I can't speak to that, but I don't agree that improving code quality does not equate to improving Blender.

I offered a similar solution once, but Campbell raised a valid concern: D6101#141517

I think the right steps to see the issue would be:

You make a good point. I had a feeling my bounding box idea was not very smart. In that case, I don't mind the manual input. :)

I wonder if it wouldn't be possible to squeeze this scale factor out of thin air, eg. by taking the size of the object's bounding box before parenting. (Since inherited scale does not cause the issue to begin with) - Or maybe something smarter than that.

Although this behaviour is confusing, I find it quite useful, and often rely on it while weight painting.

Ah, I think I was trying face selection mode not vertex selection mode. Can repro now, my bad!

Is the goal here to make sure that the object's two longest dimensions lie horizontally, and its shortest axis vertically, such that the object is as flat as possible? I don't know much about 3D printing, but that would make sense to me. (I'd want to 3d paint a gear cog lying down rather than standing up) If that's the case, that could be implemented as a single toggle button with some logic and maths underneath. But I could be totally missing the point here.

Can also confirm, currently "Show Bone X-Ray" seems to actually prevent bones from displaying in front of the mesh, even when the per-object "In Front" option is enabled.

I think this was probably fixed by rBf1ac64921b49, at least I can't reproduce it any more.

Thanks a lot for the fix on this! An improvement I wish for, is if the modifiers that are not being considered by painting, could just be disabled entirely while in weight paint mode.

Tested, this seems really neat. Can see this being pretty useful, especially thanks to rB966383138a42. It came up in chat that it would be nice if x-mirror was taken into consideration by the operators (consider opposite of selected bones as selected, even if they aren't), but to me that's a "nice to have" and not essential.

I have no strong feelings, just a slight preference to displaying bone relationship lines in object mode(ofc ideally regardless of bone drawing type). I think relationship lines are mostly useful when importing an armature, often resulting in a bare skeleton with floating bones with random orientations, so in those cases seeing relationship lines without having to enter pose mode is nice I think.

This is not a bug. For user help please use other forums such as https://blender.stackexchange.com/.

Not a bug. In the FBX import dialogue, under Armature settings, enable "Ignore Leaf Bones" option. This is necessary for compatibility reasons (and FBX has a lot of compatibility problems)

Looks like he did a bisect so must be right. Interesting. Will look into it after the new year's.

Hm, I don't think that could've been caused by this patch.

Fixed some errors (due to changes in master and some possible merge mishaps) based on chat with William.

I guess the "Additive" checkbox on the Copy Scale constraint might be a good reference here. "Additive" is descriptive, and the tooltip says that it's for 2.7 compatibility.

@Pablo Dobarro (pablodp606) No wonder unified brush pressure is not being displayed properly when you removed unified brush pressure 3 days beforehand in rB9251b077203c763f1be83505ed0a4d1e19dab947. Could've saved me a few minutes just mentioning that, really.

Hmmm, at least for my use cases, it would definitely be too much hassle to manage the locks. Just the face of my character has 278 vertex groups. But I see your point about this feature only relating to display and not actual behaviour. And sure enough, if there is someone out there who uses vertex group locking, this will be useful for them. I'm just not one of those people.

I'm happy to start brainstorming a design for a node-based replacement for the constraint system, but it would be a massive project, and there are no developers who can invest that time in the foreseeable future, so it would leave T70805 unfixed for the foreseeable future.

I can definitely see the usefulness of this feature, but I think it's a bit hard to grasp, and relying on vertex group locks is a fatal flaw because they are way too slow and unwieldy to manage.

Thanks a lot for helping out, I'll take a look at the final issue tonight.

Your build is 4 months old. I believe this was fixed by rBacd98599ffe4. Please check with latest daily build. Closing for now, but if the issue is still present you can re-open.

From a user perspective this seems good to me. I understand that After Original now avoids skewing when the parent is scaled non-uniformally, and how that technically breaks backwards comp. The reason I think that's fine is because I think as far as any user is concerned, the old behaviour felt unintentional to begin with, and we don't need to keep backwards comp with bugs. Also I'm pretty sure most people will want to use the new "Before Original" option, since it's more akin to how other (non-locking)constraints already work eg. Transformation, Copy Location with offset, etc. For the 0.01% that want After Original, the new scale inheritance is probably better than the old skewing one, although I don't have any strong feelings about this.

Hesitantly re-opening this.

What is the purpose of this task? Are you planning to implement this yourself or is this a feature request? The latter doesn't belong here.

Although the screenshot and blend file are the most important and much appreciated, the description of the issue is lacking. But, if it is fixed in a newer version like the title states, then... then it's indeed fixed. So there's no point in reporting it.

Forgot to mark this as not ready for review. Still want to finish this, but hard to find time as of late.

Afaict, Bone.hide is actually the value used for pose mode hiding, and not for edit mode hiding. For Edit mode hiding there's EditBone.hide, which is writable, although only available when the armature is in edit mode.

Perhaps the same root cause as T68352.

Please submit a complete report. Two sentences is not a bug report. It's working as intended on my end.

I wonder if I'm likely breaking anything by moving BRUSH_ABSOLUTE_JITTER out of Brush->flag and into its own enum? @Bastien Montagne (mont29) if you could take a quick look

• Rename Brush Cursor to Brush Tip
• Fixed an issue where Grease Pencil Weight Paint/Sculpt wouldn't have a Brush Tip panel when the active tool in Draw mode was Eraser.

• Update to latest master (new anti-aliasing option in 2D paint)
• Nuke all trailing whitespace via ^[ \t]+$
• @Antonio Vazquez (antoniov) GreasePencilStrokeEditPanel seemed to be unused code so I removed it on Bastien's request, thought I'd let you know.
• I turned the magic number into a proper enum value, although I can only hope I did it in the best way? If yes, this could also be done in a few other places, but maybe in a separate clean-up patch.

As an advanced user who doesn't use workspaces because lazy, and I do create and remove panels all the time, I tested this patch and really like it! Having the instant feedback of seeing what's in the duplicated window, which is what we lose with this patch... was never useful. If anything, this is better, because it doesn't squash your existing panel(which also represents your new panel) while you're creating the new one. I'm usually switching the new panel to a different type anyway, so I don't care about its content at all.

Trying to search for addon authors names on phabricator, CC @Vilem Duha (pildanovak) Can you take a look at this?

I'd still rather differentiate those things as Mouse Cursor vs Brush Cursor, rather than Brush Tip vs Cursor. Brush Tip means other things in other software, and even ignoring that, to me it feels like it implies that it affects the behaviour of the brush. But, if you guys want it to be Brush Tip, it will be Brush Tip :P I'll try to find time to implement this and Bastien's feedback in the coming days.

Could you clarify what addon this relates to?

I'm not an expert on Eevee but this just sounds like a reality of real time rendering. You have to deal with shadow map resolutions on any other real time renderer, including UE4.

Closing this because feature requests go to https://blender.community/c/rightclickselect/ and are generally preferred to be more than 9 words.

Please submit a valid report following the template and filling out all the required information.

Please submit a complete report including a useful title, reproduction steps, and a blend file where we can easily reproduce the issue.

I believe this is still being iterated on (D6020), and although I can't find this in writing anywhere, I heard that there are plans to bring back the old behaviour as an option. @Pablo Dobarro (pablodp606) can you confirm? (And close, if you think it should be closed)

I hope the right procedure for these situations is to set it to confirmed and assign it to the most handsome admin.

Could you please upload a blend file of just the minimal node setup that you can reduce the node setup to which still causes the crash?

• Update to latest master. Someone hacked yet another grease pencil tool setting into the brush settings... In Draw mode, stored in sculpt settings RNA... Interesting.
• "Smooth Stroke"->"Stabilize Stroke"
• Updating from Arcanist now so Phabricator's file context features should work.