I have a mesh generated by Tomohiros’ freeform origami imported as .obj in Rhino and Gh. There are total 40 mesh faces and they are pretty much sorted in the way I want up until index 30 - after that it all starts to get funky. Optional question: Does anyone know what could be a reason for this sort of semi-ordered behavior?
Real problem is that I want to sort the mesh, or at least find a way to manually swap indices of faces and get them in order. Suggestions?
Tnx.
if you can do it manually once you might try this:
_Unweld with an angle value of zero, then _Explode, deselect everything and _Join the mesh pieces in the desired order by picking one by one. Once done use _Weld with an angle value of 180.
_
c.
Nice! Didn’t think of making changes in initial geometry…
Just solved it with simple split list and insert item in GH. I had to type in indices manually but it does the trick. Maybe someone with more elegant solution?
Anyway, thanks @clement!
Attach your mesh, you can sort along curve (naked edges)
In general mesh faces are enumerated NOT the way that you expect.
For this particular example you can use connectivity DataTrees (FF, FV etc) and do the job. It’s rather simple given the fact that you have 3 classes of vertices (naked, clothed with valence 6 and the one with valence 10) … or impossible if you are not familiar with what a connectivity tree is. Since we have vertices, edges and faces there’s 9 possible combos for these trees.
Given the opportunity: V for conn trees stands for Topology vertices indices and NOT vertices indices (V indices are related with mesh Normal indices) whilst E stands for Topology edges indices and F is just face indices (related with mesh face normals as well).
You can “convert” a TV index to V index and visa versa.
Where can I learn about connectivity trees? Any good resource?
Not sure … but I guess that in the old GH Forum must be some related stuff around. That said I had many CT cases made with native components (for helping users from time to time) but in a recent clean-up I’ve removed them all leaving only defs made 100% via code (which I guess is not what you are after).
That said Sandbox does some connectivity stuff > try to get the gist of the whole thing using it against graphs, breps or meshes.
A CT (“connecting” ListA and ListB - these may be the same, mind) is an int type of tree where branch indices come from ListA and items are incides from ListB.
For instance a FF mesh tree works against a meshFace List (A=B) and tells you which face (by index) has adjacent faces (also by index). A VV tree does the same working onTopology Vertices. A FE tree relates Faces to adjacent edges (A = Faces, B = Topology Edges) , A EF tree does the inverse , meaning that if a given Edge has 1 adjacent Face … it’s a naked one.
BTW: Sandbox fails to deliver (i.e. the 2 dimension CT trees that one expects) IF Lists are used: first dim must be the index of a given mesh in the mesh List and the second dim the index of some V/E/F (for that mesh).
See what it reports against a 5 mesh List (hard to understand what these CT trees mean):
Here’s how it should be done (via code):
So for your tests against CT and if you use Sandbox don’t use Lists.
Peter,
thanks for the reply. I understand the logic behind CT, and I can see what are the shortcomings of Sandbox. Unfortunately I’m not that fluent with scripting so that I can write the whole thing by myself from scratch. I used M+ plugin to get the topological relationships between E’s & F’s. I don’t mind using and modifying scripts, but this time this was much faster.
Thanks for help and intro to the field of CT’s. I believe I’ll be dealing with this sort of things in future…
Appears that there’s light at the end of the tunnel. BTW: If at some later time you are ready for the right thing (or you need some sort of help)… drop a word.
