OnCurve + SortAlongCurve

note, the mesh i am working with was originally made in Rhino as a group of 5 Meshes that were then welded and joined and the common vertices were merged and collapsed. therefore the points in the list which are being pulled to curve are incongruent.
here is the script I am using:

rbt_h0l_brepmeshbend-question.gh (58.6 KB)

I doubt I can help but note that you didn’t internalise the rhino mesh.

now internalized thank you

the question simplified is:
using Rhino6, and Kangaroo Solver with SortAlongCurve + OnCurve - how do you pull external points of a mesh to a Curve in a equal distribution instead of having the points (Mesh) to collect or gather unevenly?

In this discussion @DanielPiker posted a definition with a C# Kangaroo custom goal to repel points on a curve or a mesh I think. It’s in the attached definition.

You might be able to use this to hold the points on your curve apart and stop them bunching up.
knotrepulsion.gh (17.9 KB)

I can’t reproduce your first picture, for me it looks like this

My guess - one problem is that you used a closed curve for the on curve goal by that you auotmattically produce overlapping mesh faces (also the curve looks wired since you use interpolate). Further the bend deform the way you use it seems to have zero effect atleast in my RH6.

I suspect you could subdivide the curve by the number of points you want on it and use the target input of the anchor goal for equal distance between points. At the moment the load + on curve goal result in more points on the lowest part of the curve.

Could you maybe explain what you are trying to achieve?

rbt_h0l_brepmeshbend-question2.gh (50.2 KB)


the goal is to rotate parts of the mesh object independently using sliders. i have tried to isolate the curve describing the part i wish to rotate, using that curve to pull the vertices of the mesh to the rotated position but as you see, the vertices do not stay with the rotating curve. please help if you can, this project is due later today. thank you!!!

Okay, I rebuilded this entirely. In order to do that I projected the outer polyline of the mesh to world xy, baked it, fixed one edge, referenced it back and drew the rotation axes manually. I hope I understood how the rotation should work correctly if not maybe explain it to me in german (you are also german aren‘t you?).

The result:

190902_flappy_mesh.gh (30.8 KB)


thank you Daniel,
i will look at your file now.
is there no way to use what was formerly (in Rhino5 and old Kangaroo - not solver or bouncy solver) ‘PulltoCurve’?
also, I am half American and half German, born in Germany, raise in the U.S. so my English is much better/ faster than my German. however feel free to reply in German as i do like to practice.
thank you again for your help with this!

I can’t answer that, this is a question for @DanielPiker, for me it was much easier to solve this with the target anchor to keep the lengths between the naked vertices fixed since every try with the on curve goal resulted in moving vertices. A possibility could be to use the on curve goal with as many segments as naked vertices, so every vertex has it’s on segment to stay on.

I’m fine with english too :slight_smile:

That’s really cool, but raises the question… What on earth is it?

hi Daniel,

thank you again for helping me with this. i rewrote your solution and separated the rotation sliders for each of the 4 curves because that is what i need in order to further develop the figure using Firefly.

this project is part of a doctoral research and i would like to credit you Daniel if you like, if so lets think of a way to exchange information.

i am attaching my reworked grasshopper file here. i learned a lot from your solution in terms of new grasshopper commands. in the attached are a few questions if you had time to clarify but if not no worries.

thanks again!
rbt_h0l_brepmeshbend-solved.gh (56.5 KB)

Hey Aileen,

glad I could help. I developed my approach further and added the bend deform after the rotation. (the gif didn’t turn out that nice :/)
190902_flappy_mesh_v2.gh (31.4 KB)

Seems like something with the attaching went wrong, can’t download your file.

ok cool, will look at your second solution w/ bending thanks!

The thing I noticed first in your modified file - if you need to control each slider individually you don’t need to split the tree structure. Attached a version with it’s own slider for each axis.

190902_flappy_mesh_v3.gh (35.1 KB)

  1. Why use invert in the Polyline component?
    A: Normal state of the C (closed) input of the polyline component is false, for me the most visual + fastest way to set it to true is inverting it. Instead you could use a boolean toogle or panel or set the boolean to true manually.

  2. Why is the length the same as the number of times the polygon length is divides? (Simple Remesh)
    A: Frist of all I divide the polyline/polygon segments by it’s length/x (x is 2 in this case) to achieve a equal point distribution while keeping the original polyline vertices.
    You could use a higher number than x but not a lower (the component will fail then), I can’t really answer why, it was something I learned by try and error.

  3. What are creases here? Also as defined this is the enere polygon?
    The description says: “Curves which will be kept sharp druing remeshing. Can be boundary or internal curves”, so curves that stay the same while remeshing.

  4. Is tree needed here since output of flip curve is same?
    Uhm, I use flip curve to be sure every axis line has the same direction, since I didn’t draw them all in the same, just to be sure. I used the graft tree to establish a data structure I control and can easily work with since I’m not a fan of performing operations on one single list item and then need to repeat it for the other list items.

  5. What does graft do here? (A input of Rotate Axis)
    Well since I used a tree to opertae on with 4 branches, one for each axis, I need the same data structure for the rotation values. I did input a gene pool with 4 sliders and grafted it, by that every rotation value got it’s own branch. Since you did split the whole data structure in single list items graft is not necessary any more. Have a look at my v3, since I doubt you really need to split the data strucute, just use 4 sliders, merge the values & graft it.

  6. The thing with Entwine before inputing into Kangaroo GoalObjects
    A: It’s kind of similar to merge but it puts everything into it’s own branch. All goals can be in one branch but I guess you could put them in different ones, that doesn’t matter. (It’s something I saw in Daniel Pikers scripts and started to do it the same way). The show goal (is it a goal? dunno) should have it’s own branch, beste the first one, that makes it much easier to extract the final result out of the solver by just exploding the resulting tree and use only the first branch.
    For example if you input only mesh vertices into show and the first branch, all goals in the second one, run the solver and explode the tree after, all point are again in the first branch, so it’s easy to extract the result.

1 Like

Oh I noticed you slightly changed the polyline and axes, here v4 with them in it.

190902_flappy_mesh_v4.gh (29.6 KB)

Thank you @martynjhogg , maybe some kind of funny formfinding?