Hi Micha - I guess maybe it would help if I knew more of the purpose that you are using your meshes for.

A uniform mesh does have a more beautiful topology if that is the only thing that you are looking for above all else. But at the same time it can have a more ugly shape, more jagged in areas that are curved and normally a higher polygon count than necessary on things with variable curvature since flat areas get the same density as curved areas.

For example notice how coarse the rounded peak of your result is:



Without being able to add local subdivisions just to that area, it results in a very jagged shape there, which is ugly when rendered or viewed in profile, etc...

So except for very special purposes that kind of mesh that you show there is usually worse than one with adaptive subdivision. If you are interested in low polygon count, efficient structure, and making a good looking shape that provides details in curved areas, then those are all things that are going to be negatively affected by no adaptive subdivision.

So that's something to keep in mind...


But yes there are times when people do want clean topology over all else, so for those situations a disable adaptive subdivision would be useful.


Having no adaptive subdivision at all tends to work the best when the shape has totally uniform curvature such as on a sphere or cylinder. That's when a fully uniform mesh does a fine job of fitting the shape properly and efficiently - and in fact you should have probably noticed by now that MoI already does provide that kind of uniform meshing on these kinds of uniformly curved surfaces.


> Adaptive meshing - that sounds for me like "max error between
> mesh and NURBS" and could be nice to control the amount of adaption.

Basically, that's what all the existing meshing parameters do - control the amount of adaptive localized refinement. They also play a role in determining the initial base mesh, but after the base mesh is created then they totally control the "amound of adaption" - for example any polygon that has an angle greater than your given angle parameter will get broken down into smaller pieces - that is exactly what adaptive subdivision is.

So you already have a way to control the amount of adaption - that's all the existing parameters available to you. What I'm talking about is a checkbox that disables any adaptive refinement at all and will only use the base mesh, that would probably help you get the regular meshing you seem to want in some cases, however just be aware that for many purposes such things will actually be worse in shape (or higher in polygon count to make a good shape) as I described above.

- Michael

Hi Danny,

> Sorry guys, I just have one more question Michael, I don't
> understand why a flat planar surface should be meshed
> since it's dead flat.

Sometimes people are interested in getting regularly shaped polygons for specialized purposes. Like for example if you plan to deform the mesh by doing displacement painting on it in zbrush, it is good for the polygons to be diced down to be of a more uniform small size even in areas that are planar (if you are going to do displacements on that planar area).

For other purposes like doing further polygon editing of the mesh, people are interested in getting more regularly shaped polygons with a more aligned topology between all the pieces. Sub-d modeling tends to work best with quad polygons also, so that's why that can come up.

For the most common use of just rendering the mesh, then yeah you don't need planar surfaces to get more polygons than necessary for that.


It all depends on what you are going to be doing with the output data - there are just a lot of varied things that the data is used for, there can be different kinds of meshing needed for these different purposes...

- Michael

> A uniform mesh does have a more beautiful topology if that is the only thing that you are looking for above all else.

I think this would be very useful if you are taking MoI output into a poly modeler for further work - especially if you want to use it as a basis for an SDS model. In this case how the model looks straight out of MoI is not really an issue.

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.