Nasty Mesh problem - finding the lowest depression

OK, I humbly admit it - I cheated.

The given Plane’s Up-axis must define what is up.
Regarding manual mode: No manual intervention allowed. Otherwise this would have been a walk in the a dark park.

Me too. I can probably find 777 cases, with no or little effort. This was to my surprise when I started to dig into it. :slight_smile:

Regarding connectivity for a drainage strategy: The meshes won’t get better than this. More likely worse. We live in a fallen world. Therefore, be of good courage, it will be easier to stop the recursion than the curse.

However, do not count on interconnected upper faces. You will encounter gaps (perhaps not in this mesh but…). I tried earlier with a Contours strategy, but that failed because the surface wouldn’t always be intact (holes in the surface meant gaps in the contour = more lost than a lost soul).

If you mean work on groups of faces, then that would perhaps make an algoritm more resilient to gaps.

For very “peaky” meshes I sometimes use a star MeshFace (vertice + connected vertices) to calculate an “average normal” for face groups in order to “guard” individual faces which in fact are among the “top-most” faces but have a tilt to them. Such an “average normal” can then be used in filters comparing vector angles. This is even more important when building temporary surfaces from filters, temp surfaces to be used for further analysis, since tilted faces may cause holes in the temp mesh if omitted, and so causing problems for the next algoritm. Aso.

I expect to be working only with good meshes in the hereafter. :sunglasses:

// Rolf

Well … that’s why I hate meshes (and computers, Windows, .NET, .NOT, nurbs, planes, points, curves, lines, breps and - obviously - any HarleyDavidson).

In order to mastermind some drainage strategy (not nuclear science … but not a trivial thingy either IF the mesh is a mess) do you have some other ugly meshes (or at least the worst of them) in R5 format? Preferably with more than one death valleys or at least with a topology where is difficult (or impossible) to clearly distinguish what is a death valley (that’s why the manual scan (i.e. defining the plane dir and T with your own hands) mode is always a good option - better safe than sorry).

All that because is my style to deal with any problem … having the worst case senario on hand PRIOR any Vodka assistance,

For instance: what (and where) is a death valley for that thing?



Moral: life sucks.

I’ll go through a bunch of them, uploading samples as I find them.

#1. This one having some typical “features”:
00 Iso.3dm (2.3 MB)

  1. Holes in the mesh (missing faces)
  2. “Drainage path” at the X- end making a turn while dropping drastically
  3. Drainage path making a long curve
  4. Drainage path is hilly, although small ones (local minima traps…)

This mesh was fairly clean from splinters inside, though.

I’ll dig up more samples. I use to put samples side by side when testing my algoritms just to see what features on individual meshes makes the algorithms go bananas.

// Rolf

01 Isotropic.3dm (7.6 MB)

#2. Typicalities:

  1. Spiky.
  2. Bumpy.
  3. Tunnels.
  4. Valley wall cut off on one side.
  5. Splinters inside.

Needs a working strategy for where to limit the line ends so it doesn’t receive bad influence from the dropping altitudes, or the tunnels or… oh well.

This mesh separates the boys from the men. (I love this one).

// Rolf

I need more spiritual aids (maybe switching to Tequila?).

BTW: In an ideal world (as found in Planet Pink) it could be sufficient a DotProduct question in order to yield the upper mesh (red) faces > from that filtered collection the recursive drainage could cut the mustard in a couple of milliseconds.


I hear you: no tickets left, try next century.

Are you sure you won’t get stuck and wet in those water pots along the way (local minima)? :innocent:

// Rolf

Yes (is just one simple question within the recursion [Tequila related]: to be exact is a mini recursion within the big recursion).

PS: these things of yours are trully disgusting (WHY I have answered this thread? You tell me).

Dot in Planet Pink:

Dot in Planet @#%#%$#:

1 Like

I told you to stay away from darkness…

Anyway, those screenshots looks promising!

// Rolf

I just figured out the solution: just ride (hard) the lethal thing in the rain (ABS off) while fixing the pseudocode > elementary my dear Watson.

Screen%20Shot%20085

This is that matters the most (Traction Control also off).

Big news:

All what needed is deactivating the Traction Control (don’t try this in the rain without a good life insurance).

Completely new approach: shooting 3dRays from a proper grid (deployed on the box pts (p[4], p[5], p[6], p[7]) > the first hit yields an upper (red) mesh face (i.e. some upper face no matter if the mesh has 666 disjoint pieces or is twisted or is nasty or whatever). Then the drainage thingy deals with face centers as a graph (no matter … blah, blah). The only thing still MIA is setting the Engine Mode to Track - in the rain (Ave Caesar Morituri te Salutant).

Ray-shooting in the dark is an option, yes.

Just because I’m quiet doesn’t mean I’m not trying things myself, but I’m slow, and I tried to refactor some of your code to get that nice speed you got out of your Plane-Mesh intersection.

I had a somewhat similar component (compiled VS), but it is so terribly slow (based on intersections of mesh face edges against Nurbs surface(s) (which can be curved though, so that is trickier and slows it down)). It spends 1.2 seconds to get a mesh-surface intersection from these meshes, so it’s just too slow.

I really appreciate your ideas, and I’ve learned a lot from some of your code snippets. I’m forever learning.

// Rolf

The bad news are that I can’t find some isolated time (I have a practice to run) to deal with that puzzle … meaning that every 5 minutes I stop whatever thing is on the making … and when I return I have completely forgotten what I did, why and what C# made in the past (out of ~50K available) has some method to use/test: blame advancing Alzheimer and other spiritual things.

But the good news are that MotoGP is over (and F1 as well) meaning that there’s nothing scheduled for the w/e (unless there’s strong winds around > wave windsurfing).

Well … in theory this is a simple case (no matter the mesh). But only if Methods (Rhino Methods) work as expected. Of course they don’t: see the somehow odd behaviour of the 3rd elimination option (RayShoot). Is it due to the crap mesh of yours? Is it Karma? Is it a sign to marry a rich girl and abandon ship? Is it an UFO sourced message? You tell me.

Note: Drainage is not yet implemented (I must test it a bit more against messy meshes).

Mesh_ValleyOfDeath_V1B.3dm (1.7 MB)
Mesh_ValleyOfDeath_V1B.gh (133.6 KB)

To me it it looks like RayShoot does exactly what it’s suppose to do also in this case.

Problem is - the mesh tends to have “double surfaces” in places (not to mention a zillion small splinters inside), so in this case there’s a surface with normals directed “inwards” (from our human perspective) while the mesh has it perfectly right - the normals are actually pointing outwards. Like the dotted arrow in my mousedrawn piece of art illustrates. In combination with a hole = disaster:

Sometimes it solves these kinds of problems to use an “skip-outliers algorithm”. And sometimes it doesn’t. In automation, phenomenons like “sometimes” is the curse.

But this is only one of the things that makes these meshes the “more interesting”.

// Rolf

Well … the big question here is: is a valley collection (the red faces) due to a double (or more) layered mesh with holes valid? If not there’s ways to deal with the elimination (for instance sorting boxes out of the disjoint meshes …and then start asking stupid questions [are you “above” that thing? etc etc]) … but I rejected them because are slow (my mantra is: if anything takes more than 200 milliseconds, go date another girl). But I could provide a similar sort Method and then … well … may the Force (the dark option) be with you.

Say: Sync sort meshes/boxes as above and find the “top most” (with regard the orientation Vector) Mesh in a given collection of disjoined meshes. Using classic connectivity (hopefully working on a messy mesh) get the 2 (or more) faces that are naked at both ends. Test the second “top most” if it has a naked face that belongs to an open loop [due to a naked face closest to the second in order to speed up things] as defined by the top most and his naked faces. Make that one the top-most and check the next in the sorted list. Blah, blah. This approach works … but is not very fast (and I hate meshes like my sins).

Moral: there’s a rat aroma in this case.

Only upper faces are valid “guidance” data for a final straight FitLine along the “bottom”.

Holes may occur along this path, yes (thus watch out for Sum of lowest Z:s to suddenly drop, even if not at the lowest path), but perhaps the “sum divided by the number of faces along a distance (Line length)” can damp the effects of such holes? You tell me.

Anyway, only upper faces are valid guides, because the “distribution” of holes, and whatever surfaces and splinters and anything really, which you may find below that surface, is not consistently spread, and so they will most certainly make the final straight Line drift off the “bottom” of the valley, compared to if it was guided only by the uppermost (sur)faces, at each point.

Although having been married for nearly 40 years, to the same wonderful girl, i sympathsize with the idea to drop any girl slower than 200ms.

There’s a lot of bad aroma in this case, yes. Which is part of why I’m holding my breath, :wink:

// Rolf

To be clear (I hope I understood your question correctly), the uppermost faces in the picture below would be perfectly okay to guide the final line - if only the plane had found the “bottom path” of the cavity, of course (this is on the top of the ridge though, but due to the holes in the upper surface it illustrates a worst case scenario):

Also, what I mean with a hole potentially affecting the calculations, the “sum of Z values” would drop (it depends on how you calculate of course) in a case like pictured below (compared to the red line, which is closer to the bowwom of th valley):

Edit: So, if a “Sum of Z-values” strategy is used, then that strategy perhaps can be “armored” from influence from thee holes by dividing the Sum also with the total length of the (poly)line going through all faces.

// Rolf

Holly cow !!

Anyway get the sort stuff and prior the massacre/elimination (add a 4th option) do some practice:

Do a Method that identifies a face as naked. Then do another that using a naked Face (as a start face) loops and finds the neighbor faces indices (it stops when a newly found face index is the start face index). Use classic List intersections for that one (FF connectivity) and the “are you a naked face” question. Then store all faces (due to the section) indices during their creation and map them correctly to all the disjoint mesh faces. Note: List.IndexOf() is the mother off all delays.

In plain English: each mesh due to the section is a “string” of faces that terminates (or not) into naked ones. If it terminates in a naked find the indices in a loop (hole) assosiated with that naked face and test if the next “string” has a naked face with an index that is contained in the loop indices List of the previous string.

Then … may the Force (blah, blah) be with you.

Mesh_ValleyOfDeath_V1C.gh (127.1 KB)

Then … comes the drainage thingy with the same termination logic (plus dealing with local pockets).