Hi Micha,

> (5) mesh #3
>
> I attach the original surface, now it should be buggy. ;)

It looks like this one is due to having a surface that has an internal crease (G1 discontinuity) in it.

This is kind of an unusual surface since you have created a degree 1 surface with a lot of points in it - normally when you have a surface with a lot of points like this, it typically is done as a degree 3 surface so that it will be smooth when you pull points around on it, a degree 1 surface is kind of more similar to a polyline, and typically degree 1 surfaces are used only with a smaller number of points to form a simple plane (using just 4 corner points).

At any rate, the bug in this case is in the splitting function that is supposed to split surfaces at G1 discontinuities when they are loaded, it is only splitting it partially in this case.

I've fixed it up for the next v2 beta, so it will get split properly when loaded and mesh well.

Another workaround for the current release is to use Edit/Separate on it, and then Edit/Join to rejoin it, that will cause it to get split up properly and it will mesh well after that.

- Michael

Hi Micha,

> (6) mesh #4
>
> Seems to be the same problem like at (4) and I don't understand it, why edges
> are independent from the surfaces

Well, edges are not restricted to only be along the natural boundary of a surface.

If they were, then you would be unable to trim surfaces in many situations.

Here is an example - say I start with this plane, it is a simple surface where it has 4 edges that are on the natural boundary of the surface:



Now if I take a curve made up of many different segments and trim that plane, it will create a bunch of new edges on that surface:



You can see there that I turned on control points for the surface as well, and the plane surface is still there underneath those 10 new edges that form the new boundary.

Similarly you can have any number of trim curves on a curved surface as well, and it is possible to have trim curves that touch each other smoothly rather than at a sharp corner - that is what was happening with this previous model, if you go in and try to select the outside edges of that cylinder you will see that you can select a small portion of it, which is actually one small edge itself, the boundary is made up of a number of small edges touching one another rather than one single large edge.

Check out this FAQ answer for some more illustrations on how trim curves and an "underlying surface" work:


A larger number of edges makes for a more complex topology and will prevent MoI from doing things like spacing points out evenly across a larger distance like it can do when the edges are larger.

So if you want the most optimal mesh result, it will help to have an optimized topology as well.

A complex topology will also tend to generate a more complex mesh result as well.

The mesh will still be valid on a non-optimized topology (as in no holes, etc...). But since you are very interested in getting the best possible mesh, you will need to also give the mesher clean topology to work with.

In general it is a pretty simple situation, I mean you can't expect the mesher to generate perfect results when it is given lower quality inputs. (sometimes low quality can mean different things, but I've described previously the types of alignment conditions which help for this purpose of all quad generation).

There's a saying: "Garbage in, garbage out", - if you don't start with a high quality result it is not realistic to expect the highest quality result out the other end!


> and how to delete edges.

In MoI this can be done by selecting all the edges of a single surface (not a joined surface, use Edit/Separate) and pushing delete. Check out this object repair tutorial for more info:
http://moi3d.com/forum/index.php?webtag=MOI&msg=446.17


> I would like to
> avoid the effect per Rhino script befor I export the object to MOI. I afraid, at
> complex models the "separate-edge-delete-join" method could be a problem.

Yes, it can definitely be difficult to do a cleanup of messy stuff on a complex model!

But if you don't provide clean inputs, it is just not possible to get the very best quality outputs.

Keep in mind that MoI does not have the same level of human judgment and analysis that you can apply, it is a very difficult problem to do a fully automatic cleanup without judgement to assist the process.

- Michael

Hi Micha,

> (8) I used an angle of 35°. It's the "o" from a Rhino text object with a round.

I think this one was answered by my reply to your additional message, see here for that reply:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2451.21


> This screenshot above was done befor I changed the CentroidTriangulation option
> at the ini. (Sidenote: the Rhino mesher create this overhanging peaks too.)

It probably wasn't so much the change in CentroidTriangulation that avoided this, but rather using a different angle value that didn't cause the edges to get an additional subdivision beyond what the base surface got. Again see the above linked reply for more info on this.


Overhanging peaks are basically when a polygon has a high degree of non-planarity to it. If you have many points that are nearly co-planar and then suddenly one that is a larger distance away from that nearly common plane, it creates that kind of situation.

Rhino's mesher tends to create things like that in many more circumstances even without going to coarse levels of meshing, particularly around closed surface seams.

In MoI you will typically only see that effect if you are torturing the mesher by using very coarse angles like you are doing here! :)

If you see that kind of peak under more normal meshing circumstances in MoI (like say less than 20 degrees angle parameter), then please let me know, but in general I think you won't run across that except for in these very coarse examples.

Again, please refer to that previous message about how it is possible for edges to get refined with additional points than the surfaces and why that is necessary (or else things that are flat but with complex trim boundaries would not work at all, example in that previous message).


> Two other things to this - at Rhino I found, that some triangles can be converted
> to quads (maybe this is fixed in your internal version like you wrote at (9))

This was with the Mesh#6.3dm model? Was this instance where you could convert some triangles to quads happening at the default mesh parameters, or only at a particular parameter?

If you can tell me the parameters you used to run into that, I can test with it over here and see if it is fixed by the other fix or not.


> and could it be possible, that the CentroidTriangulation option is
> part of the general meshing parameters?

Is it something that you expect to be turning on or off very often?

For most people I was figuring that it would be something that they would want to have on all the time or off all the type for more typical usage.

- Michael

"MoI is a one man show" indeed (joke about earlier thread). After the length of what I see here, I'm starting to wonder if there arent a few people named Michael Gibson working on this product! ;)

Hi Nick, I just type fast!

But yeah I do have to try and get some time to write code as well as answer questions! :)

Micha, maybe in the future when you have so many different things to post about you could possibly group them into some more categories and space them out a little bit, like maybe one group of bug reports, one thread a bit later on low poly questions, one thread later on quad generation on particular models, etc....

That would probably be a lot easier for me to manage, either that or I could possibly need to take some items and kind of archive them for future reference rather than trying to deal with them all right now...

- Michael

Oh, that's much to read. :) Thank you for the answers.

First - why I'm fighting with the low poly count? I offer 3D visualisation and get my models from my clients. So, often I can't choose, how detailed the models are. Some production models, most from software like ProE, are so complex, that I must try to get the lowest possible polycount. For example if a designer send me a train seat and like to see a coach full of this seats, best rendered in very high res and without visible tessalation at 100% at the screen - worst case.
So my tests go in the direction low poly count and best quality. I happy to see that MoI doe's a great job for that.

Thank you PaQ for the 'avoid smaller than' hint. That's a good polycount saver. :)

Michael, I see, if I like to get a perfect mesh, than best I model at MoI. ;)

Now I better understand the concept of curves and trimmed surfaces. Thank you for the deatiled infos.

>> Two other things to this - at Rhino I found, that some triangles can be converted
>> to quads (maybe this is fixed in your internal version like you wrote at (9))
>This was with the Mesh#6.3dm model? Was this instance where you could convert some triangles to quads happening at the default mesh >parameters, or only at a particular parameter?
>If you can tell me the parameters you used to run into that, I can test with it over here and see if it is fixed by the other fix or not.

(Rhino "o" model - Mesh#6.3dm)
33° -> "96 triangles were converted into 48 quads."
22° -> "226 triangles were converted into 113 quads."

>> and could it be possible, that the CentroidTriangulation option is
>> part of the general meshing parameters?
>Is it something that you expect to be turning on or off very often?

I don't know - if I mesh an object, than I look at the preview and if I see a problem, than I change the parameter to get a better result. So, best would be good to get all control at one place.

Thanks,
Micha

Hi Micha,

> (Rhino "o" model - Mesh#6.3dm)
> 33° -> "96 triangles were converted into 48 quads."
> 22° -> "226 triangles were converted into 113 quads."

It looks like these are also tuned up to at least some degree for the next v2 release - in the current Jan-19 release with Quads & Triangles, these currently generate these number of polygons overall:

33° -> 635 polygons
22° -> 1211 polygons

In the next v2 release instead these generate a lower number of polygons (some more quads):

33° -> 608 polygons
22° -> 1163 polygons

However, MoI's mesher only creates quads when the quad is a "natural quad" that is aligned with the UV grid of the surface, it doesn't just create any possible quad that may be found by combining any adjacent 2 triangles because that tends to make for somewhat odd looking results in many cases.


I'll see if I can think of a good way to add centroid triangulation as a checkbox option. I kind of hate getting such a huge array of options though, it tends to make the UI much more complex. But I guess in this case since the dialog can collapse to simple version I maybe shouldn't worry about it so much for this.

- Michael

Hi Michael,

here an other issue or example (mesh#8), where could be possible an optimization. I create this object at MoI, it's a first try for a railway sleeper for a visualisation of a train station.
My screenshot shows the unfilleted object that is good meshed and the filleted version with two issues - a large kink, also visible at smaller mesh angles like 16° and missing quads at the big top surface that goes around the sleeper.
It could be nice, if the meshing of the fillet would be determinated by the top surface. But this isn't new, you told me:

"I think it is going to be possible for me to do some work in the future to try and form the initial UV quads of a fillet after the "main" surfaces have been done and in some situations it may be possible for me to make a better initial structure for the fillet that matches an adjacent surface, but probably only when there is a plane to one side of the fillet since matching to pressure from multiple sides of curved surfaces is probably not going to work."

So, maybe this is one more example for a know issue only. But I have the feeling, the big kink at 16° should be avoided without additonal adjusting. ;)

Hi Micha - the big kink at 16 degrees happens because of the curvature of the fillet surface is quite shallow in the longer direction, which I highlight here:




Since the surface is only gently curved in that direction, an angle of 16 degrees does not cause the fillet surface itself to become subdivided.

As I've mentioned before, if you have a situation where a surface does not get subdivided but its boundary edges do, it can lead to these kinds of kinks.

There isn't really any bug here - to solve the big kink you need to do something to cause additional subdivisions of the surface.

The typical method for that is to decrease the angle parameter until it is less than the angle of that shallow curvature for that long direction on the fillet - that will solve the problem. For example try using an angle of 12 instead and your kink problem will be greatly reduced. As you go to a tighter angle yet it will continue to be reduced.

Another way you can solve it is to use the "Divide larger than" setting to force that shallow long fillet piece to get subdivided. For example with Angle 16, try entering a value of 20 for "Divide larger than", and it will force any polygons longer than 20 units in size to become additionally subdivided - that will force additional subdivisions of the surface and again solve the problem.

When you see this problem, it is caused by a surface getting a coarse mesh on it, and the solution is always going to be to force additional subdivisions...

I think that a "Chord height" tolerance value which I am also planning on adding would be a pretty good parameter to help in these situations as well.

But basically if you want to improve the tessellation here, you need to manipulate the settings to produce the result you want - normally the solution is to just make a tighter angle but if you want to avoid that you will need to use some of the other settings instead of angle alone on shallowly curved things.

Keep in mind that 16 degrees is a rather coarse angle, the default that MoI uses for angle is 12, which is already somewhat coarse to start with.

- Michael

Hi Micha, just to give you a better idea on how coarse 16 degrees is (and to better illustrate what is happening), here I have extracted that fillet piece and viewing it from the side where it is curved, I have placed 2 line segments underneath it which have a 16 degree deviation between the lines:




As you can see, the fillet overall does not really bend as much as those line segments bend with respect to one another - that's why an angle of 16 degrees does not cause that fillet to be subdivided in that direction, it is within that angle tolerance.

Again also notice that the angle between the lines is very noticable - that is because 16 degrees is a pretty coarse angle! As you can see lines that are at 16 degrees to one another do not look very much like a smooth curve.

When you generate a coarse mesh you can get that kind of "non-planarity" to n-gons which is what causes those kinds of kinks.

- Michael

Thank you for the hints. Also I'm very courios for the "Chord height" tolerance value.

I play with the options "devide larger .." and run in an other issue. I enabled "curved", but the upper surface is devide in the direction without curvation too. My wish here is a fourth option (planes, curves, all) like "curved UV", so that the upper surface wouldn't devided in the not curved direction of the red arrow. Maybe a fourth option isn't needed and this feature could be implemented for the exist "curved" option.

General I miss quads at the upper surface like the object without fillets show it. I marked two critical areas. So, it's not only a question for the polycount, also for the look.



Also nice would be, if the polygon edges of the polygons could go straigt upward. But maybe that could be done by a inteligent mesher with a sense for beauteousness only. ;)
I know, you like a simple interface, but I could imagine, that it could useful to set independent parameters for "divide larger than .." of curved and plane surfaces.

Hi Micha,

> I play with the options "devide larger .." and run in an other issue.
> I enabled "curved", but the upper surface is devide in the direction
> without curvation too.

Yeah, the "curved" option will apply the division to any surface that is not planar, and will divide in both directions.

I think that the chord height option will work better for this particular thing rather than having another variant of "Divide larger than".

That is basically what will be useful about a chord height metric - directions that are flat will already satisfy the chord height metric. By the nature of that metric it only applies to curved areas.


> General I miss quads at the upper surface like the object
> without fillets show it. I marked two critical areas. So, it's not only
> a question for the polycount, also for the look.

Well, you've used an angle of 100 degrees in your screenshot there, you should generally expect to get a jagged look to your object with such a coarse angle, no surprise about that!

Re: quads - as far as I can tell the same thing that I described earlier in this thread applies here - you're not getting quads because the initial UV quad layouts of those surfaces do not align, here is a link back to that explanation and illustration again:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2451.6


> I know, you like a simple interface, but I could imagine, that
> it could useful to set independent parameters for "divide larger
> than .." of curved and plane surfaces.

The separate chord height metric will basically allow for something pretty similar to that since it essentially ignores planes. So that would let you use "Divide larger than" and set it to only apply to planes, and meanwhile use Chord height separately which will only apply to curved areas.


> Also nice would be, if the polygon edges of the polygons could go
> straigt upward. But maybe that could be done by a inteligent
> mesher with a sense for beauteousness only. ;)

I'm not quite sure what you mean by striaght upward? But yes unfortunately many things that would be nice to have tend to require a kind of "artifical intelligence" which is rather difficult to code. Maybe some day! :)

- Michael

Hi Michael and Micha,

I've been following this thread with interest, I am not by all means a meshing expert, my question is, does model geometry/surfaces play a part in good meshes, the reason I ask is
that I noticed Micha has modelled the top of railway sleeper with one surface, typical of a poly modeller, as I've learnt from the forum.
Would it be better in the meshing sense to model all the fillets as fillets instead of a single spline?

I've attached Micha's railway sleeper as I would have modelled it, it is the third model along, hope you don't mind.
Does this make a difference ? Just curious and educating my self.

Thanks

The chord height options sounds very interesting. I'm curious for it.

Straight upward means something like this ...


... 100 degree - I set this high angle because I tried to get control only by the devide option. I'm quite happy with the result, only the missing quads. The initial uv layouts could be alligned, if fillet and top surface would be created per sweep allong a side curve. I understand.

I tested how good could be a mesh (#9) created only by "devided ..". I wonder me, that the right surface show some triangles. The initial uv layout should be quite good to create a mesh of quads only or?



Or here - additional polygons at the lower edge ...

... and from down view

... also "avoid smaller than" 2 dosn't help.

Hi Danny, that can actually help somewhat to have it structured the way you show there, with more of a partitioning between different regions of that long surface rather than just one long single piece.

With a long single piece that goes through a lot of bends, what will happen is the mesher will attempt to fit a regular uniform mesh on it but will have to give up on that since it would take too many polygons to do a completely uniform evenly-spaced mesh across the whole thing.

When you have it separated out into more individual regions like you have done there, that can help each section to get a uniform base mesh on it, which can help to avoid adaptive subdivision of the mesh.

Adaptive subdivision is the kind of thing shown here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2379.3 which will divide only certain areas of the surface into smaller pieces instead of having a totally uniform division throughout the entire thing. You won't get simple quads anymore in areas where adaptive subdivision happens, where there is a transition from one level of subdivision to the next.

But at any rate, some of these issues are things that can come into effect with any kind of model when you want to make a coarse, low-polygon version of it that doesn't have odd things sticking out from it. Coarse meshing and jagged shapes kind of tend to go along with one another, so it can take some targeted manipulation of the meshing parameters to get low polygons without too many artifacts. That can be kind of a separate issue from the modeling technique used since it applies to a wide variety of models.

- Michael

Ok thanks Michael, clear now :)

Cheers

Hi Micha,

> Or here - additional polygons at the lower edge ...

Like I mentioned earlier in this thread, it can help for you to switch to Output:N-gons which more clearly shows you where the polygons are coming from.

So for example, with the parameters that you show there if you switch to Output:N-gons, you can see this (viewing from the bottom looking upwards):




Notice how the ngons are not aligned?

In general if you are confused about why you are getting triangles in a particular structure, I would encourage you to switch to Output:N-gons to see how the n-gons are formed. Any place where an n-gon is formed with more than 4 points in it, will end up with that being converted into triangles when you have Output:Quads & Triangles mode.

Now as to why they are divided differently - that is pretty simple, it is because those surfaces have different lengths, here I have discarded the other ones, and you can see that the veritcal one is trimmed back and is not as long as the bottom one:



Because they are of different starting lengths, the longer one gets something like one extra division on it when they get their uniform grids.

I can understand that it seems like they should align like a voxel grid would align - unfortunately it is not feasible for the mesher to use that kind of "intersect with world grid" method because it would only work well on things that happened to be made of planes that were aligned with the world axes. It would produce strange results on anything that was angled.

One of the things that you are asking a lot about are special parameters or things that would help out for a specific model. I can understand that, but just keep in mind that there are a really wide variety of models that the mesher needs to be able to process, there are often all kinds of things that would work great for just one particular kind of model, but that is just not generally practical. Those kinds of things would help you out in one situation and then be really weird and cause problems in a thousand other situations...

- Michael

Hi Micha,

> The initial uv layout should be quite good to create a mesh of quads only or?

No, not good enough to match the parameters - whenever you see adaptive subdivision it means that the initial quad polygon in that area did not match the tolerance and needed to be subdivided.

That's the _only_ reason why things get adaptive subdivision on them...

The part that makes the initial grid has some limits on it to try and avoid creating too huge of a uniform mesh. You can imagine for instance that trying to do a uniform mesh on an object like the one shown here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2379.3 would make for a huge number of polygons.

Also if the surface has varying curvature throughout it like the one you show there, it is not likely to get a dense enough initial grid to avoid all adaptive subdivision, the part that does the initial gridding is more focused on getting a "perfect" initial grid on uniformly curved objects like a cylinder or sphere. It is generally assumed that something with varying curvature may need adaptive subdivision in areas to put more polygons in areas of tighter curvature...

One thing I've been thinking of is possibly adding a setting that would let you turn off adaptive subdivision entirely, that would probably be useful for things like this.

- Michael

Hi Micha,

> Straight upward means something like this ...

I see - of course that would mean making more vertices and more polygons as well instead of keeping the polygon count as low as possible.

It's unfortunately difficult to do this kind of a thing and still keep things all connected overall.

For example making those Straight upwards lines that you show there would mean inserting new vertices on the bottom edge, which means the face flat on the bottom would also need to be altered by that as well.


In the future I do want to work on some more ways to divide a big n-gon up into triangles, but it is pretty hard to do it by inserting more points along the outer boundary since it has this ripple effect of modifying other faces. When you get many faces trying to modify each other at the same time it becomes a big problem. I can more easily add points to the interior of an n-gon which is what happens with centroid triangulation.

- Michael

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.

---------