Hi Micha, thanks for sending the file.

All right, so I think I see what is happening here (on your "Avoid smaller than" problem)

The way it is currently set up, when a polygon is out of angle tolerance, if there is an "Avoid smaller than" value set, and one direction (U or V direction I mean) is under that distance and the other is over, it will split it in the long direction rather than in the short one, without consideration of the angles in the different directions.

The reason for that is because it is trying to avoid making small polygon edges.... If it were to divide in that small direction it would cause it to make an even smaller edge.

The edge is already under that "Avoid smaller than" size and now it would become halved to become even smaller yet.

But it looks like the mechanism here of only focusing on avoiding small edge length at all costs is not the right thing to do though, I think that it should also consider the angles in this case and that should make it behave in a better way.

Tomorrow I should know more after a little bit of experiments, but I think I can see the proper way to fix it up.

- Michael

Hi Micha and Michael,

There is also a problem with this surface that doesn't help the situation.



---------

Hi Micha, your new one looks like a different problem, looks like the aspect ratio metric is not being considered for some of the polygons there but is for others.

It looks to be related to the pole point there, I probably should be able to fix that up too.

- Michael

Hi Danny,

> There is also a problem with this surface that doesn't help the situation.

Yeah I noticed that too, often something that looks like that may have a kind of messy jumble of points in the pole area rather than a clean single shared point.

But this surface is not like that, it is actually ok and instead that is a bug in the surface normal calculation which happens in the current v2 beta for things that are a little ways from the origin. But that is already fixed up for the next release.

- Michael

Oh! ok, no probs.

Cheers

Thanks Michael and Danny.

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. :)