Sat, Oct 14
Mon, Oct 9
I can confirm that there is a problem, here.
I had to open an Image Editor, modify Number of frames, Start Frame settings and enable autorefresh into Image Properties.
In 2.78 I can redo this, but I can't redo this in 2.79 or master e360d003ea45ee233c6f10c03ff57c956929b383
Sun, Oct 8
This a known limitation.
Sat, Oct 7
Fri, Sep 29
Found this page when I'm trying to create a lightning effect using texture nodes and a line (with many segment) with displacement modifier. Glad to know it is on the todo list.
Thu, Sep 28
Can confirm the behavior, unable to say if this expected behavior though. @Sergey Sharybin (sergey) ?
Tue, Sep 26
Mon, Sep 25
Yeah sure, I will put it on my todo for Wednesday.
Closing. This sounds like a known limitation with geometry-altering modifiers and motion blur.
Sep 22 2017
Well it seems Vertex Weight Proximity is not the problem, another modifiers like Subsurf or Triangulation placed before second Displace also break simulation
Sep 21 2017
This is a known limitation of Motion Blur that modifiers altering geometry may have an undesired impact.
Sep 20 2017
Note, this is caused by the epsilon being measured in different spaces, it's possible for the vertex not to be detected on the face, and the edge not detect intersecting.
To add to what Yury included above, if the models use Weight Paint Groups to determine the values for width and segments then multiple objects with different settings can be joined together.
Sep 19 2017
Thank You very kindly for looking into it!
Yeah, thanks @Sergey Sharybin (sergey), that was also my understanding of things.
There is no such a way to get DerivedMesh which is different from ob->derivedFinal. This is probably possible to hack via evaluation flags stored in depsgraph nodes. But keep in mind, all this subjects are being reworked in 2.8, trying to fix them in master would cause same work done twice which we'd better avoid to.
I want to drop a few cents here about the related proposal I don't see mentioned here.
I remember cédric's proposal in rightclickselect for adding Bevel Segments value for Edges Data. It could be s great feature for non-destructive modeling with a better bevel modifier.
Funny fact: if you switch source mirrored object to WeightPaint mode, it will work as expected.
@Campbell Barton (campbellbarton), this seems to be a closed manifold, without duplicate verts, Mind having a look here? :)
Corrected rB9a2f7dd77b38504d77b1b058072194496fdc91c9 - BM_verts_calc_rotate_beauty locked rotating out of degenerate cases, causing confusion.
Sep 16 2017
@Kenrick (Prototype) - thanks for looking into a fix, however this now works in 2.79.
This is fixed by rB892d304dedb60891d9e0b3091eceecb163644215
Sep 15 2017
Was error in quad check, now fixed rBfdb8e17936a0abfbb61b71ae9a0061405ab7e2c4
Using rBb94a433ca34 does the boolean correctly
Sep 13 2017
@Howard Trickey (howardt) Thanks for such a quick reply! I agree with @michael knubben (michaelknubben). The only thing that really needs to be as much centre as possible is the edge seam, as that way it would be really easy to just reunwrap the mesh and avoid any issues with those unwanted tears. The ideal would be that the UVs wouldn't tear in the first place but it's not a big deal to just reunwrap the mesh with the new seams at the centre of the bevels. I wonder if it would at all be possible to have an option within the modifier on how it would handle edge data. That would be perfect act avoid any worries about being consistent with how edge data is treated. Just let the user decide whether edge seam is split or center. Perhaps add an offset option so that if the bevel has a segment of 1 the user could offset which side the seam would move to. Just an idea, in reality I would just be very happy with just a change that put seams in the centre.
Maybe it could be usefull to clean bevel weight when applying the bevel modifier to avoid this kind of result ?
Glad to see this being discussed here. I agree with @Jac Rossiter (Jakro) that you'd want UV seams in the middle of the bevel whenever possible. Now ofcourse that's not the case with an odd number of edges, but it's still an ideal to strive for in my opinion.
As for other edge attributes, it seems to me that hard edges & bevel weight make sense being on the outside of the bevel, so as to avoid compromising the bevel's curvature (either by bevel the middle of it, or by having a sudden gap in normal continuity there).
Existing subsurf code isn't really good for sharp geometry (both vertices and edges). OpenSubdiv handles those better, but current implementation lacks proper smooth normals due to OpenGL restrictions. Those restrictions are gone in 2.8 branch, so it's possible to have high quality subsurf in there, just need some time to implement missing bits.
Thanks for your suggestion, Jac. And thanks for the clear examples in your rightclickselect post. While it seems strange to me to have a different treatment of seams for odd and even numbers of segments, I can understand your argument. What about other edge attributes (e.g., smoothness; bevel weight; ...). In your opinion, which edge attributes should go exclusively to the middle edge, which should go to all of the edges, and which should go to the outer edges of a beveled edge?
@Howard Trickey (howardt) Hi Howard, I've been running into some trouble with the bevel modifier over the last week as I move more towards VFX. I am using the Bevel modifier to produce my control loops for Subd modelling and UV as I go, ensuring that the bevel modifier has an even number of segments so that any seams I have defined will remain. But the seams don't remain when the modifier is applied. I have written up a post about this on rightclickselect to argue for a change in behaviour but have since realised I would be much better off voicing my thoughts here.
Regardless here is the post: https://rightclickselect.com/p/general/Xvbbbc/preserve-uv-seams-when-applying-a-bevel-modifier-with-an-even-number-of-segments
Sep 6 2017
Hey @LazyDodo (LazyDodo), it's understandable and agree it's not nice to get pulled in different directions.
I give up, I'm done.