I didn’t get any response to my last reporting a bug related to the Transform component. A valid mesh becomes invalid after the transform. It doesn’t happen for all meshes. I have many meshes in the same definition which are all subject to the same Transform, but only a few meshes goes bananas in the transform.
debug_mesh-transform-fails.gh (416.6 KB)
The Workaround component fixes the mesh like so;
mesh.Faces.CullDegenerateFaces();
// Rolf
Your brep is not good… it has somehow a “dirty” structure/topology.
I’ve tried, any mesh generated from that brep is having very non-uniform face density with many vertexes almost duplicated, very thin triangles, etc etc etc…
Even the “valid” mesh, simply rotated on rhino, will result in an invalid mesh.
I guess it is because of new rounding of vertex coordinates can randomly lead to 0-area faces or such.
Even directly on rhino, meshing your brep generates an invalid mesh. (4 on 4 attempts)
Edit:
For such simple shape, 46k faces is definitively an overkill.
If the final purpose is a fast viewing of an animated/parametric structure, with those “blocks” always the same, i would consider using quadremesh or some other trick to generate a clean and efficient mesh to move/trasform around.
Currently you are dragging around a zombie mesh (and brep).
The Brep is from a STEP-file downloaded from the internet.
What tests should I use to verify/ensure a “good” Brep?
// Rolf
I don’t know an automatic method to check the "quality"of a brep.
I did see that just by looking at it.
Fragmented surfaces, disaligned isocurves, too many isocurves (so, control points).
Explode the brep, rebuild edges, join: open brep!
Why would an open Brep matter?
I intend to use the model only for illustration (which is why I resorted to downloading it) since I don’t care about the edge quality (or any other invisible details either), only the visuals matter.
Why wouldn’t the mesher be able to handle open breps? I mean, open breps are just as common as closed breps.
// Rolf
You are right.
But we were talking about quality. An open brep mean bad quality.
And that brep is originally “”"“closed”""" only because it was used very low tolerance to do so.
I’m just trying to say: you are having problems with meshes because the meshes and breps are bad, not because of transform function.
No.
A Brep can be a surface or a polysurface, trimmed or untrimmed, and open or closed.
@RIL - I’m looking at this.
– Dale
oh… ok.
I wrote it down wrong, what i meant is: “An open brep, that was meant to be closed, mean bad quality”.
This view alone personally tells me “bad quality”:
I think all the problem here starts from the initial geometry.
And I think that, as you want to use that geometry many times around your model, it is worth to create (and internalize) an optimized and cleaned mesh or even better spend a bunch of minutes recreating it on rhino.
You could have a 1/10 face count mesh that never suffer from rounding after transformation.
Agreed.
– Dale
I’m with you all on that the brep is “bad” (although not for my specific use case), but not so bad that the mesher shouldn’t be able to make a valid mesh -which it actually is able to do. Only when transforming the mesh (in this case a rotation) the mesh goes bad.
I can imagine that some vertices comes too close to each other during Transform, making some faces bad, but if the mesh is valid before the Transform then the Transform should ensure that it’s valid also after (fixing whatever needs fixing).
Absolutely. It was a free download from somewhere. The STEP-file with the part located at the tip of the crane:
Foldable Crane.zip (1.6 MB)
The crane column has the same problem on Transform.
Crane downloaded from grabcad.
// Rolf
Let me just be clear that i agree on that the initial geometry is “bad”. And that the problem shows up in a mesh which is then sensitive to transforming. Probably due to vertices being close to model tolerance apart (aligning vertices helps, as a workaround, although CullDegenerateFaces is magnitudes faster fixing the problem after the Transform).
Problem is - if one cannot import STEP-models, convert the parts to meshes and transform them without having to check all the details (they can be very many to check…), then… well, then it’s not optimal, so to speak.
I hope the Transform component can do better with some checking of before & after, and trying to fix at least known problems if meshes turn invalid. perhaps optionally, so as to not slow down the component when knowing there’s no problem with the objects.
Anyway, thank you all for looking into this. AT least we’re getting closer to the cause of this problem.
// Rolf
I imported the STEP file into Rhino 7 and threw everything away except what you were using. Seems to mesh OK (see attached).
Foldable Crane.3dm (747.8 KB)
Foldable Crane.gh (4.5 KB)
– Dale
Yes, the meshing works, but the mesh goes invalid when I rotate it using a Transform.
Strange that your version of the brep swivel works, but not mine.
If I copy “your” brep into my old GH definition and make a new rotation-transform, no problem occurs, but if I connect the existing transform (created in the same way as my original) the error occurs again if I convert to mesh via a regular mesh parameter, like so:
This is very confusing: the mesh itself seems to not be the main cause of the problem (but if there’s a difference I can imagine it matters how it was imported). The problem for me seems to come from the transform.
The original Transform being chain-linked with many hops from the source Rotation component, but I also tested to connect the source directly to the T-input without any hops, but no difference. The only difference I could find was to make the new rotation component (as in the pictures) and use that one, then the mesh was Transformed with no problem.
I presume you would be interested in my definition, but its huge… The problem was “captured” in the earlier post in which i internalized the transform parameter with its value. If using debug-definition with your version of the brep, does it still produce an invalid mesh? (before dabbling with my massive definition)
But at least the “smooth mesh” does a better job in this case.
// Rolf
TESTING COMBINATIONS
Here testing a series of four possible combinations of the two most obvious factors; #1 the Brep/Mesh and #2: Two different Transforms (my old transform and a new transform created near the test setup).
I connected the "“My” old transform directly to its source (hence the wire going out of sight to the left) without any hops to ensure that hops doesn’t disturb the data).
Image A: “Your” Brep/Mesh + New Transform == Both Meshes OK.
Image B: “My” Brep/Mesh + The same New Transform == Bad mesh (via mesh param).
Image C: “Your” Brep/Mesh + My Old Transform == Bad mesh (via mesh param).*
Image D: “My” Brep/Mesh + My Old Transform == Bad mesh (via mesh param).*
Conclusion
This doesn’t make sense to me. Scratching head.
// Rolf
I just had a similar issue with some curves. Took a long time tot figure out hat the problem was, but for some reason, a few curves after a transform became invalid. Workaround: test for validity, explode non-valid curves, join segments, test again
Same bug here.
Please fix it.
Can you post (or send us) something replicable? as well as your system info. Thanks.
When you have any sort of mesh into grasshopper and you transform it with a cartesian transformation, you will end up with an invalid mesh…that’s it.
Not really…
-wim
