algorithmic modeling for Rhino
Hi Daniel,
I am working on an algorithm that can help to automatically organize components on the grasshopper canvas. It is going quite well in that I am able to create a rough optimized layout of all the components. See attached images.
Before cleanup
After cleanup
After the first run, I would like to tweak the position of the "in between parameters" to create strictly horizontal connection curves and ideally concentrate any "vertical" wire movement only in certain areas. (as illustrated in the 3rd image.)
I have a feeling Kangaroo might help me with this. However, I'm running into some issues.
I would need to be able to have kangaroo drive the location of the component, but the input and output parameters need to move with the component. These input and output parameters will drive the location and shape of the connecting wires, which should be optimized for as many horizontal ones as possible.
Could you help me get started, by explaining how I would setup these constraints using kangaroo? I have tried for days, and my head is hurting...
Tags:
This would be a great debugging tool. My more complicated definitions can be hard to follow, especially when I look back on them a few weeks after completing a project.
Here are a few fixes to that file.
To have just 1 connection become straight, I made a custom goal (you'll need to update the referenced assembly location) which snaps the Y components of two point locations together if they are less than some cutoff distance apart.
I also switched the collision detection to spheres, which is simpler than Collide2D.
This is just to help figure out how this setup could work - I think eventually you would want to have this all in a script. I think there may also be significant improvements in efficiency possible if it made more use of custom goals, since your constraints are mostly 1-dimensional.
You may also want to look at yEd and Graphviz. Both are able to automatically layout complex graphs.
http://www.yworks.com/products/yed/applicationfeatures#AutoLayout
Hi Eric,
Thank you for the suggestion. The first pass is indeed done by Graphviz. However, the result is not exactly what I'm looking for so I am exploring ways to improve. Any suggestions are welcome!
That's really interesting, I've been working quite intensely with integrating Graphviz/Dot notation in my Grasshopper/GHPython lately (for stuff like this). What kind of issues are you having with it (layout-wise)? Also, really great work. Look forward to seeing where it goes. I believe someone already implemented something similar for Dynamo, might be worth checking that out as well.
Ps. here's a paper describing the Dot layout algorithm used by Graphviz. Been thinking about implementing it in pure Python for a while now. One day..
Edit: Here's the Dynamo function.
Dear Anders.
Thank you for your reply. Those are some excellent references. Your work at SmartGeometry this year is spectacular.
Also the Dynamo thing is indeed very similar to what I'm trying to do. And I believe at the moment, I am kind of at the same point these guys were when the post was made.
However, as a designer, a have some very specific desires when it comes to laying out my GH graph.
Most algorithms try to get the edges as straight as possible. My desire is to get a many edges as possible absolutely straight. It's a subtle difference, but big in aesthetic perception.
Also, I work a lot with floating parameters for 2 reasons:
1. To route the edges however way I want avoiding any and all collisions
2. To add a description (name) to the parameter (like naming a variable. I have created a custom object in EleFront to this extent)
I would like to be able to prioritize the straightness of edges connecting to inputs and outputs of components over the straightness of edges connecting from one floating parameter to another. The second image in my post below shows what I mean by that.
Anyway, any more input you may have is highly appreciated.
Hi Daniel,
Thanks for your response. I was able to work your custom goal into a working global definition. It works quite well, and may actually provide a way forward. However, as you may see in the animated GIF below (you may have to click it), the current configuration does not allow components or parameters to "pass" one another:
If the wires are tangled at the start of the solving, they will remain tangled when the solver is done:
The reason is that there is a collision goal as well as an axis anchor in place and so these two goals working together prevent any order shifting in any column. Would you have a suggestions to address this issue? I'm basically looking for a way to allow the components to pass one another, but ultimately never overlap.
Also, I couldn't use the sphere collision goal, as it only accepts a single radius value. The GH components each have different dimensions, So I ended up using the (probably less efficient) "collider" goal. Is there a way to have the SphereCollide goal to take one specified radius per point? (see image below).
Your help is again much appreciated.
Ramon
Looking good!
As I hinted at in my last reply, for the collisions, the most efficient is probably going to be to make a custom goal which operates only in the Y direction.
The method used in both SphereCollide and Collider is something called Sweep-and-Prune, which sorts the bounding boxes along one world axis, and then only for those which overlap in this axis does it check if they overlap in the other directions. By ruling out early lots of potential collisions(if the bounding boxes of a pair of objects don't overlap in one axis, they can't be colliding) this avoids having to calculate a costly everything-against-everything-else distance check.
However, in this particular case, it looks like you already know which components are in the same column, so we really only need to find collisions between these, rather than between everything on the canvas. Also, since we already know they are aligned in X, we only need to check for collisions in Y (The current collision components always do this sorting in X first, so not very good for this application). So I think it will be possible to make a modified version of the current collision code that might be faster.
About the tangling issue - One solution might be to run a first pass with weak or no collision strength to let them find their ordering, and then increase the collision strength to push them apart.
You could even run it all in 3d at first, and then squash everything down onto the plane. Maybe not the most practical approach, but interesting conceptually.
Hi Everyone,
For those of you who have shown interest in this project, I'd like to announce that a first incarnation has been posted on Food4Rhino. Unfortunately, at the moment it is not yet utilizing any Kangaroo functionality, but that might change in the next version.
Please feel free to check it out and leave your comments.
A group has been created here:
http://www.grasshopper3d.com/group/autograph
Download:
Well I always enjoy my hundreds of complicated bad ass looking wires :D
But I just downloaded and Installed it. and I think it was TOTALLY AWESOME ! Bravo !
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by