This is so cool! You can definitely tell how much faster it is when you ramp it up to about 1000 agents haha.
A have a few questions, out of curiosity, if thats ok?
How long have you been using gy/python to get to this level? As seeing how effective this is at tackling this problem, it is something I would love to keep learning.
I tried to test this out with polyline routes that are also in the z axis; our model has agents starting at their home points - which could be in a flat in a tower block, i.e. at say 100m elevation. To which the tool then generates a line vertically downwards to start the route. However, when doing this the script crashes - I’m guessing it just wasn’t meant to be used in 3D?
Ooo actually another question - I tried editing the scipt a little so that each agent starts their journey at different times, so that it represents a day cycle with each person having a set routine. (and therefore a set destination, and set departure time e.g. +500 “steps”). But got nowhere haha - how would you go about achieving this?
I’ve started learning Python maybe 6 to 7 six years ago. It’s hard to exactly pinpoint when.
I didn’t start in Rhino though, but rather because I was interested in learning how to program. At that time I had only very little experience (and incentive). Only some HTML and CSS, because my friends and I liked to do homepages for fun in high school.
The first couple of years, I remember doing exercises and tutorials here and there from time to time, but I didn’t take it too seriously. I did like the idea of knowing how to program, but really had no idea what to do as a project. Thus progress was really slow.
Later at university, I was often times confronted with geometrical problems related to experimental architecture that weren’t easy to do with vanilla Grasshopper, Maya, or other software, and that rekindled my interest in Python, Processing, and later C++.
Eh, I would have to check, but theoretically everything should be fit for 3d. Maybe the GHPython component that computes the routes doesn’t work in a three-dimensional context? Could you upload an example?
Yes, the particle system could for instance have a steps counter attribute that gets incremented each time that it gets updated (maybe it has already?). Each mover now should get a delay attribute that you can set randomly, when it is first created.
Then when updating the particle system, you can check for each mover, whether its delay is bigger than the particle systems general steps count, and only update it then.
This should do the trick!