algorithmic modeling for Rhino
Differential growth in Grasshopper
The definition and code is in the comments bellow.
This is related to this thread:
Hi Vicente Thank you for posting this script.I was wondering if a typical Mesh component could work with your Differential growth script ?Is there a reference in your C# code that allows only WB components?I'm not very C# proficient yet, still I'm trying to learn, ....very....very painful an slowly! I was trying to replace a Mesh component in your script, and referencing a Torus.The script bombed, too bad there is no KILL computation component in grasshopper :( cheers!
Vicente, Great work like always!!!! great simulation....
Thank you. I guessed there had to be a catch, but it seemed like a very simple (lazy) solution to the problem of parallelizing the calculation of forces that could affect the same particle (like springs).
Each particle has a ConcurrentBag that is accessed by different forces in parallel storing how much the force wants the particle to move. This list is added to a single vector at the end. Other alternatives might require more book keeping.
The main bottleneck I think is the edge splitting which is not multithreaded. I'm sure it can be parallelized up to some degree (by locking neighboring springs, not sure).
Still, someone smarter than me can probably make all of this faster, multithreading aside.
You might want to make some tests on ConcurrentBag though. I initially considered it for Kangaroo, and found that the large overhead of initializing it outweighed any benefit.
I fixed the mentioned bugs, the new file is here.
- The issue with wrong normals was because I assumed that Rhino's mesh object returned the two connected faces of an edge always in the same order.
- Now every time you run it behaves differently. My guess is because I decided to use new thread safe unordered collection called ConcurrentBag to store (in parallel) which springs have to be split. The order of the objects stored in the collection is not predictable, but the order in which the springs are split matters. This is simple to change if you want it to always behave the same.
- I should use a smarter way for 'converging' but my girlfriend was laughing at my nerdiness when I was trying to read about numerical analysis.
I replaced distance checks with checking the square of the distance. This avoids lots of square rooting so it's much faster.
I probably wont get around at fixing the issues so I'll just post it as it is for now (a bit of a mess). You can download the definition here.
- The way I keep the connectivity between faces/edges/vertices is not the most elegant, should've used something like a half-edge structure.
- I probably messed up something with the multithreading.
- It includes a simple octree class I wrote based on the pseudocode from the Wikipedia article of quadtrees. I use this because the rtree class is not thread safe even for searches. I haven't tested it but wouldn't surprise me the rtree class is faster even single threaded (I was hoping this stops being the case when its starts to reach tens of thousands of particles.
Great! Its seams that these forms are more and more accessible in grasshopper. This is my second highlight already this summer after Daniel Pikers recent growth contributions. Would be nice to play around with it for sure!
Sign Upor Sign In
by Mostafa Alani
by Parametric House
by Si Han Ho
Added by Mostafa Alani
Added by Farid Fadlillah
Added by CCal
Added by Parametric House
© 2019 Created by Scott Davidson.
Report an Issue |
Terms of Service
Please check your browser settings or contact your system administrator.