I’m taking a 3D mesh, generating the mesh graph nodes (Ivy) and generating an 2D mesh with the same connectivity. I orient each mesh face triangle on the corresponding 2D mesh node, and want to run a kangaroo collider so these triangles do not intersect.
That’s working great but I’m wondering the best way to keep the mesh graph connectivity information so that it will update when I run Kangaroo collider. Ideally the mesh graph would have angle constraints so it wouldn’t twist, and instead just expand until each triangle has enough space.
My intuition says to make my own mesh graph from the triangles in order to keep it with the simulation, but I’m thinking it might just be the lines and not the same connectivity order… Any advice would be appreciated
190903TriangleCollisionWithMeshGraph.gh (43.8 KB)
Kangaroo has a goal
Show component to help you preserve information before and after the simulation.
Yeah I’m using that - but because the mesh graph connectivity is based on the whole mesh and not the separate mesh triangles - when I run the collide, the graph is visible but not updating based on new triangle location.
That’s because the graph is not anchored on (does not touch) any triangle vertices. First hack off the top of my head would be to subdivide the triangles to have a vertex at their respective centroids, from which you can “attach” the graph to.
Yep this post is looking for the best way to anchor the mesh graph to the triangles while maintaining the same connectivity as the whole mesh. Originally I subdivided the triangles with wbTriangle and connected those center vertices but that data structure does not work in a way that I can use the GraphToMesh components after the simulation is run. Using Ivy not for unrolling strips but for maintaining data structure of connectivity.
Ok, then a last suggestion would be to look at the
MeshTopologyEdgeList, for each edge you can track the connected faces. You could assign the connectivity info to each edge and retrieve it after the simulation to recreate the graph. Maybe it could be done as well using Ivy but I am not familiar with the plug-in, unfortunately.
190903TriangleCollisionWithMeshGraph.gh (29.5 KB)
It gets simpler if you use CurveCollide to do collisions between whole triangles, instead of collider which is just working on individual segments. Each rigid curve is tracked by a point at its centre, which already coincides with your graph points. If you do want to keep that offset, you can just scale the triangles about this centre for the collision, and scale them back again in the output.
(or alternatively, offset and use the rigid curve’s frames to orient the original curve as shown here Aesthetic Part/Pattern Nesting?)
Awesome thanks for the help! I wonder @nejur is it possible to “deconstruct the mesh graph” and then “reconstruct it” with different curves?
Alternatively I can make sure the single mesh stays in the simulation and updates by using
wbTriangles, but subdividing the mesh will of course change the meshGraph substructure so not very productive. Wonder if there is a simpler way to retain the single, un-subdivided mesh through the kangaroo sim @DanielPiker ?
silly question @PaulPoinet how do you change the formatting for “Show” when highlighting different component names? I’ve seen Piker reference it before but I’m not sure if it was in meta or Markdown or where on the forum and cant find it now
would have been happy to google but didn’t know it was called discourse code formatting. thanks
To be fair, Discourse uses CommonMark (i.e. a flavour of Markdown) as far as I know. And I still see formatting around here that is not documented in the CommonMark Help. Such as the boxy highlighting that for instance @DavidRutten sometimes uses to represent GH component names.
The Component formatting is just HTML…
All good - had tried the ’ and didn’t notice it was a ` instead. TIL, thanks!