Hi and thx for the report!

Largest difference I can find is 0.00062 m (on those 4.04221 m x 4.04216 m meshes).
Thats a factor of ~1/6500.

UI Mafia: should we consider this a High priority (since it is reported so often)?

Merging this one into T67805 (even though it is a bit newer -- but it is also a bit more general since it also covers popups...).
This has now been reported quite often, maybe we should consider making it a High priority?
Anyways, lets continue discussion in T67805...

Just noticed that T67805: Mouse pointer/cursor doesn't update when changing tools via shortcut or pop up menu is probably the same

In T74070#877450, @Frankie Hobbins (Frankieh) wrote:

I tried remapping images directly to the shader nodes and they appear in the FBX file but nothing seems to get picked up by unity.
My hope is now if we had Blender exporting the path to Metallic or Roughness images though the Separate RGB (and actually we need an invert node for the roughness) node we could go to Unity and tell them to assign them it to their mask map.

I dont think it would make a difference if paths were exported even with the Separate RGB still in the nodegraph (this Separate RGB will never be included in FBX, afaict FBX has no concept/knowledge of shader nodes really, so you'd have the same texture hooked up to Metallic and Roughness in the FBX -- and this is what seems to already fail in Unity...)

Hi Hussein, this place is tracking bugs in blender.

Thx for checking, not sure if I can sink more time into it atm though... could you take care of T74044 then?

This issue is coming up once in a while.

In T74041#877400, @Peter Fog (tintwotin) wrote:

It should only be in the Sequencer Preview Sidebar Tab called View - as it is only printing data in the preview and is executed when the playhead moves.

"View" could be good, yes (if it would really work to get the metadata from the preview...)

OK, I am not sure how this would ever work in the Video Sequencer if we try to get the ImBuf from sequencer_ibuf_get (as this gets rendered and there is no metadata on the newly rendered ImBuf)...

• Regarding the panel being everywhere in the VSE: not so very sure anymore about putting it in the "Strip" tab, this will not display info for the selected strip, but for what you see in the preview (ImBuf)... so maybe makes sense to have it in all tabs?

Or put it in its own "Metadata" tab?

• Regarding the Panel actually being empty: seems like we are not displaying the original ImBuf, but the cache or something? If I load in EXRs, then sequencer_ibuf_get will still get me a PNG? Still needs more investigation...

Can confirm.

Caused by rBa33b261473e9: Fix T71455, T73852, T73860: Transform, Redo doesn't work properly in time…

Confirmed, checking...

Hi, the problem will be solved in T67805: Mouse pointer/cursor doesn't update when changing tools via shortcut or pop up menu, no need to have multiple reports open for the same issue, feel free to comment there, thx.

Please have a look at the discussion here T74025: vertex weight intensity in the gradient weight tool doesn´t work
(in short: you are right about the previous brush governing the behavior of the Gradient tool)

avoid setting r_path early

Can confirm, checking...
Also getting the following:

BLI_assert failed: /blender/editors/transform/transform_mode_edge_slide.c:113, edgeSlideFirstGet(), at '!"Should never happen, at least one EdgeSlideData should be valid"'

In T74025#876975, @Ruben Dario Espinel Mora (Rubens91) wrote:

Yes, actually the vertex weight when I change the value to 0 or 1, doesnt seems to have effect, it´s very confusing

At the current state it is confusing, yes.

Gradient Tool in its current state is not very user friendly:

• generally this accesses previously selected tools brush as it doesnt have its own brush (so it looks like it has its own settings for strength/weight, but those are from an 'alien' brush)
• when Unified Weight is turned ON (default) the tool actually works with the Unified Weight (set on some other brush, e.g. the Draw Brush), but doesnt present you with that value in the UI (bug!)
• when Unified Weight is turned OFF you are actually tweaking the weight setting of the previously selected tools brush (the 'alien' one) -- this causes confusion (it doesnt affect e.g. Blur, Average or Smear since these dont have weight capabilities)
• this is even worse when tweaking the Strength, you are actually tweaking the weight setting of the previously selected tools brush (the 'alien' one), this affects Blur, Average or Smear (and Unified Strength is OFF by default!)

Can confirm, seems to use the previous selected tool setting, checking...

This has been reported before, see T67805: Mouse pointer/cursor doesn't update when changing tools via shortcut or pop up menu, will merge these reports...

Might be because the context menu (VIEW3D_MT_edit_mesh_context_menu) does some more fancy stuff (counting selected faces etc.) which the "regular" one (VIEW3D_MT_edit_mesh_faces) doesnt do - yet.

In T74006#876755, @Richard Antalik (ISS) wrote:

I checked this with limit scale modifier on maximum X field. It worked in 2.79

@Richard Antalik (ISS): this doesnt seem to work in 2.79 either?
Anyways, I'll see if I can come up with something...

Also cannot reproduce here

Can confirm, checking...
Looks like this is true for all options on bone constraints?

Thx for getting back.

Looks like this was included in rBcfdb5b9a8b07: Fix T73941: Custom normals from normal edit modifier ignored by further… already

1--In the options of the bone constrains, the drop only selects the armature, and the bone must be searched among the list of bones. No exist drop selector bone.
1-- create armature and add constraint in a bone / use drop for select a bone / object armature is select and not exist drop for select a bone

• ATTR_STD_VCOL -> ATTR_STD_VERTEX_COLOR
• add OSL

Isnt this the same as T67805: Mouse pointer/cursor doesn't update when changing tools via shortcut or pop up menu?

Hm, if nothing is provided in the Vertex Color Node, then the active_render (Camera icon) kicks in (so watever you choose there will be rendered - in Eevee but not in Cycles)

This behavior is also inconsistent with the behavior of custom normals set via a weighted normal modifier. When that modifier is used, it seems to affect further modifiers appropriately.

Not sure about this, can you provide an example file where this works?

address review by Campbell

@Ajlan Altug (jacobo): If I apply the the subd modifier on LIGAMENT CUTTER and disable the subd modifier on LIGAMENT CUTOFF this renders correctly:

Can confirm in this particular file.
This is quite complex though, can you come up with a minimal example file where this kicks in?
(will also try a bit more to reproduce this from scratch -- which I wasnt yet...)

Looks like the is no vertex color layer actually selected in the node?
(you need to pick one)

Cant get this to work either (havent looked at mantaflow in depth yet though)

Yeah, T73252.zip suvives like I said. Can have a look again tomorrow if I can come up with something

Think we can close this then?
(feel free to comment again if you have found the offending Addon or preference tweak that caused this...)

When "really" constraining to X, the t->spacemtx (which gets dumped into t->orient_matrix) is not negative

In T73852#873875, @Alessio Monti di Sopra (a.monti) wrote:

Ah, I just noticed one thing regarding the mirroring (that's also valid for T73853): it doesn't happen when constraining the transformation to the x axis

Working fine here.

CC @Germano Cavalcante (mano-wii)
CC @Campbell Barton (campbellbarton)

Guess T73853: Transform: Redo does't work properly with NLA "Move" transform mode is related