Create volume from separated mesh faces?

Hello everyone,

I was wondering if what I am trying to do is even possible. I start with a mesh (black in image), from which I move and scale the faces (green). These faces act as a perimeter of an imaginary nucleus. Is it possible to create this volume from these faces? (Something like the red line).

All faces have been moved and scaled by the same factor.

Mesh Volume.gh (28.8 KB)

For a given topology vertex (MTV) first sort the edges (this yields a clock wise MTV neighbor collection). Then use connectivity VV, VE, FE to bridge the gaps ((1) edge to adjacent edge (yielding a quad and/or tri mesh), (2) vertex to all adjacent edges (yielding a tri mesh)). Note: If you have mesh Lists … Sandbox does quite odd connectivity trees.

Don’t forget to combine identical vertices when the appended mesh is made.

This does a “similar” (well … kinda) job using the MTV sort Method.

I could easily modify it for doing what you want (you only need to bridge the poly vertices shown [quad meshes] plus the vertex to poly vertices [tri meshes]) … but it would be a solution using 100% code.

Hello Peter, it can be done then? Great. Thank you. If you could modify the script that would be awesome, not problem with it being solely code.

Maybe I could try to replicate it with native componets later as practice!

I always admire the brave. The thing would include lines of ultra freaky stuff like this (what tthese lines do? who cares? and who knows?)

The thing was ready 10 minutes after … but then I said to myself: what about adding some freaky struff ? (offset vertices, distort randomly this (and that), do some Maelstrom morph … blah blah).

Then … alas … the CEO of my practice (I’ve transfered ownership to him for taxation reasons => get THAT IRS) spotted me doing the freaky thing … and the C# is posponed for after 5 pm.

So until the thing is ready get the “equivalent” for breps (kinda) and try to find the Truth Out There with components.

Brep_move_brepfaces_V2A.gh (128.4 KB)

2 Likes

More delays > major changes > fired that ungrateful top dog + all the personnel close to him > hired new staff > new world order > …

Here’s the current practice status (BETA):

Here’s what you’ll get soon (4 mesh types [ so to speak]: 1. quad bridges in naked edges, 2. quad bridges in clothed edges, 3 tri meshes from the (as above) sorted MTV loops, 4 tri meshes from offset face vertices). Shown 1,2 types for clarity:

Of course if a mesh in a given List is closed > no bridges of type 1.

Hahah thanks!

I tried the brep version by inputting the face boundaries of my meshes, strange results followed. It does not work with non planar stuff right?

Don’t mix onions with sardines. The soon to be released mesh version works on a totally different approach (especially in open meshes [as in the screenshots above]).

In the mean time my new CEO delivered the goods from day zero > that’s my man (worth every banana I confess) .

Screen%20Shot%20009

Here comes the pain (Nothing is internalized [ I never do that] => load R file for the demos).

Mesh_MTV_VS_MV_vertexIndices_V3B.3dm (235.8 KB)
Mesh_MTV_VS_MV_vertexIndices_V3B.gh (142.8 KB)

That said I have absolutely no idea about C#, D#, E# … Z# > I’m only the business man (and I hate computers) > work is done via my new IT guru (feel free to ask him for anything related with these freaky defs). Guru said that he removed the offset vertex option due to speed reasons (he claims that the thing is using 3 passes with different indexing [VTV, MF, MTE] meaning delays for this, this (and that) reason). But if you ask me he’s trying to avoid writing some lines more.

Hi Peter,

Are you sure this does what I described in my OP? I cant seem to make it work with my meshes. In the examples you provided no volume is generated from separated mesh faces.

This works as follows:

Given a mesh in a reworked List (auto split disjoint pieces + auto triangulate) it does a new mesh by (a) offseting (var: move) face vertices inwards and then (b) bridging the 3 new vertices with the adjacent naked and clothed ones. Meaning that if the donor mesh is closed you’ll get a closed mesh as result as well.

In plain English:

From here:

To there:

So in a way the faces due to the offset (move) on vertices (as in (a)) are engulfed in the new mesh.

Or you need to sample these in a new collection as well?.

Or you have N mini meshes and you need to “connect” them? (that’s reverse engineering of the worst kind: I mean IF the mini meshes are due/from a mesh why bother talking???). Ot you have N random mini meshes (and no info from where they come) and you want some sort of “3d convex hul” ? (so to speak) - if so that’s a special ball-pivot thingy (all my related stuff on that matter are strictly internal - no post is possible).

On the other hand see the attached that does some stuff more. Do you need this new offset ability to work on both sides for a given mesh face? (creating a mesh with 8 faces per face).

Mesh_MTV_VS_MV_vertexIndices_V3C.gh (146.5 KB)

Is it so? Shame. Note the meshes are not random, they are simply moved along their normal and then scaled from their center. They come from the mesh in black wireframe in my first post. Maybe this simplifies things? You tell me.

Exactly they are due/from a mesh. Is that good or bad?

I’ll take a shot in the dark, since I’m not sure what exactly you are after. Maybe something like this:


Mesh Volume_mod.gh (19.1 KB) requires Weaverbird.

Thanks Luis, I see you replaced my move by normal and by z with an offset, and my scale with the mesh window. Sadly I need to control how much each face moves in the normal direction as well as in the z direction. (not individually for each mesh face but for the amplitude of the normal and the z vector).

In the picture below I try to show the operations performed on each mesh face of the original mesh:

  1. Orignal Mesh Face
  2. Move along negative normal direction.
  3. Move in z direction.
  4. Scale.

The result:

What I am trying it to have a solid volume out of these now.

Wouldn’t it make more sense to perform your operations on the mesh vertices while retaining all the connectivity, and then perform the face tesselation etc. afterwards?

Wouldn’t the result be the same? I mean supposing I do the operations on the vertices for faster computing, when I construct the mesh again, the result would still be those mini meshes you see in the picture, or I am missing something?

Nope, the way meshes (in Rhino) work is by having a ordered list of vertex points, and faces which simply reference which vertex indices they are connected to - GH represents this by T{i,j,k} meaning " Mesh Face between vertices number i, j and k" . You can experiment using the Deconstruct and Construct Mesh components:

image

Mmm I am getting the same result with either method. Maybe I am doing something wrong?

Mesh.gh (22.8 KB)

I can’t get you AT ALL:

  1. FORGET your faces.
  2. Input the mesh in question in the V3C (or input some List). Each mesh is auto triangulated and splitted (if there’s disjoint meshes around > see demos).
  3. Enable offset.
  4. Set offMin == offMax (this does a move “along” the face normal whilst the move variable offsets inwards the face vertices [using the face center] ). If these values differ then each face is moved outwards/inwards using a vector: faceNormal * rand.NextDouble(offMin. offMax)
  5. Is the result what you are after? (Your faces are PART of the new mesh created: simple as that and the new mesh engulfs the faces [well … that’s obvious]). The only question - as I said - is: do you want them sampled in some Tree? (as MeshFaces or Meshes or Breps or cats or dogs).

simple or what?

Sorry Peter, I will try to be clearer:

Top: What I am after (Step 1. and 2. done, trying to achieve 3.).
Bottom: What I achieved with your instructions. Was this spiky result what you had in mind?

Note my method is not the same to scaling the whole mesh and then the faces individually, because I am moving the faces by 2 vectors with different amplitudes. (Normal and Z negative).

Mesh_MTV_VS_MV_vertexIndices_V3C_Internaliced Mesh.gh (34.0 KB)