Reconstructing Colored Mesh and Restoring Hole Regions

Hello,

As described in the title and shown in the image below, the mesh is a colored planar surface within the red domain box. What I’m trying to achieve is to fill the pink areas (which indicate holes), assigning colors based on the nearest existing vertices and then rebuild the mesh back into one continuous piece.

The pink regions that I internalized in the Grasshopper file are only used for visualization to highlight where the holes are. If there is a method that can detect and fill the holes directly without explicitly providing these regions, that would be even better.

Any suggestions or recommended approaches would be greatly appreciated.
mesh_rebuild.gh (780.7 KB)

Hi ,

Is this approach reasonable?

mesh_rebuild-1.gh (790.6 KB)

Hi @JinLong, thanks a lot for your detailed reply — it’s really helpful.

I tried your approach and it works when the missing regions are explicitly provided. However, for this particular workflow I’m hoping to avoid specifying the hole areas manually, and instead detect and reconstruct the missing parts automatically.

Also, after joining the meshes, the result still remains disjoint rather than a single continuous mesh, so I might need a different strategy for actually rebuilding the missing faces.

Really appreciate your input — it definitely gives me more clarity on the possible directions.

Hi @ctu6

I tried to address the first question, but the script ended up being quite bloated, and there are still some issues I haven’t resolved.

As for the second question, I’m also not sure how to solve it.

I am still at a beginner level in learning Grasshopper.Please forgive my limited skills.:sweat_smile:

mesh_rebuild-2.gh (808.3 KB)

Sorry to bump the thread without a solution, but this is a difficult one. “Fill the gaps” is a notoriously thorny problem, especially when regions share vertices, like these tricksy little squares:

I’ve tried all sorts of methods and it’s always these ambiguous islands that cause errors. Is there any way to guarantee their absence in the mesh generation stage?

I’m afraid not — these gaps are generated as a result of slicing the mesh after the simulation, so they can’t really be controlled during mesh generation.

In fact, I think the first part of the problem is actually the hardest one: reconstructing the missing regions back into a proper mesh or geometry. The challenge isn’t only that the slice is an open mesh, but also that its outer boundary is defined entirely by the domain box, which adds another layer of complexity.

Since you didn’t say ‘mesh topology’ has to be maintained, and given all things are planar here, I did it this {lazy} way*:
mesh_rebuild-quick.gh (582.4 KB)
*I didn’t do the color thing—I think you can take care of that based on what @JinLong showed before :stuck_out_tongue:

You had some fragmentary data (naked mesh edges) that were just lines (not closed/holes), so I excluded them.

Elaborate on this, please—what is a ‘proper mesh or geometry’ for your case? In the meantime, and in an attempt to understand what you meant, we’re retrieving fragments as breps then remeshing them here.

Also, if it weren’t for those tricksy regions, as pointed by @Tom_Newsom, I think you could probably python the ‘Fill Mesh Holes’ method.

Cheers!

Hi @René_Corella ,

Regarding your earlier comment — “since you didn’t say that the mesh topology must be preserved…” — you are absolutely right, and that was an oversight on my part.
I actually do need to preserve mesh topology, because the color data attached to the mesh depends on its structure.

My initial thinking was too naïve: I separated the problem into two or three steps — detect the holes, fill them in any convenient way, and then simply convert everything back into a mesh. However, after further testing, I discovered that this approach is extremely difficult to execute reliably, and I will explain more below.

On your question — “what is a ‘proper mesh or geometry’ for your case?” — I should have clarified this earlier (apologies for not specifying it in my first post).

My goal is to reconstruct the sliced surface into a single, continuous, watertight planar mesh, while preserving per-vertex color attributes.


Regarding the suggestion of calling Fill Mesh Holes directly from Python:

I tried this route as well.
My workflow was:

  1. extract all naked edges,
  2. join them into curves and discard open ones,
  3. remove the largest loop (outer boundary),
  4. feed the remaining loops to FillMeshHoles.

The difficulty I encountered was reliably distinguishing inner boundaries from the outer boundary.
As a result, the function ended up filling every closed loop, which produced multiple overlapping filled meshes (as shown in the image).
Technically it fills the holes, but the result cannot be used as a proper single mesh.

I also experimented with Delaunay-based patching.
It fills the holes neatly and without overlap, but introduces entirely new triangulation, meaning the original color distribution cannot be preserved, which makes it unsuitable for my purposes.

I hope the explanations above help clarify the constraints of my case and answer your questions.

Thank you again for your time and for the effort you put into exploring this problem — I truly appreciate it.

That’s the core of it. On first glance it seems trivial, but actually making a reliable algorithm that covers all the edge (heh) cases is fiendishly hard.

Here’s a dumb solution: Just make a new mesh over the whole thing and sample the colours.

Here’s a closeup at a resolution of 1 unit. The overall face count of the two meshes is the same (~39k), but you lose some fine detail near boundaries.

resample colours.gh (580.2 KB)

You might be able to use your Delaunay method and resample the colours the same way.

Awesome @Tom_Newsom! Thanks! Dumb is better/smarter than lazy for sure! :ok_hand:

I’m pretty far from being a fan of Elon Musk but he said a smart thing once, something like:

It’s common for a smart engineer to spend a long time finding a clever solution to a problem that only exists because of bad requirements. Always review your requirements.

Threads on this forum often remind me of this quote, and I often find myself guilty of falling into the “bad requirements” trap :stuck_out_tongue:

In this case, @ctu6 might actually care a great deal about the fine detail near boundaries, hence the request to patch the original mesh, but I suspect the actual requirement is “a good enough heat map for the whole site”, which is much easier to fulfil!

I finally did something like the images below.
Thank you all for your help — it has given me a lot of inspiration!