@Martin Capitanio (capnm) it does work boundary of course (otherwise the "preserve boundary" option would not be there).
The issue here is that the mesh is non manifold …
The Suzanne disagrees:
The issue here is that the mesh is non manifold. Even the voxel remesher has issues with the mesh provided.
Hi @todd doehring (tcdabemis) : both Never and Fast seems to be working fine here.
EDIT: I may have made an error in last post. 'Never' seems to be working but not all the time. I can't figure it out, will keep testing.
I noticed that this task is now 'closed', but the original issue with 'never' is still not working and using 'fast' makes little difference.
I made a first pass at reviewing this. Several minor things to change per my comments.
I think this code is about ready to merge, though we should wait until after the 2.81 stabilizing branch has been made (supposed to be Oct 10).
Sat, Sep 21
Any hope to see this done one day ?
Not sure what means "to never use backfacing polygons"
If I turn backfacing off polybuild still moves only the backside
On "much simpler example with less geometry" the problem is not so obvious
The fix caused another bug, reverted for now, will look at it again next week.
Fri, Sep 20
I also confirm it ( T70103 Can't select extruded Vertex ) in Linux-5.0.0-29-lowlatency-x86_64-with-Ubuntu-19.04-disco 64 Bits X.Org 4.5 (Core Profile) Mesa 19.0.8
Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-09-20 13:18, hash: rBd1cc340e5669
I reproduced it with a Quadro RTX 6000 on Ubuntu 18.04.
Cant actually reproduce on my end (linux, 970m, 435.21 drivers -- not sure if this is a windows thing or the rtx cards?), but since this is confirmed and a regression, setting this to High priority...
This is caused by rB3a08153d7a842b7ab1e40a9048730e1a3ddab5f7.
It's really weird, I run the remesh operator in a Debug and a RelWithDebInfo build with ASAN. In all cases the crash seems to be caused by some code that handles audio.
ASAN shows a warning that might be related: /extern/quadriflow/src/hierarchy.cpp:272:48: runtime error: division by zero
This seems to be fixed in current master.
(Have not hunted down the exact commit, but there have been many changes in this area since...)
Confirmed, checking... (was still working in rB1e375ab5a104...bisecting...)
Thu, Sep 19
Yeah, there's always the battle between convenience (having properties everywhere they might be useful) and organization (keeping only a type of property in a single place.
I can see the issue. I guess the solution is to never use backfacing polygons? Can you try to create a much simpler example with less geometry that shows the same issue? That would probably make fixing it easier.
OKi, summing it up we all agree that this tool could be improved (I agree and see the usecases for this).
But we should also note that this was always working like that, so stating something like Worked: 2.80 is just wrong...
... And to complement a Blur All Vertex Colors function, a Sharpen All Vertex Colors function would also be very welcome.
I agree with @Wo!262 (wo262) . Renaming the tool to something like 'Smooth edges' would avoid confusion.
My understanding is the same. It's used to blur face corner colors into all the adjacent corners, but it doesn't actually blur like in Weight paint or with the blur brush.
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..
Wed, Sep 18
@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.