mesh optimization

I figured that before Daniel Piker drops another giant pile of awesome on all of us with dynamic bottom-up mesh topology optimization in kangaroo, I'd share a little bit of some stuff I've been doing on and off for the past several months. I've been thinking about organic mesh modeling based on driver curves for some time...mostly because of a design idea I have kicking around in my head, but also because I've liked many aspects of the meta-ball to mesh stuff that's been going on, have been amazed by the isosurface tools available in Millipede and have been inspired by Mateusz Zwirzycki's work with Starling. What I've been interested in is focusing on the the intersections between mesh segments. The meta-ball/mesh-from-points approach creates even geometry, but the topology doesn't seem particularly well-rationalized, and I'm interested in those moments of intersection.

I've also wanted to try to engage in scripting with meshes on a deeper level for a while, so in my down time in the spring I started up on this, but I now have a little more time to explore it as a vehicle for my research. Lacking the deep skills that might allow me to develop, for example, a physics-based engine that can dynamically re-write mesh topology, I've instead been focused on a top-down approach...it uses driver curves, hexagonal paneled mesh tubes, a stitching algorithm, and then a series of topology optimization passes that apply optimized patches where possible to create a unified, closed mesh. Finally, with a little love from kangaroo and weaverbird, I do some dynamic laplacian smoothing and extract the dual.

There is still a lot more room for further optimization, and there are several approaches for me to take...it's a matter of writing the code and/or waiting to see what Santa (aka Mr. Piker) possibly brings for us in the coming months. I suspect that starting from a point that's at least a bit closer to an optimized mesh will accelerate the impact of new functionality in kangaroo...in the meantime, this has been a great exercise for me to better understand scripting with meshes...

update: Thanks for the interest everyone! In response to Andrew's request for further explanation regarding the stitching process:

Walking through it...we begin at (1) with just a series of adjacent and overlapping hexagonal mesh tubes. The first phase of the script (2) identifies any mesh vertices that are either too close to or lie within another mesh, and it extracts all faces associated with those vertices. Then (3) the script searches all of the newly naked vertices for proximity to other meshes...it seeks the closest point and (where possible) tries to match up the topology so that the resulting initial stitch will lead to a hexagon...any place where two vertices on different initial meshes lie within tolerance it splits the difference between the two and welds them together. The topology optimization strategy here is very primitive, and I think further refinement will be able to create a better result. The next bit (4) first takes the naked polylines left over from the newly welded mesh and makes sure that they are split at any self-intersections. This took a bit of time...often, naked polylines return curves that cross over themselves, which obstructs the next part. Here (5) each naked polyline is analyzed iteratively, triangulating in sequence along the lowest angle between segments...so it looks at the polyline, finds the lowest angle, builds a mesh triangle, rebuilds the polyline and then repeats until each polyline has been fully stitched. Here again I think there is room to improve the topological optimization process. Next (5) comes a smoothing process with weaverbird's wonderful laplacian smoothing component. Finally (6) the mesh is ready for testing against the patch database for any pentagons, heptagons and octagons that can be re-worked to maximize the hexagonal duals in the mesh.

Next Post >

Comment

You need to be a member of Grasshopper to add comments!

Comment by Shirley Murphy on July 27, 2022 at 11:43pm: Buying thesis online. I'm a college teacher, and my students say I'm unique because I don't consider buying thesis online something illegal and harmful. They rarely tell me that the buy thesis proposal they submitted was bought online; even if I detect it, I put the grade it deserves. 90% of my colleagues don't understand me, but I remember how I felt when I was a student loaded with an enormous amount of work. I think the reasons for my position are obvious, aren't they?

Comment by Maria Haack on February 8, 2018 at 1:18pm: is there a downloadable file for this? I am a rookie at this and I am wishing to make some interlaced vertical "worms" similar to these

Comment by AJ on May 20, 2016 at 2:29pm: David

thanks for answering. the meshmachine and remesh (SI) are amazing

but i got result that is not as organized . so instead of hexagons (using dual mesh) i get 4/5/6/7 point cell. where i wish to get only hexagons.,

http://storage.ning.com/topology/rest/1.0/file/get/2654970959?profi...

saw this link a just now... i look to make the grid as clean. as i use lots of patched surfaces, i thought re-meshing them would be the only way to make then a one domain and to organize the mesh grid . however since its curve related it is not what i would like to learn.

also i saw this page http://www.grasshopper3d.com/forum/topics/space-frame-mesh-modellin...

where in this discussion, David , you have dropped TetTruss.gh

i think im looking for something like this to be applied to my mesh. this way i can have a clean and organized mesh, ... as if i would have been using T.map (evolute tools) with the ability to paly with the mesh grid size.

http://www.grasshopper3d.com/forum/topics/t-map-patched-surfaces-me...

here is a discussion i started today, with images and GH file(internal brep)

cheers

A

Comment by David Stasiuk on May 20, 2016 at 12:41pm: Hi AJ-

Have you looked at MeshMachine at all?

Comment by AJ on May 20, 2016 at 8:26am: hi there hoppers

this is an impressing old thread

how would you be meshing a collection of patched surfaces (not matching at all and different UV) to generate a clean tri or hex grids

thnx

Comment by Luisana Hernandez on April 20, 2015 at 2:45pm: hello! would you be so kind to share the script for this, please?

Comment by Nick Tyrer on January 8, 2014 at 4:00am: 'the more I learn, the more I learn how little I know'

Unfortunately i can't use VB so to me you sound slightly like a mad man! But i appreciate your detailed explanation, the valence optimisation is really interesting, i had previously only come across mesh edge valence, not mesh vertex valence. i have many things to add to my reading list.

Thanks again, i will be back in a year!

Comment by David Stasiuk on January 7, 2014 at 2:47pm: Hi Nick. Thanks! That part was all managed through vb. At this time I relied very heavily on the Rhinocommon Mesh class for reading and editing topologies. I set up the system to identify for each vertex an ordered sequence of neighbors with different valence counts, and tested these sequences against the patch database I had developed by sketching fixes. It really was a fairly ugly process...very "top-down" for sure. Additionally, because editing topology in Rhinocommon tends to break several useful lookup tables, this process is rather doubly slow because the entire mesh needs to be re-indexed whenever a single patch is identified and applied.

Since then - and since Daniel and Will Pearson have published Plankton and Daniel has pointed me to a great paper that address this same issue of optimising vertices for regular valences (six edges per vertex) using edge-flips/vertex splits/ and edge-collapses, I've revisited the entire process. I haven't had a chance to thoroughly document it yet (it's actually all part of my research project, so still very much in process). I have a couple images of pre- and post-optimisation here:

http://www.grasshopper3d.com/photo/pre-opt?context=user

http://www.grasshopper3d.com/photo/pre-opt/next?context=user

This setup is very much bottom-up, and runs waaaaay faster...there's much more to it, but the basic logic is pretty simple for the main operation, which uses an "edge scoring" process to determine if flipping an edge would result in better overall valence. That is to say, if you flipped an edge and the affected vertices all got closer to a six-valence condition, then it's an improvement. So, say for example that both of the connected vertices for an edge each had a seven valence and the opposite vertices each had a five valence, then by flipping that edge, you'd reduce both sevens to a six, and increase both fives to a six (if you look at the patch database in the post here, this example is reflected in the first "patch", which is labelled "7,5,7,5").

All of these operations I also do in VB, and I use Daniel and Will's Plankton library to do it...the half-edge mesh data structure it uses is fantastic for only locally affecting indices...so when you make a change, you don't have to reindex your topology tables and can just continue to iterate through your edges.

I don't know if this helps at all...let me know if you'd like to hear more...but I guess the short answer is yes, I'm relying heavily on scripting throughout these operations...

Comment by Nick Tyrer on January 7, 2014 at 11:34am: David. Found my way back here. Still cool over a year later. If possible could you please tell me a little more about stage 6. Whats the patch database? is that step gh or vb?