Differential growth

Comment

Comment by Kim hauer on July 15, 2015 at 2:47pm

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!

Comment by I_M_F [Iker Mugarra Flores] on July 14, 2015 at 10:15am

 Vicente, Great work like always!!!! great simulation....

Comment by Vicente Soler on July 14, 2015 at 8:02am

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.

Comment by Daniel Piker on July 14, 2015 at 7:32am

Very nice!

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.

Comment by Vicente Soler on July 14, 2015 at 5:52am

With intertia.

Comment by Vicente Soler on July 14, 2015 at 5:51am

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.

Comment by Vicente Soler on July 12, 2015 at 5:39am

I replaced distance checks with checking the square of the distance. This avoids lots of square rooting so it's much faster.

Comment by Vicente Soler on July 11, 2015 at 10:01am

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.

Some notes

- 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.

Comment by Christian Schmidts on July 11, 2015 at 9:14am

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!

• ‹ Previous
• 1
• 2
• Next ›
• Page