Hi Micha, I've tuned up "Avoid smaller than" for the next v2 beta to avoid this problem.

So basically the way it worked before was that if a polygon had an edge under the "Avoid smaller than" distance, it would switch to a rougher 35-degree angle for the angle test in that direction (U or V direction).

It would use that adjusted angle to decide whether a polygon met the angle tolerance or not, and if not then it will subdivide the polygon.

But then the problem was that when it decided which direction to subdivide, if one direction (U or V) was under that distance (note, _distance_ was used for this part and not angle) and the other was not, it would split in the long direction. The idea was for it to literally avoid splitting something that was already small even further. However, it is not good for low poly count to do this, your example of those long and skinny objects in that cross-hatch area shows that.

Really the main intent of "avoid smaller than" is to make a rougher mesh in small areas, to help reduce polygon count. The old mechanism was trying kind of too literally to avoid subdividing small edges at all costs which actually increased overall polygon count in some cases.


So to fix this up I now use the angle to decide which direction to split in.

The way it works now is that it looks to see if U or V are out of angle tolerance, using the rough angle for a direction if that direction length was under the "avoid smaller than" distance (the same as before for this part). Then to decide which direction to split, if only one direction was out of tolerance (using the possibly adjusted angle), it will split in that direction.

If both directions were out of their angle tolerances then it will use the one with the greater angle, same as how it normally works with no "Avoid smaller than" specified.

This adjustment will now give more expected results including with "long and skinny" shapes.

I've tested it with a bunch of things and so far I don't see any problems. So I think it is an overall better way to do it. But please let me know if you see any unexpected results with "Avoid smaller than" in the next beta.

- Michael

Hi Micha,

> And here an other problem, I don't get a mesh without a split effect.

There are actually 2 different bugs that are happening here.

The first one which actually causes the biggest rendering glitch is that the surface normals are not being handled right at that "pole" point for the center point of the disc. This is a bug that happened with the last v2 beta along with some of the speed-up stuff (same bug as from this thread).

To avoid that you can either use V1 for that particular model, or move it closer to the world origin which should avoid the problem. The bug happens in the Jan-19 beta when models are in a certain zone away from the origin something like between 7000 to 10000 units away, anyway that one is fixed up for the next v2 release already but it is not present in v1 (well it is in v1 for display meshing but not export meshing).


Then the other bug is with the aspect ratio control. It is normally intended that the aspect ratio metric should not be applied to a UV quad that has a collapsed "pole" endpoint. Otherwise if you took an isosceles triangle like that and subdivide it, the new triangle tip does not improve in aspect ratio so it would just keep on dividing until it gets to be really small. The piece of code that detects whether there is a pole was using too tight of a tolerance and not detecting it consistently in this case. I've fixed this one up for the next v2 beta so that the aspect ratio control will be ignored for that front disc surface as it should be.

But for the moment you'll also need to avoid using the aspect ratio setting on that particular model - use "Divide larger than" instead of you want to dice it up, until the next v2 beta where this stuff is all fixed.

Thanks for sending the models so I could debug the problems over here!

- Michael

Thank you for the detailed infos. I'm very curious for the next beta mesher. :)