How to use "features" in a tri-remesh component for grasshopper

So, I am trying to get this right and there might be a very simple workaround that i might be missing.
I tried re-meshing a mesh, using the sparkly new Tri-mesh Remesher (which in my opinion with the quad remesh is one of the brightest gems in the rhino7 toolbox)

if the mesh edge is an external edge this works fine, but it doesn’t seem to work that great for mesh edges BETWEEN meshes.

I tried welding the meshes to create a sharp angle, but still it doesnt seem to take an “edge”

210428-fold edge.3dm (77.1 KB)

What could be a good solution for the same?

1 Like

Hi @chottabhai,

It looks like you are feeding in 2 separate meshes, which are then getting remeshed separately.
If you want to remesh those 2 polysurfaces as one, you need to first join them like so:

1 Like

Thanks! Works like a charm. (7.8 KB)

I am facing issues with the boundary curves. What am i doing wrong here ? isn’t the “features component” supposed to pull the vertex points?

Can you post with internalised inputs? (7.8 KB)

I am so sorry, my bad

Thanks - the Features input will preserve features when they exist in the input mesh.
Here you can make a mesh including these points like this, then they stay fixed during remeshing:

Hi Dan,

Could you have a look at this please: (231.4 KB)

Is there some sort of tolerance problem that the trimesh not picking up these verts or am I going mad?

Hi @andrei.smolik

Your geometry was hundreds of thousands of units from the origin. This causes tolerance issues for many functions in Rhino/Grasshopper.

It can be solved simply here by moving everything closer to the origin.
You could of course then move it back to the original location, though I’d actually recommend working closer to the origin for all operations, as otherwise you are likely to run into other issues further downstream. (235.7 KB)


Thanks Dan!

The locations are from the architects (who have a tendency to put things light years from the origin for some reason).
It’s kinda strange since I was testing it with a plugin called Iguana which does something similar:

For our purposes, trimesh does a better job (as far as I know) so I’ll do what you recommended with moving things to and from. Just out of curiosity do have an idea of what might be happening behind the scenes that allows Iguana to bypass the floating point decay issue?

I suppose I could add something inside the tool to check for geometry far from origin and do some relocating automatically or adjust tolerances.
I believe the other plugin you mention is calling a 3rd party library, which might make things origin centred for processing.

Like I say though, geometry that far from origin will probably cause a problem elsewhere in Rhino too, so better to build a workflow where you work near the origin for everything.

Fair enough. Maybe just add a warning message. That would’ve saved me a trip down a remeshing rabbit hole! Great job on the tool anyhow, really really useful!