For developers working at the Blender Studio to organize Blender bugs and tasks reported by artists.
This should be fixed now along with other CUDA baking bugs.
Mon, Mar 11
The reason is that vertex groups and shape keys are actually part of the Object to some extent, not the object data. So with just a Mesh pinned these can't be edited.
Fri, Mar 8
Thu, Mar 7
Wed, Mar 6
Thread 25 "blender" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd57fe700 (LWP 20388)] 0x0000555558323336 in subdiv_ccg_recalc_modified_inner_normal_task (userdata_v=0x7fffffffd0d0, face_index=10, tls_v=0x7fffd57fdb60) at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/subdiv_ccg.c:908 908 const int num_face_grids = face->num_grids; (gdb) bt #0 0x0000555558323336 in subdiv_ccg_recalc_modified_inner_normal_task (userdata_v=0x7fffffffd0d0, face_index=10, tls_v=0x7fffd57fdb60) at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/subdiv_ccg.c:908 #1 0x00005555586921a9 in parallel_range_func (pool=0x7fffcbf64008, userdata_chunk=0x7fffffffcfb0, thread_id=2) at /home/zed/programmering/blender_master/blender/source/blender/blenlib/intern/task.c:1038 #2 0x000055555868f8d5 in task_scheduler_thread_run (thread_p=0x7fffd89f2068) at /home/zed/programmering/blender_master/blender/source/blender/blenlib/intern/task.c:439 #3 0x00007ffff63993c3 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff134e3ef in clone () from /lib64/libc.so.6
@William Reynish (billreynish)
But ... most tools/brushes are not really compatible either in the settings or in how they are used. And these differences make sense.
You can't use textures or colors for weight painting since these are useless for that mode. You can't define options like weights, auto-normalize and multi-paint for vertex painting for the same reason. Some settings are not available for the brush in one mode or another which makes any brush setup in most cases useless and unnecessary to share between modes (especially vertex paint & weight paint).
Tue, Mar 5
Why not simply use different brushes if you don't want to use the same one?
It's related to hair, happens in a simple scene just moving the object:
Mon, Mar 4
As this is from the studio, I'll mark this as confirmed.
Fri, Mar 1
please, duplicate and also istantiate
The naming for delete is pretty clear: "Delete" for the what you selected and "Delete Hierarchy" for the entire Hierarchy of the selection.
"Duplicate Linked" doesn't imply the hierarchy part. It could just as well be the default duplicate linked operator for objects.
Naming it "Duplicate Hierarchy Linked" is clearer but maybe too long?
Sounds good I think with those new names.
I believe that this can be implemented with the distinction of direction in which the selection tools were executed. AutoCAD and Rhino 3D have this feature where users can select either only completely inside the selection area or anything that intersects the selection area. Left to Right triggers the first and the RIght to Left triggers the latter.
- Duplicate Linked
- Duplicate Hierarchy
@Dalai Felinto (dfelinto) Just tried it out and it works great! One confusing thing is the name "Duplicate Collection". It implies that only that collection will be duplicated instead of the entire hierarchy.
I think overall the naming and tooltips are becoming a bit confusing but that's perhaps a different issue.
I end up removing the original operator. It was indeed useless. Now collection follows the logic of objects (as far as UI goes), so only duplicate collection and duplicate linked options.
Thu, Feb 28
@William Reynish (billreynish) Vertex could also mean vertex groups or Vertex ID, etc. I wonder how clear it would be that Vertex means Vertex Colors.
It's not clear to me that it is a good direction to have this option at all. If we do need it that seems rather low priority compared to more important bugs in the tracker.
Probably we should name it 'Vertex' rather than 'VColor', given the 'Color' is already implicit in all the other labels too.
I didn't specifically mean moving the cursor. That as a concept doesn't sit with me very well in all cases. Keystrokes are fine being tied to specific functionality in specific editors, and therefore require Blender to keep the focus in the intended area. But for example typing in the text editor or Python console without paying attention to where the mouse is, can have you pressing 237689 keystrokes in the viewport before you realise it.
I think the current behavior is by design, even if it's debatable.
Wed, Feb 27
Just discussed this with @Julien Kaspar (JulienKaspar). Seems like it's not a bug per se, only confusing behaviour emphasized by another bug.
The fact that add-ons with panels set to '.objectmode' disappear when changing modes is of course correct behaviour - the add-ons themselves are at fault for declaring they are related to Object Mode, while that's not necessarily true.
The confusing behaviour is caused by the fact that the top bar *looks* application-wide, but should have contents directly linked to the UI area and the tool that are currently active.
The actual bug is that the top bar doesn't update when it should, namely when focus shifts from one area to the other. Accordig to @Julien Kaspar (JulienKaspar), this has been discussed before, so I assume there's already a task for that?