From @Julien Kaspar (JulienKaspar) on IRC:
Getting an assert:
BLI_assert failed: /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/node.c:1741, ntreeFreeLocalNode(), at '(ntree->id.tag & LIB_TAG_LOCALIZED) != 0'
Tue, Mar 19
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?
Yes I guess that would be more useful than the current way it works but I can't remember if I ever needed that kind of operator. This would be for very specific corner cases.
As far as I can see this isn't a bug. The default select tool in the compositor has no options, if you switch to border select there is a single option.
Tue, Feb 26
Right, but part of this is because its current functionality is really that limited.
If we were to change it (e.g., copy collections as new collections, respecting hierarchy, but leave the same objects linked) it would be useful no?
@Dalai Felinto (dfelinto) I never really saw the current "Duplicate"operator in the outliner as that useful in comparison to a proper "duplicate hierarchy" or "duplicate linked hierarchy" operator.
It can become useful sometimes but ultimately isn't even that much of a time saver in comparison to just creating a new collection, box selecting the old contents you need and LMB + Ctrl dragging them to the new one.
@Julien Kaspar (JulienKaspar) what is your thought on the "Duplicate" operator? As far as its children collections are concerned?
Right now we are literally linking the old nested collections inside the new one parent collection.
(it is a bit complicated to explain, easier if you try in 2.80 without the patch even).
Mon, Feb 25
Sat, Feb 23
I can not confirm this.
No remarks. This makes sense to add.
Fri, Feb 22
@Julien Kaspar (JulienKaspar) I like the idea, and in fact got Duplicate Linked Hierarchy to work here (not committed yet). Duplicate Hierarchy is more tricky, but I'm trying to find a way to do it while keeping the code manageable.
Thu, Feb 21
Wed, Feb 20
Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.
Feb 16 2019
Feb 15 2019
This comment here (from rBc6e3a20ab60b):
Confirmed, for me this already hangs in node_clipboard_copy_exec
(probably endless loop because new node is automatically selected....)
Feb 13 2019
Great. I largely agree with the updated task description here. To me this sounds like a nice list of small improvements to make the UI clearer for this.
I have no read all of this task yet. But I think an important missing piece is improving the dependency graph so that hidden objects are never evaluated, while keeping toggling visibility fast. Users shouldn't have to worry about the distinction.
In conclusion, I think a few things are becoming clear:
@Julien Kaspar (JulienKaspar): Yes, that was simply my point too. The checkmark makes the feature more obvious and clear.
I would oppose removing the ability to set renderabilty and viewport visibility independently.
It is one of the current strengths of Blender and one of the things I really like about it.
There are several cases where you want objects visible in the viewport but not renderable. Here are a few:
@carlos (c17vfx) It's an interesting proposal but this kind of menu would be a nightmare to manage.
Imagine having to click through potentially hundreds of collections and objects to change these settings. Keeping this in the outliner makes it very easy to manage.
@William Reynish (billreynish)
I absolutely agree. The eye and checkmark/excluding should be front and center to make clear what should be used the most. Good tooltips can clear up any remaining confusion.
@Ali (Ali6): That's why I proposed to promote the hidden exclude/disable toggle as a checkmark to disable visibility in both the viewport and render. In many many cases, disabling for both is exactly what you want - it's the WYSIWYG philosophy.
Feb 12 2019
I'm a bit new to Blender but couldn't you just merge everything into the eye icon? Surely if you're disabling it from the viewport you would probably want to disable it from rendering as well? I don't see when you would need to do one or the other. I understand the disable collection from viewport selection but couldn't everything else could be merged into one?
They way those states relate to the other features are and presented in the UI is so hidden and confusing that very few people will find them, and if they do, it's completely non-obvious how they work,