Multiple breps with Meshmachine

Replies to This Discussion

Permalink Reply by Nik Willmore on July 29, 2015 at 6:54am

Grafting the Geom input lets it treat each brep separately, which makes sense, and you lack the usual timer attached to MeshMachine along with a Boolean toggle to reset it, so MeshMachine won't do much, and using the BScale and BDistance are creating havoc somehow too. I've simplified first, and used the Kangaroo Frames component along with setting internal iterations, to make MeshMachine act like a normal component, along with releasing the FixC and FixV. The FixV didn't make any sense anyway. I've also set Pull to 0 to speed it up during testing, since much less calculation is involved to just let the meshes collapse, prevented from disappearing altogether by using a mere 15 iterations.

Also, your breps are open so that allows much more chaos and then collapse, though they did manage to close themselves too at times. Here is closed breps with a full 45 iterations:

So now that it's working, lets re-Fix the curves, and the problem arises that there is an extra seam line that is getting fixed too, running along the cylinder, stopping the mesh from pulling tight under tension wherever a vertex happens to be near that line:

So lets grab only the naked edge curves instead:

And what happens if we lose the end caps, now that we don't have an extra line skewing the result?:

There is no real curvature differences since it's not a curvy brep so the Adapt at full 1 setting has little to do. Now what does the BScale and BDist do? Nothing! Why? Your scale is out of whack, 99 mm high cylinders but only a falloff maximum of about 5, so let's make the falloff be 25 instead, but I must restore the end caps or the meshes collapse away for some reason and freezes Rhino for a minute or so the first time I try it:

It's a start.

If I intersect the cylinders, nothing changes, since they are being treated as separate runs. MeshMachine outputs a sequence of two outputs though, due to Frames being set to a bare minimum of 2 needed to get it to work, so I filter out the original run, which is just the unmodified initial mesh it creates.

The lesson so far is that closed meshes are much less prone to collapse and glitches leading to screw ups.

A Boolean union of the cylinders is when it gets funner, here show with and without the fixed curves that seem to define boundaries too where really there are just polysurface edges:

Permalink Reply by Igor on July 29, 2015 at 9:18am

Hi Nik,

Many thanks for an explanation of some aspects of work of MeshMachine. You couldn't explain briefly conditions under which different inputs of MeshMachine render effect on the different BREP types. What function is executed by Bkgd input? I think it it would be useful for many users who didn't deal with features of work of MeshMachine yet.

 

Thank you again,

   Igor

Permalink Reply by Nik Willmore on July 29, 2015 at 10:46pm

Lack of documentation is the norm for Grasshopper, but we can look at the source code in this case:

https://github.com/Dan-Piker/MeshMachine

https://github.com/Dan-Piker/MeshMachine/blob/master/src/remesher.cs

Alas, this source code does not seem to be the latest, for it lacks half of the inputs.

From the right click pop-up menu Help entry, it seems four inputs are related, allowing you to set up points in space where you want to specify edge length targets:

SizP (Point) Locations for edge length values to interpolate between

SizV (Number) Edge lengths to interpolate

Exp (Integer) Power for interpolation (see http://en.wikipedia.org/wiki/Inverse_distance_weighting#Shepard.27s...)

Bkgd (Number) Weighting for background edge length in interpolation

Sounds like what I thought but also has some math about how it transitions between assigned edge length target positions and also has a bias towards the normal ("background") Length input.

This will get tricky with two breps, needing a data tree, so I'm switching to one. It does work, but I note a strong artifact which I am already well aware of, that finer target mesh sizes collapse under tension slower than coarse meshes, so changing the target sizes either way up or way down from the default Length value, also distorts the result:

Running it more iterations:

This artifact is what made it hard for me to use MeshMachine as a Rhino manual modeling aid via Geometry Pipeline, since I had to use a rough mesh target to work fast, but when I tightened up the mesh there was much less smoothing so I had to also re-tweak the number of iterations used, though I did get the same result. Here, I can't even get the same result since it distorts the result.

I like using NURBS polysurfaces (via troublesome Boolean unions) since they are continuous and MeshMachine can avoid even more artifacts due to an uneven input mesh, though it works just fine with meshes as inputs. Using the manual settings for minimum/maximum edge during mesh creation from NURBS can give a more uniform mesh by ridding both very tiny and very long edges.

I also note that using Pull strength other than fast 0 can work to avoid blow ups, but you often only need a tiny amount, such as 0.001 or even 0.0001, or else it just conforms nearly exactly to the input geometry. In the case of this cylinder, there's nothing else for it to do than match the original cylinder, in which case my form distortion artifact is moot, and I hereby gain control of mesh fineness in a predictable system, shown with and without FixC curves at the ends:

To give it some ambiguity, once again I'll just add a Boolean union of a crossing cylinder, so it is forced to decide between two local surface directions rather than just boring end caps:

With even slight 0.00000001 Pull setting or higher I get the same brep-clinging effect so, no, in this case, I'm not afforded fun control over form, but I am getting local control over mesh fineness, seen in the upper points:

Attachments:

• MeshMachineEdgeLengthsTEMP.gh, 21 KB

Permalink Reply by Nik Willmore on July 30, 2015 at 2:37am

For the record, border adapt does interact with the edge target length point system, but the settings are very tweaky, needing lots of small values to get it to do any transition at all instead of having your points control the entire surface:

This seems to be since it's here relying on the background mesh length input (Length) which only asserts itself with certain values of background weighting (Bkgd). It's there to be had though, controllable transition border meshing via using points with associated edge length target values.

Permalink Reply by Nik Willmore on July 30, 2015 at 4:03am

New source code is here:

https://github.com/Dan-Piker/MeshMachine/tree/8a9c55cab5d72b8eac376...

https://github.com/Dan-Piker/MeshMachine/blob/8a9c55cab5d72b8eac376...

Permalink Reply by Nik Willmore on July 30, 2015 at 1:41am

Finally, the Exp input is pointy fascinating indeed, affording different types of transition between assigned points with associated edge target values, since it can concentrate almost all the change in the middle between points, and thus result in controlled banding. Here I change Exp value from 0 to 10 for the same random point edge length targets of 1 or 30 on a diameter 100 NURBS sphere, allowing the Pull = 0 artifact to relax the ball more with coarser mesh, and since towards Exp 10, all the change happens at an abrupt middle location between points, I get large areas of small meshing and large areas of coarse mesh that collapse, instead of a boring smooth linear transition between edge target lengths:

Much simpler, a diameter 100 2D circle surface with two target edge length points (1 and 30), a FixC border to stop collapse, and varying the Exp input from 2 to 6:

Not as predictable now, no, and beyond 6 just tightens the little bundle. I was hoping for an abrupt transition between them. Ah! Negative Exp numbers gives me exactly what I want:

There seems to be some curvature to the transition though, likely a 2D version of the same artifact that fine meshes don't respond as strongly to MeshMachine iterations.

Using target edge length points seems to disable border adapt fine meshing, and the Exp input doesn't seem to affect border adaption when I remove the target edge length points. Two different systems, I guess, so to do Exp adjustable adaptive border meshing you'd have to populate the border with target edge length points.

Attachments:

• MeshMachineEdgeLengthsBTEMP.gh, 13 KB

Permalink Reply by Ethan Gross on July 29, 2015 at 2:00pm

Thanks Nik for your extremely thorough examination and for convincing me, as I've always suspected, that I have no idea what I'm doing. I guess my "great results" stemmed from using only single, bound surfaces, where seams didn't intrude.

At an even more elementary level, I am unfamiliar with the Sequence component and how it differs from Reset. Could you possibly explain its difference/advantage? Thanks.

Ethan

Permalink Reply by Nik Willmore on July 29, 2015 at 10:58pm

All Frames does, a Kangaroo component itself, is issue a list of True, False, False, False... entries to the Reset input, but MeshMachine also includes an internal cycles control (Iter) that is faster than that I assume, given that it must output 20 meshes instead of 2 when I use 20 frames instead of just setting Iter to 20, so I just right click assign 2 to the number of frames, since that is what it takes to make it run at all, then control Iter and filter out the initial mesh in the series of two. This can get confusing with multiple input geometry that doesn't always seem to output a flat list but I can usually get the real "final" mesh out with some trial and error, otherwise the output seems to be a whole series of mesh steps. What's most confusing to me is Timer and Reset use, actually, so I was happy to blunder into Frames in a casual post by Daniel Piker.

Permalink Reply by Nik Willmore on July 29, 2015 at 11:08pm

I have a MeshMachine-based Rhino modeling aid here:

http://www.grasshopper3d.com/forum/topics/bulge-free-metaballs-and-...

It also uses David Stasiuk's brand new Cocoon metaball plugin to form a force field around geometry that is then surfaced at a single field value after the fields combine in space. It relies on setting MeshMachine Pull to zero, for both vastly greater speed smoothing both, but I believe can still give some actual smoothing around corners of intersecting input objects even with Pull set to a tiny number, more so than my script above. It uses metaballs in order to avoid Boolean union failures. Playing with this package, and before that wanting better 2D meshes from 2D surfaces, made me delve into MeshMachine, and also nag David to add so many inputs to it that I'm only now learning the rest of today!

Permalink Reply by Ethan Gross on July 29, 2015 at 11:48pm

Thank you Nik. A lot to digest, but - "fascinating"!

https://www.youtube.com/watch?v=cFods1KSWsQ

Permalink Reply by Igor on July 30, 2015 at 1:59am

Thanks Nik for useful information.

Permalink Reply by Daniel Piker on July 30, 2015 at 7:47am

Hi Nik,

Thanks for sharing all these interesting investigations.

I realize the multiple versions and user interface of MeshMachine are rather a confusing mess at the moment - I'll try and shed some light on why this is, and some ideas I have for how to improve things going forward.

MeshMachine grew out of some scripts I started developing over 3 years ago (described here), originally just with the aim of achieving approximately equal edge lengths on a smooth closed triangulated mesh.

As time went on, I kept adding things, such as ways of keeping boundaries and sharp edges fixed, different ways of controlling edge lengths that vary across the surface, and different ways of pulling to surfaces.

I was also still experimenting with different rules for the core remeshing operations, such as valence driven vs angle driven edge flips.

All of these things meant many variables in the script. I wanted to share the work so others could play with it, but not really knowing exactly what people might use it for made it difficult to simplify the interface, so I just exposed most of these variables I was using (actually there were originally even more, but I felt a component with 20+ inputs was excessive, and combined some of them and fixed others to default values).

I've never been happy with that component, but some people want a component that you can just feed a surface and get a mesh with 'nice' triangles, without too much fuss or needing to know anything about how it works, while other people want to be able to vary the density based on proximity to the border, and curvature, and attractor points and see the intermediate results, and model minimal surfaces without pulling to any underlying surface, and...

Since then I did the rewrite from Kangaroo to Kangaroo2, and through that process, and associated conversations with Steve Baer, David Rutten and Will Pearson, my ideas about how to structure libraries and make cleaner more flexible Grasshopper components changed. Much of this centres around using interfaces (in the specific programming sense, not to be confused with UI), because they allow separating code into multiple components, while still allowing to edit parts of it within Grasshopper, and other parts in a proper IDE (because I find the GH code editor is not conducive to writing large amounts of well structured object oriented code).

Towards the end of last year, Dave Stasiuk and Anders Deleuran invited me and Will Pearson over to CITA for a few days of mesh and physics coding and beer drinking. During this time I made the first steps to restructuring MeshMachine to be more modular and interface based like Kangaroo2, instead of one giant script. One of the main motivations for doing this was to make it easier to combine the K2 physics library with the remeshing. However, at the time I hadn't yet released K2, so it didn't make sense to post examples that used those libraries. After the launch of K2, this restructured MeshMachine development has been a bit on the back-burner, but this discussion and Dave Stasiuk's work with Cocoon is inspiring me to pick it up again.

Seeing how you are combining the Cocoon and MeshMachine, and how Dave is also using interfaces in his recent work suggests to me it might be possible to integrate them more smoothly...