Ugly Bug - GH MeshSplit doesn't split correctly (R5 & R6)

Give it a crack and let me know if it works for you! The implementation is not perfect, but it may do the trick…

Hi @tom_svilans. I have tried it on some of my messy meshes and, well, it basically works. Perhaps not superfast but acceptable.

Intersection sometimes crashes though, due to the bad meshes. I can’t really see why it should though, since bad meshes is what we deal with in reality. Cutting triangles should not crash, no matter what.

Boolean + doesn’t seem to produce valid meshes, an so they won’t bake. Etc. it would be interesting to find out why they’re bad though, so it could be fixed .

A mesh analyse tool capable of formally reporting problems with a mesh would help a lot with my bad meshes (so that proper repair actions could be performed as a post process). For now I will have to run “every repair tool available” out there., which makes it a bit slow.

Anyway, this looks promising.

// Rolf

Probably not. The GPL license isn’t very suitable.

Why?

Doesn’t that license only consern the development and enhancements of the library itself, and not including derivative work?

I’m not very well versed in license terms.

// Rolf

No, GPL is viral in that programs using libraries with that license should be published with compatible licenses, essentially meaning open source. Using such libraries in a closed source environment is not allowed.

This is the reason that integrating Cycles into Rhino became possible only when the codebase was changed from GPL to Apache.

OK, thank you for pointing that out. I would have missed that based on the simplified text I linked to.

Edit: BTW, isn’t it possible to split an application into separate functionality modules, well, plugins, in which one could “isolate” conflicting license terms, limiting it only to the individual plugin?

// Rolf

Perhaps ActiViz would be a better bet. BSD license should do? Massive community behind, 20 years of development and… oh well, what do I know.

// Rolf

Hi Nathan,

My memory is a bit hazy, but wasn’t this an issue back when Carve was considered for integration into Blender? I haven’t kept up… is it still in Blender or did the whole Bmesh overhaul change the boolean engine as well?

Cool to see you’re part of the Rhino crowd as well now!

It is still in Blender . I doubt the licensing has been a problem, since Blender is GPL itself, too.

1 Like

Bad meshes should be cleaned up, yes. The wrapper / plug-in is only as good and lenient as the actual Carve library :slight_smile:

What I’ve found to be a pretty good workflow is to do mesh work and clean-up in Blender - getting rid of loose edges and verts, patching holes, etc. - and then moving to Rhino / GH. I’ve been poking around with getting a Speckle client implementation (https://speckle.works/) going in Blender through Python, which works fine for meshes at the moment. I still need to sort out the finer details with Dimitrie and figure out a decent way to expose it in Blender…

There are other ways as well to move meshes back and forth without exporting / importing files…

The box split seem to have stability now. It is slow though, each box takes around 5 sec.

1 Like

That’s how it’s done! Speed is another project. :slight_smile:

// Rolf

Is this with Carve? There might be a couple small speed-ups that may help… hopefully I’ll have a bit of time soon.

No, it is done with the hacky-smacky-project I work on.
It uses XYZ oriented boxes and just splits the mesh, and is only for slicing up raw meshes.

2 Likes