Grey/Scott running on a mesh

An adapted and optimized version of my Grey/Scott reaction difusion code, which runs based on the topology of the Mesh. The animation is realtime, the lag in the middle is because of the recalculation of the topology information.

It is run with the mesh wires previewed to show that it is a high density mesh.

20 members like this

Get Embed Code

Tags:

Comment

You need to be a member of Grasshopper to add comments!

Comment by Jens Pedersen on August 20, 2015 at 2:48am: Cool i might give that a go:)

But yearh some times it doesn't do much in terms of speed increase unless it is as I said a threadable problem.. I've also seen examples where people are writing threaded loops, but in a way so they work like regular loops- meaning they queue the data send to the threads rather then a free for all type situation.

Also it speeds up things a lot when you are running through a lot of data, this is a mesh with 10.000 plus faces/vertices..

Comment by Daniel González Abalde on August 19, 2015 at 4:27pm: Amm, I had already applied the parallel.For... I guess it's slower than yours by the capacity of my computer (6 years, 2 cores, I insult and mistreatment him almost every day...). I had not noticed a significant performance improvement, so I thought it was something more complex, though I'm not sure at all if my code is threadable...
Okay, for comment, a good trick to manipulate patterns or play with, is to control the indexes of the neighbors to route patterns. For example, if you double/duplicate the closest neighbor index to a external point in each vertex, the diffusion will move faster towards that point.

Comment by Jens Pedersen on August 19, 2015 at 3:23pm: I just use the .net implementable version of threading it is pretty easy, but you need to know whether or not your code is threadable... and be carefull, I have had a tone of problems with it...

I am essentially using the Parallel.For comand, which distributes the calculations to each thread, but this messes up your loop order, ie what I was talking about knowing whether or not your code is threadable...

Comment by Daniel González Abalde on August 19, 2015 at 9:04am: Well done :)

In each iteration you send the U, V values of each vertex to the threads available, perform calculations and then you extract the new values for the next iteration? or perform the entire process always within the threads? I have not managed to optimize my code with this, but only use a few lines of code :]. Could you give us some clue about using threads in this case please?

Comment by Jens Pedersen on August 16, 2015 at 3:52pm: There is some multithreading going on yes.. I actually havent tested it wihtout threading. But I assume it will be pretty fast though, since all the topology is build before hand, so all it does is loop through a single list.

I was really taked back by how heavy the Mesh.Vertices.GetConnectedVertices comand was, cutting that out cut the code down from 500 ms, to 20ms....

Anyway I can show you if you poped by Aarhus with Anders :)

Comment by David Stasiuk on August 16, 2015 at 3:42am: Nice! i'd live to hear a little about the strategy you're using...is there any multi-threading going on?