Reshape Mesh or Brep

Hi there

I have a simple question. How can i round the vertices of a mesh or a brep. as you can see in the script, the mesh who comes from a cad software, is not precise. so i want to round the vertices and clean the geometry.
there are only two geometries at the moment, but there will be 1500 meshes per floor and 20 floors!!!
so i need some help which is the best way to clean this geometries. plugins?

thx for your help
chris

You may want to share the file so folks can take a closer look.
What do you mean by “rounding” the vertices?

Here is the script.

As you can see the vertices are up to 5 decimal place. i want to reduce that to 2.

IFC GEOMETRY.gh (15.2 KB)

missing

The expression on each of the pDecon outputs is “round(x,2)” (without quotes):


IFC GEOMETRY_2020Sep10a.gh (17.2 KB)

Thx very much for the answer! This is exactly the way i wanted


Note that this method only works on boxes that are square with the ‘World XY’ axes. If you want to handle boxes that are rotated at arbitrary angles, a bit more work is required. I’d use one of the longer horizontal edges to find the correctly oriented plane for the BBox (Bounding Box).

Thx, that is allready the next question. i will put a script with this case
 I have geometries where i can’t use the bounding box. How can i reshape this geometry in an easy way? Maybe with a plugin

IFC GEOMETRY EXAMPLES.gh (6.3 KB)

how dare you ask for an ‘easy way’ ! :stuck_out_tongue_winking_eye:

start with that so you don’t make good Samaritans like @Joseph_Oster work extra

you could try convex hull this way:

You can use the height of the bounding box

Oh, that’s not just rotated, it’s trapezoidal instead of a box.

Here is a hasty (lazy) way that works on the single MESHES_T (one trapezoidal “box”) but fails on two of them (the output of Entwine) and fails on either or both of the square boxes from yesterday (MESHES_B).


IFC GEOMETRY_2020Sep11a.gh (20.5 KB)

A more meticulous solution using MIndex (Member Index) might work for all cases? If I get really bored I might give that a try.

I’m not the right guy to answer that. :sunglasses:

Thank you very much for the answers!

I tried and failed with MIndex (which doesn’t mean it wasn’t useful) but managed to come up with a way that appears to work for all three test cases (Value List in blue/white group), sort of


The trouble is that converting the lofted brep to a mesh results in extra points, either at the midpoint of all the edges or duplicates at the corners with Custom Mesh Settings. I don’t know why?


IFC GEOMETRY_2020Sep11b.gh (21.8 KB)

CullPt (Cull Duplicates) added to cyan group:


IFC GEOMETRY_2020Sep11b2.gh (22.6 KB)

Meshes are messy!

FYI, I tried a bunch of different things but wasn’t able to rebuild an arbitrary mesh from the “rounded points” (points with their X, Y and Z coordinates rounded to 2 or 3 decimal places, which is the easy part). Perhaps I just don’t know enough about meshes. The assumption that there are identical top and bottom surfaces that are aligned vertically is just too limiting, eh?


IFC GEOMETRY EXAMPLES_re.gh (6.7 KB)

1 Like

Well that’s annoying! I mean that I didn’t know that. Construct Mesh doesn’t work as desired with vertices alone but accepts the old faces and replaces their vertices with new point values!??? Wow.

And apparently the points can be moved far away from where they were, as I just discovered by modifying the pDecon expressions as follows:

  • X: Round(x*3,3)
  • Y: Round(x+1,3)
  • Z: Round(x/2,3)

Is there some rationale for this behavior or is this another one of those weird things about GH that one just has to know? :man_facepalming:t2: Would have saved me a lot of time had I known this yesterday.

That’s because the Faces input expects the vertex Indices for creating a face , since you don’t change the order you can move the point as you like as long as you don’t produce an invalid face.

Thank you but there is no obvious correlation between faces and vertices, at least not to me, so it’s very non-intuitive.

P.S. I guess this means that doing this on a mesh is much easier than doing the same thing with a brep.

I think the name"Faces" might be misleading.The vertex order is important for the mesh creation,the same way it is for a polyline. If you imagine the face as a closed polyline it may become clearer.

1 Like

The only way it makes sense to me is if a face is actually a list of index values that refer to the list of vertices, rather than thinking of a face as a closed polyline?

Yes, that’s how I understand it.

I mentioned the polyline because of the vertex order.