I can confirm the bug
Sat, Jun 24
Fri, Jun 23
I got the problem. I am currently looking for the solution in code. For time being, you can manually select the extra vertices and press Ctrl + X to merge it in Edge. for first scenario. For second case, It will look into details.
Wed, Jun 21
Thu, Jun 8
Mmmh… in fact there is no bug here, even though the result may not be what one would expect off hands.
Wed, Jun 7
Wed, May 31
Edge group for bevel could be better than vertex group
Someone else requested something similar to what you suggest -- just that when some vertices get blocked, they stay there and the unblocked ones continue to move. Maybe this should be the default, but I'd like to get some kind of consensus from artists before changing. As you say, it could be an option, but there is a lot of pushback on Blender devs from Ton not to add too many options to tools, but rather make them smart enough to "do the right thing" without options.
Mon, May 29
I think what I'd like to see is a threshold that prevents close vertices from overlapping without blocking the movement of vertices that are far from each other. I suppose something like a weighting that diminishes the bevel effect for close vertices.
Something like in the following which shows how Edge-Slide has less impact on close vertices but a large influence on vertices with larger distances. I think this would have to be an option though since it would best suit organic or choppy shapes like rocks. It would likely be inappropriate for machined surfaces.
For a much simpler testcase, apparently demonstrating the same problem -- non-solid objects resulting from boolean difference with BMesh -- see T51236 . Again, "Carve" produces the correct result, "BMesh" doesn't.
The problem is that the clamping is very naive right now: just clamps to the min of the half-length of all the edges involved in a vertex bevel. In this case, that means it clamps to the half length of the vertical edge, which doesn't even have advancing vertices on it, and it is a lot shorter than the edge that the vertices move along. It is a TODO to do much smarter clamping, but I'll spend some time now to see if cases like this, at least, can be improved.
Another requested bevel clamping change. See T50994. Requester would like clamp to apply to edges individually rather than globally. Could be consider as breaking backward compatibility for 2.8. Or an option (but we dislike adding too many options).
May 29 2017
But shouldn't a mesh generated by a fluid sim be closed and non-self intersecting?
@Howard Trickey (howardt), mind having a look here? Thanks! :)
This is not about depsgraph, it is about some internal conventions which depsgraph have nothing to do about.
Thanks for the report, but nothing to be done here currently really, this is known limitation of boolean ops - they need sane meshes as operand, that is, meshes that are closed, not self-intersecting, etc. Better handling of corner cases and complex situations is considered a TODO currently, not a bug.
May 28 2017
May 26 2017
in bli_winstuff.h we replace the stock fseek function with a 64 bit version
May 25 2017
From an end-user standpoint I would expect the object to curve along the visible (final/deformed) curve rather than its base geometry. If that was unwanted I could still duplicate the curve and remove the shrinkwrap modifier. With the current behavior I am prevented from choosing a possible option.
I think it's more a design problem than a bug. It's one of the area in Blender that doesn't follow the philosophy of "don't think for the user". The depsgraph will decide in which order the modifiers should be applied and sometime fails at finding the right order, because in some case their are several possibilities, all valid and it's more a question of artistic decision.
The solution to it would be to have a way for the user to order modifier execution. The everything node system will solve it on the long term. In the meantime, it could be solved with a scene stack of modifiers instead of being limited to object stack.
The results are the same regardless of the Shrinkwrap modifier mode. The curve with the shrink wrap gets shrinkwrapped, but the objects that deforms along this curve doesn't follow its shrinkwrap deformation.
If you use project mode in Shrinkwrap modifier, I think that you have to appoint axis.
May 24 2017
May 23 2017
May 22 2017
I like the idea to add slider for the particles. It is quite usefull, when you want to give an offset for origin of the particle object to put it below/above emitter's face.
This is not a feature. Particles are simply ignoring the modifier options when doing the lattice computation. Disabling the lattice modifier should stop it from having any effect on anything on that object.
May 21 2017
Particles deformed by lattice is a useful feature. Especially for emitter particles with physics, that allows to easily define flows for particles with erratic movements.
May 19 2017
May 18 2017
The error above somehow made me suspect if it is a problem related with the compiler used to build the program. So I tried the currently available latest x64 build (102394a).
No crash log appears to be generated. A "blender_a05604" temporary directory gets created, but it's empty. Nothing related in the parent temp directory or in the directory of the blend file gets created either.
Was crash log generated? Please upload if it does. Thanks.
No crash on OSX, same build.
May 17 2017
May 16 2017
May 2 2017
Yeeahhh a big thank YOU Joshua !
There are currently location + rotation keyframes on some of the objects (frames 0 and 33). Try removing all keyframes before fixing the position of all the objects.
May 1 2017
Apr 20 2017
I have resolved the issue via a post at Blender Stack Exchange: To make precise dimensioning possible, one has to change the radius of the control points of the curve from 14 to 1!