in the last days I was trying to implement the slime behaviour in C#.
It is working so far,particles are moving, but it is not generating the the pattern described by Jeff Jones(please see pictures below).
I was suprised high numbers(over 20.000 agents) are still possible.
As a base I used the obligatrios book by Jeff Jones and I also had a look at the sharpmatter library from @rawitscher-torres (thanks a lot for sharing!).Nicholas,may I ask you at this point, I cant seem to find where you set the status of an cell if it is occupied or not.
My project consists of 6 classes plus the Component:
the voxelgrid class ( used as a grid as described in J.Jones)
the voxel class (every voxel is built out of 2 domains(x and y)
the domain class ( just to store the bounds of the voxels)
the hypha class( its the agent if you will)
the fungus class( its the agentsystem, its a slime not a fungus, but when I started I was kind of confused)
the util class(for conversion radians to degree basically)
and finally the class inherited from the GH_Component class
Since its a lot of code, I think it might be better not to post it here, I attach it below.
The procedure as described in J.Jones and consists mainly of the two stages, Move and Sense:
Slime.zip (561.9 KB) 20200806_Slime.gh (18.7 KB)
I know its a lot of code and I cant point to the error nor ask a specific question, please excuse me for that!
Thanks anybody in advance, if I can contribute anything more in detail, please let me know!
that SharpMatter needs some refactoring I have gotten sidetracked and stopped committing to the repo for a while. Its in the Cell class I beleive, but doing occupancy check via how Jones explains it in the paper is the bottle neck of the algorithm. There should be a way to perform cell occupancy in a different way but I haven’t looked back at the code again. In general its also kind of hard to tell what is the actual issue that you are having, you will have to sit down and debug parts of your code.
Also for speed, don’t output the actual points, override the display methods.
public override BoundingBox ClippingBox
{
get
{
return //BoundingBox.Empty;
}
}
public override void DrawViewportWires(IGH_PreviewArgs args)
{
}
I already thought it will be difficult to debug for someone else and when I was asking it was mor for general advices,if I maybe overseeing/misunderstanding some basic principle.
I think I found why it is not working, I still dont know how it is happening, but at least I see where to keep digging: When I apply charge on the cell values it goes mad. Instead of adding one to the current value it goes between positive and negative 2146974010. Thats why the agents never follow their tracks , I assume.
Once I get it working I will take care of speed things, like display, parallel loop etc.
Do you mean the laplacian?In the version I posted in the morning I still hadnt implemented it, but now its integrated.
I was debugging the single steps and found some errors, as the one mentioned above, but it still seems they are not getting attracted or, stay at the fields with higher attraction.
Hi Benedict,
thanks for the advice!
I had a lot of redundunt stuff going on there, so I decided to start again, keeping everything better organized.
Still a lot to do but I am getting closer:
Good, it looks correct now. The only faster way would be to do it in Open Frameworks in C++ and do all the display on the GPU. Or option 2 that rhino rendered those points as a single object and not as per point.
Yes, I totally agree! C++ (openFrames, Cinder, etc.) with shaders would be the way to go, if we’re talking > 100 000 particles.
For less, you can probably get away with C++ code without shaders, but your code needs to be pretty niffty and optimized. For instance, if you do a lot of distance measuring for NNS (nearest neighbor search), you’d want to implement binary tree searching (QuadTree, k-d Tree, R-tree, etc.).
openFrameworks is great and free. If you’re into coding, I can highly recommend it (and forget about C#).