That seems to be the case indeed. If the only purpose of Smooth Vertex Colors is to smooth absolute, mask-filled faces to their directly surrounding vertices, then the function works. But the tool name suggests it will smooth / blur all vertex paint, which would be much more useful, eliminating the need to manually blur everything.
hi, @Hans Goudey (HooglyBoogly), fair enough. I'll just add a pic here that shows there's still a relationship between the edges data and the bevel tool. Fortunately you can access both at once and make changes to/in both ui positions without losing the bevel operator menu. I was thinking more of the modifier tbh and grouping of related items for access in the one place.
Well the bevel active tool doesn't use the bevel weights, so I'm not sure why it would make sense to have them in the same location. Plus they're very different things-- one is the options for the operation you're about to do with the tool, and one is used to control data attached to edges.
It seems like it only works if you paint using the paint mask..
@Sergey Sharybin (sergey) want to add this to the depsgraph bug fix guide? How to proceed for race conditions in the depsgraph evaluation?
P.S.: I've tried repeating the steps I described in my initial bug report above, and even on a cube that's not subdivided, if you paint one vertex in a color, applying Smooth Vertex Colors does nothing.
Hmm... I tried your example scene, and in there the Smooth Vertex Colors tool works.
I did rB57e0e520e89b (and reading this report now I see, that I missed an optimization in vertex_color_smooth_looptag which I will fix in a bit), but cant really reproduce this operator behaving differently than 2.80 or 2.79 even.
I might be blind, but check (this should work with no mask, face mask, vert mask...)
This was caused by rB309cd047ef46.
Above commit introduced code that would skip early for sculptmode (leaving out the neccessary createTransPaintCurveVerts)...
I don't think this is a bug and more of a technical limitation.
The reason for the weird cuts is floating point imprecision. As your faces are laid exactly on top of each other the operator struggles determining what's crossing what.
I can successfully create a paint curve, but can reproduce a crash selecting one of the curve points and translating that with G, or scale it with S, etc...
I'll check on this...
yes that's correct. Bevel weights is about as far away from the bevel tool or modifier as possible. It requires looking for in the ui each time you need to use it. It always made me think, why is such a heavily relied upon bevel tool out there all lonely?
While the report is low quality, I managed to redo the bug with the attached blend file.
These are two different kinds of even.
Note that making the offset "even" can cause spikes, so we'd want this to be an option - as it is for shrink/fatten "offset even" option.
This isn't a bug, although this could be supported.
Seems to be a creative cover for 'offset edge loops slide' aka 'offset edge slide' aka [shift-ctrl + r], an implementation that has always worked this way.
If I understand you correctly, that's separate from the Bevel active tool. The bevel weight is in the "Item" tab of the viewport side panel.
what about bevel weights? should it be there in edit mode?
Tue, Sep 17
@Jacques Lucke (JacquesLucke)
I expect even distance between edges. the same way as solidify do it, for example.
even edge offset literally: edge offset from edge, not vertex from vertex as it is now.
Not a bug but wrong behaviour, as I think.
I can reproduce it, but I'm not sure if this is a bug.
This actually seems a running condition issue, likely on depsgraph end.
BLI_assert failed: //source/blender/blenkernel/intern/customdata.c:2099, CustomData_get_active_layer_index(), at 'customdata_typemap_is_valid(data)'
Full backtrace: P1102
Thanks for the report.
Mon, Sep 16
Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Videos and/or links to external sites etc. are not acceptable as bug report (they can be provided as additional information only).
Note: this can also be fixed by just adding a multires modifier and removing it immediately after...
Having the file to reproduce is still mandatory...
Also would be nice to know how exactly you are "connecting edges" (this could mean multiple different tools/operators...)
Sun, Sep 15
- Fix crash from BM_faces_join by limiting it to two faces. @YAFU (YAFU) This should fix the crash with your blend file.
- Fix calling recursion code unnecessarily when the depth is near 0.
CandleComet, thanks for your work!
Can confirm the crash here.
I definitely agree, so I'll look into it soon. I may have to remake some of that gizmo since this operator does not use a translation operation like regular extrude.
- Fix a bug causing faces to become deselected between recursions.
- With that bug fixed, cases like also work now :)
- I moved code from bmo_extrude_destrucive into editmesh_extrude_destructive so that now it handles welding and deleting faces between recursions.
- Between recursions, editmesh_extrude_destructive now utilizes a function from auto-merge split edges & faces so that cases like F7626906 work as users would expect.