Perfect - thanks!



Is there a japanese bow emoticon here? :slight_smile:

1 Like


This is just fantastic! I Love this package and you are a magician!
My Question: I have a collection of sets of 4 points on a spherical surface that together describe a diagrid. All the sets of 4 are non-planar, each defining a ruled surface. I want to nudge the points around to approximate the underlying design surface but get more planar panels.

If I send 1 set of 4 points to the Solver with Goals.CoPlanarGoal_Create and Goals.ShapeMatchingGoal_Create, I can get the set of four points to stay close to their original placement while moving to a more coplaner relationship. Hurray!

However, when I send more than one collection of 4 points (say, 3 groups of 4 points) the result from the solver is only 8 points. It seems to flatten the list structure AND eliminate identical points. So I thought this was originally just a list management issue, but it seems like the solver is doing something a little more complicated?

Essentially, I want to send multiple sets of points to run the same analysis and keep the orginal list structure



Hi Zack, I am really happy that you like the package. I have been a long time follower of your BuildZ blog since 2012.

Answer for your question:

  • You are right, DynaShape automatically merges coincident points into one “node”. This is essentially how we can set up a system where a point can be subjected to multiple, usually conflicting, constraints/goals.

  • If you want to keep track of the original list of points. Probably the easiest way is to bind a polyline to each group of points you want to track (like you already did). The Solver.Execute node will then output these polylines (as PolyCurve objects actually, because Dynamo does not seem to have PolyLine). You can easily extract the points you want from these output polylines. (Note: the polylines/PolyCurves are only output from the solver if fastDisplay is set to False. You collect them from the “geometries” output port of the Solver.Execute node)

  • Probably I will implement some sort of method to maintain and output the original nodes/points structure in the future.

1 Like


Sweet! Thanks @LongNguyen



Here’s my file if anyone else wants to try a little panel deformation rationalization. Needs Lunchbox package for the Diamond panels.
@LongNguyen, this is excellent and really fast, even with real geometry being generated.
One bug in this alpha/beta, I think: When point count gets over about 160 (40 ish panels) the analysis starts to get weird, seems to ignore the Goals.ShapeMatchingGoal_Create and just goes for planarity, ending up making a pancake.

Kronz_RationalDiamondBall.dyn (44.8 KB)


Dynashape problem
Dynamo dynashape

Great work.



Nice script. I was not even aware that know Dynamo has GaussianCurvature node out of the box. Will play with the file later this afternoon :slight_smile:



Could you please help me to resolve this problem ?



Hi, seems like there is no Dynamo folder located inside your computer’s AppData.

Can you please help me check by going to “Dynamo Main Menu > Packages > Manage Packages …”. Then click on the triple-dot icon/button on any package of you have installed an select Show Root Directory…

An explorer window will pop up. Click on the address bar so that the full path is showed. Can you please share the screenshot with me, like below:



Pls have a look at the below image.



@Zach_Kron: I tried your script with around 400 panels and it seemed to work fine :slight_smile:

I did notice, however, the solver tends to flatten the sphere into pancake if momentum is set to True and ShapeMatching weight is too high

  • Generally momentum is good for physical motion simulation (like in the cloth simulation example), and in many cases, it helps the geometric optimization reaches the solution in fewer iteration. But in other cases, it can lead to unstable and counter-intuitive result. So generally, for geometry optimization, I tend to turn it off.

  • The system in your script is obviously over-contrainted. The ShapeMatching goals are conflicting with the CoPlanar goals. In such case, we can mediate them by adjusting their weights (relative to the others). In the screenshot below I changed the ShapeMatching matching weight from 1.0 (default) to 0.2, this allows the the quads to achieve better planarity, at the cost of larger deviation from their original shapes



Excellent, thanks. What is the difference between setting the weight initially in the .Create node versus with the .Change?



The .Change nodes allow the goal parameters to be dynamically adjusted while the solver is running.

If you change parameters in the .Create nodes, they will only have effect after the solver has been reset.

I would like to combine the Create and Change nodes into one, but currently the ZeroTouch plugin framework does not make easy to do so.



Hi @LongNguyen

I have only one issue I follow the instruction but still can’t control the points through the mouse even in the background 3D view, can you please help !. please check the picture below. and Great work man (Love these nodes).



Hi Mohammad. Just a quick reply for now. I will look into this when I can. It never happened to me personally but at least one other user has reported this.

If possible, can you please try this on another computer?


1 Like


i have the same problem till now !



and here is a screenshot as you requested from my computer



Hi Long,

Great work! I’ve had some fun playing with it already.

A general question: does anyone know how to model pressure rather than a static force like gravity?

For modelling air-supported structures in Revit. :grin:

My guess is a vector force applied to a facet or vertex, but how to calculate that force is a bit beyond me… my high school physics was a long time ago!



Sorry for late reply, I am currently on vacation.

Generally, simulating pressure is just a matter of applying force on the the nodes along the normal direction. The slightly tricky bit is that the normal direction changes as the object undergoes motion, Because of this, we will need to implement a custom goal for this, rather than just use the “constant goal” that have already been in the package.

This is conceptually simple but will take a bit of works to code it up. I have added it to my to-do-list. Currently my main priorities are to make the tool more stable and improving the display/feedback

1 Like