Hi Tony - one tricky thing with using the output for sub-d modeling is that it only works very well for certain special cases, like with just a single untrimmed surface, or a surface of revolution that has not been booleaned.

The way MoI's mesher currently works focuses on making a low polygon count with n-gons. But n-gons can be bad for that specific purpose of using them as a sub-d cage, especially when the n-gons are particularly big and have concave outlines.

Instead of one big n-gon for a planar cap on something for example for sub-d you would rather have a different style of meshing with all surfaces (including planar ones) diced up into regular sized quads, without regard to the underlying surface's UV layout.

That really needs a much different meshing method to make that work well for the general case of trying to convert something like a whole solid to a sub-d... Things would need to be tiled in a pattern that radiated out from the trim edges rather than starting with quads from the underlying UV surface grid which is how the mesher currently works. The way the current mesher works is good for other purposes though like rendering and getting an accurate mesh for STL prototyping, etc... But for sub-d it is not particularly a good fit right now except for limited cases.

Some more info and illustration here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=1244.48

- Michael

I remember this product,

http://www.npowersoftware.com/booleans/pboverview.htm

They are trying to output quad mesh sds friendly from booleans operations, it was a smart attempt, but not working that well on something more complex than an hole in a cube. (and even the provided examples are not that good if you close up the object a little bit ...)

< an hole in a cube
very useful indeed :D

> Hi Tony - one tricky thing with using the output for sub-d modeling is that it only works very
> well for certain special cases, like with just a single untrimmed surface, or a surface of revolution
> that has not been booleaned.

You are probably right - maybe one day :-)

Hi PaQ - yes I actually have the same code available for that npower polygon to quad conversion, it is included in the Solids++ geometry library that I use.

I tried hooking it up before, but it just did not give good enough results.

In the future I'd like to try making my own version of that, but it will be a lot of work since it is a completely different mechanism than what the mesher currently does.

- Michael

Allright ... I didn't made the link between npower and solid++ :)

Hello, I'm back with a mesher question. ;)

I meshed a very complex model and tried to get down the polygon count per "avoid smaller than", but if I set a higher number, than the polycount increase too. I have seen this behavoir at other models befor - is it logical or a bug?

Hi Micha, there was a bug in v1 with "Avoid smaller than", are you using v1 or v2 for what you show there?

Otherwise, do you possibly know of one small portion or even one individual surface in your model that is getting more polygons with when you increase "Avoid smaller than"? If you can extract that surface or small portion of the model and send it to me, that would help me to take a look at what might be going on there.

The way that "Avoid smaller than" works, is that if a UV quad polygon is less than that distance then it effectively switches to a coarser angle tolerance of 35 degrees so that those small things will be coarser.

It does this individually for the U and V directions so it can change the way that the mesh is divided, maybe there is some case where that difference ends up generating more polygons due to the way it intersects with the trim boundary, but I would think that would be pretty unusual. So it may be a bug, if I can get an example for me to reproduce the problem over here I'll be able to know more about it.

- Michael

Hi Michael,

I used v2 and sent you a test file. I have seen now that the problem seems to be the fine fence of the air intake, the problem is good to see.

-Micha

polycount of this test 280.000 (1) vs 4000 (0,1) - that is it! ;)

I tested a little bit more - at angle 12 there is a big poly count jump between "avoid.." 0,92 and 0,93. If I set a smaller angle, than the problem appears at a lower "avoid.." value. Could be nice, if the issue could be solved, because the user can't know, when he riched the critical values.

Good luck,
Micha

And here an other problem, I don't get a mesh without a split effect. (the moi screenshot dosn't show the settings for the rendering)

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