In D14965#404137, @Pablo Vazquez (pablovazquez) wrote:

Nice feature! The term for this behavior is usually called Ping Pong.
Blender already uses that term for the animplayer feature (P key), but it's also a common term in other software.

@Pablo Vazquez (pablovazquez) thanks for your comment. I'll prepare the patch. Do you have any other comments on the info text "Loop back and forth"?

Nice feature! The term for this behavior is usually called Ping Pong.
Blender already uses that term for the animplayer feature (P key), but it's also a common term in other software.

@Matias Mendiola (mendio) If you agree with the UI, we can approve the patch.

Good Job! Code LGTM, but we need a review of Tooltips by @Matias Mendiola (mendio) and also a test by @Daniel Martinez Lara (pepeland) to be sure is doing what we expect.

Thank you so much @Howard Trickey (howardt) for that very detailed reply. I can see this issue is a lot more complicated than I had assumed, and I'm glad you were able to fix the zero-area polygons issue.

When I claimed that this bug was fixed, I was referring to the problems of making zero-area polygons in UV space. I knew there were remaining cases where the UV layout, if done by hand, could be better, but also that Blender's bevel has never so far been able to do that well, so it wasn't exactly a bug or a regression.

In case it may be helpful to someone else, you may want to bake your textures from duplicated objects that have the bevel modifiers removed. This way you can bake without gaps or other potential errors. Then on your original object, apply your bevel and other modifiers and assign the new textures you baked. If the extra generated UV seams fall along sharp edges (they most likely do), then there shouldn't be any additional vertex cost in a game engine, otherwise you can optionally clear those new seams. Depending on the required precision of your diffuse / roughness / normal maps, etc, you may be able to completely get away without having to stitch any of the torn UVs back together, but your mileage may vary. :-) However, if there is noticeable stretching or other artifacts in the material you will have to either stitch the UVs or re-unwrap after the Bevel Modifier has been applied and bake to this new UV map.

In addition to potentially stretching textures in undesirable ways, one of the destructive side-effects of this bug is how texture bakes will get messed up because of the triangular holes ripped in the UVs. Stitching torn vertices in the UV editor is unfortunately not very straight forward, and becomes quite tedious for many hard-surface mesh parts. I confirmed the issue existed since at least 2.79b, so it is not a regression. Strangely, it seems increasing the Bevel Modifier's "segments" to an even number like 2 or 4 prevents the issue of split UVs on the angled pieces in my test file, but then the straight pieces still get split UVs, and of course, UV seams are not preserved either (they also get split apart). Having unnecessary UV seams is not ideal for game assets, as the extra seams will increase the vertex cost, and having unnecessary geometry (from extra bevel segments) will also negatively impact performance. It appears the only way to currently mitigate these issues is to set all seams and perform all UV unwraps AFTER the modifiers have been applied. This is a destructive workflow and can also mean an enormous amount of re-unwrapping for detailed hard-surface models that have already been unwrapped.

In T98202#1361151, @Hans Goudey (HooglyBoogly) wrote:

If an input mesh has no vertices, it is empty and not processed by geometry nodes.

This has been reported again, see T98249: Bloated mesh data example (multires CD_MDISPS hanging around without a multires modifier) and actually I think we should reopen this (even if only as a Known Issue)

If an input mesh has no vertices, it is empty and not processed by geometry nodes.
I'm finding your file a bit confusing, but I still don't think this is a bug. Sometimes the final mesh is not recreated as an optimization, or sometimes the data types from the original are used, but it's just not really a supported workflow at the moment.

EDIT: The following information was incorrect: "Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges". It appears (at least for my test .blend file) the new algorithm in 3.2 is just splitting the bevel operation between the straight and the angled UV islands, rather than keeping the bevel on the angled island (as in 3.1). The rest of the info shared still applies, however.

Thank you so much, @Howard Trickey (howardt) for your work on this! I'm not sure if I've downloaded the correct beta build for 3.2, I have tried the latest 35e73aa3472a but it seems the issue is persisting, except it manifests in a different way than in 3.1.0. Please see attached screenshots and test .blend file. When one applies the Bevel Modifier, different results manifest in 3.1 and 3.2, but neither seems to be correct. I don't believe the bevel modifier should be splitting ANY UVs based on an algorithm, but rather keeping any new generated vertices joined and scaled out evenly from where they originated. It seems the algorithm in 3.2 is currently putting the inner vertex at the center rather than merging it with the one below it, and is separating the outer two vertices rather than merging them at the center. Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges. I have noted in the final screenshot what should be happening to the vertices. If your fix has already corrected this and it has simply not been applied to the latest 3.2 beta build then I truly apologize!

In the file the "not working example 1" and "working example 1" collections contain identical cases with one difference: the object "cube (has vertex group)" has no vertices and the "cube 2 (has vertices)" does have some.

In T98202#1360823, @Hans Goudey (HooglyBoogly) wrote:

Right, they are "created" because the result of the join node is a new mesh that just has the values copied from its input meshes. Geometry nodes only reads generic attributes, so that's what it creates in the result.

Right, they are "created" because the result of the join node is a new mesh that just has the values copied from its input meshes. Geometry nodes only reads generic attributes, so that's what it creates in the result.

@Hans Goudey (HooglyBoogly) in this case it is not creating vertex groups it is just copying them. And it does copy them in some cases and not others (a mesh with vertices vs not). Can you please look at the example file again I may not be explaining it well enough.

Thanks for the report. This is expected behavior currently though. Geometry nodes doesn't create vertex groups when it creates new geometry, it creates generic float attributes. The difference isn't so visible externally currently, but most modifier cannot use generic attributes as inputs at this point.

Happens for other modifers, too (e.g. Simple Deform).
Wondering if this is somewhat expected, needs another look with fresh eyes...

@Henrik Dick (weasel) is that a known limitation?

@tempdevnova (tempdevnova) In your test file Bevel_pinching2.blend it is clearly a user problem, as the faces are non planar. Bevel mostly works with non planar surfaces, but normals behave different and happen to cause problems.

In the 3.2 version for example you can see that the edges protrude, whereas in the 3.1 version it doesn't which might be caused by T97940.

Both the bevel modifier and operation were changed from 3.1 to 3.2. See: T97940 and T95916.