sorry confirmed here too - it was the subdiv and not the dynamic paint (and I just didn't notice it because of the simplify setting *blush* )

I can confirm, as soon as I remove the subdiv modifier on the water, it doesn't seem to freeze anymore.
(Can also confirm that it seem to endlessly compute when I remove the simplify setting (so that the subdiv modifier is evaluated in the viewport).

Confirmed, checking...

since @Brecht Van Lommel (brecht) and me discussed the revival of the particlemesher in blender.chat, setting him as reviewer here.

Solved the particle issue by treating the particlemesher modifier like the dynamic paint and smoke modifiers regarding particle system copy and deletion.
Fixed some crash bugs regarding loading and saving as well as copying objects with this modifier too.
Need to deal properly with Ngons still for the mask object, like using looptris or something like that.
But i think a first pass of general review may already happen.

add an inline comment marking the area of the problem

Setting on "Planned Changes" since the particle issue is to be solved yet.

Both functions are very useful. However particle meshing should indeed be a separate modifier and submitted as a separate patch. I guess ideally OpenVDB could be used for particle remeshing too, it's probably better than our metaball code in terms of performance and control.

I can confirm this bug! Its very annoying. But it occours only, if faces are smooth shaded. If there are flat shaded, it works.

Is been almost a month now, and is not even treated as an high bug... guys I use blender for sculpting too and because of this problem I'm using a older version of the program...
I would love to get the new beta with this bug fixed. Please!

This appears to be working now, probably after Sergey's latest depsgraph and mesh API changes.

Reproduced. Blender 2.8 (18.05.2019 build)

Thanks Philipp for doing such a nice job of isolating the problem. I confirm this problem and am working on it,

Can confirm.

I can confirm. Same bug here too. Multires not refreshing properly.

2.8 Build from May 12, 2019, Win 64 bit

@Philipp Oeser (lichtwerk) nice catch. Wouldn’t it be even simpler to always reset that nearest->index directly in BLI_bvhtree_find_nearest_ex()? Keeping previous nearest distance there if provided makes sense, but I think item index should be always reset, at least I cannot see a case where keeping previous value would be useful?

Had a look at this again and here are some findings:

modifier says Hide, Mask and optimized display disabled

@Andrew Zhou (dodeqaa) for every constructive modifier it's currently converting all data to BMesh and back - even if all of the modifier's in the stack operate on BMesh data types.

In D4530#104032, @Campbell Barton (campbellbarton) wrote:

Before getting into code review or looking into details I'd like to see example uses cases for this modifier.
Otherwise we could:

• Postpone until nodal modifiers are supported.
• Make this an optional post-process for the decimate modifier. -----

All BMesh operators _could_ be made into modifiers, however the modifier system isn't designed for constructive modelling (at least not with many fine grained operations).

Hi to All:

Modifier nodes are planned, I'd rather postpone this modifier until the new system is implemented.

In D4530#104032, @Campbell Barton (campbellbarton) wrote:

Before getting into code review or looking into details I'd like to see example uses cases for this modifier.
Otherwise we could:

• Postpone until nodal modifiers are supported.
• Make this an optional post-process for the decimate modifier. -----

All BMesh operators _could_ be made into modifiers, however the modifier system isn't designed for constructive modelling (at least not with many fine grained operations).

apparently caused by rB46eb5a0b8a4f