I have problem with building of this patch on Linux (CentOS) with GCC/4.9 or GCC/7.1 with blender_lite.cmake. I have got the error message: "uchar.h: No such file or directory" in BLI_sys_types.h and in wcwidth.h. After fix it I have got the next error message: "unknown type name size_t" in wcwidth.h and wcwidth.c. After changes on my site in BLI_sys_types.h (uchar.h -> add typedef like for macos), wcwidth.h (size_t -> unsigned long long int) and wcwidth.c (size_t -> unsigned long long int) it works fine.
Voxel-based Remesher works on volume, so pure surfaces won't work for sure. No bug here.
There is no bug here, improvements are always possible (patches are welcome btw), but no reason to keep this open.
It's sometimes hard to know, if something don't has the functionality yet or is a bug. :)
As a creator I just expect in some cases an behavior that is consistent.
Not really a bug, bug could be a nice improvement, see D6869: Fix T73871: improve assignement of material to selection in multi object editmode
Yes @Ankit (ankitm) , it also works on selected text. I have attached a video demonstrating the same.
would it work if you select the whole text? So that you can change the spacing between all characters?
Sat, Feb 15
Fixed issues with the Active Element pivot in edit mode. Added the property to more transform operators.
Hi! Yes, I can reproduce all of them.
I'll make 4 separate reports then, or for the Graph editor one it's not needed?
Fri, Feb 14
This isn't a bug, and it's actually a bug fix that caused this change. There shouldn't be "individual origins" because all of the vertices are connected by at most one edge.
Thansk for the report.
I tried to reproduce each of the problems but I was only able to replicate the "Graph editor Extend (TIME_EXTEND mode)".
Simplified version of the first file:
The fact that the center vertices of the cylinder coincide with the top face of the cube is critical. Possibly related to T68144.
Thu, Feb 13
My initial diagnose was incorrect. I initially thought that isect_bvhtree_point_v3 gave the wrong result because the it found two intersection points that were so close together that they were incorrectly considered to be identical. The actual problem is that the ray exactly hits an edge of the cylinder, which is not recognized as such.