I’m noticing a significant increase in calculation time when using the Solid Point Collide node in a Grasshopper Kangaroo 2 simulation in the latest (Downloaded May 7th) Rhino 7 WIP build compared to a previous version (Mid March - Early April). A 5 second kangaroo simulation calculation time has increased to over 3 minutes when the SPC Node is included.
Update. The difference is between WIP Build 7.0.20084.11445 to WIP Build 7.0.20126.10465
I didn’t know about this, thanks for letting me know. Nothing changed in the collisions code of Kangaroo between those versions, but some other function it uses must have. I’ll look into it.
Thanks! Did a bit more digging and installed WIP 7.0.20091.15085, which has 7 more days on the license before it expires. Opening the same script works fine. Just confirming it seems to be a change now between builds 91 and 126.
Hey Daniel, I installed the newest WIP build and noticed that the same issue persists. The SPC node running efficiently is really integral in my workflow. I’m wondering if you have any idea of the timeline on when this could be repaired? Really appreciate it!
Hi Colin,
I’ve tracked the cause of this to a change made outside Kangaroo in a Rhino mesh function.
Basically another user was finding that a check for points inside meshes (that Kangaroo also uses) was sometimes giving a wrong answer. The change in the Rhino function fixes this, but the extra checks it adds slow things down massively. For applications where people are checking only a handful of points once each this probably doesn’t matter, but as you found, it makes it pretty much unusable when you need to check thousands of points multiple times a second.
We’ll look for a way of bringing back the old behaviour, but in the meantime I think I can also provide an alternative scripted goal to replace it, so you don’t have to wait for the next Rhino WIP release.
I took this change as impetus to write a new point-mesh collider:
Solid_pt_newCollide.gh (44.0 KB)
(you’ll need to set the referenced assembly location of KangarooSolver.dll when you open it - usually this will be in
C:\Program Files\Rhino 6\Plug-ins\Grasshopper\Components
if you are on 6, or
C:\Program Files\Rhino WIP\Plug-ins\Grasshopper\Components
if you are using the WIP)
This scripted version uses a slightly different approach to before, so it doesn’t need the inside check that was causing problems. It seems from some rough testing that this new one is actually even faster than it was before the problems.
Hey Daniel,
That’s amazing. Only hitch is that I’m using the zombie solver to run 4 simulations and results as steps of a sequence. While there may be a way to consolidate that, is there any way you can advise on how to use the new SPC with the zombie solver? I tried both manual resets and using the data-dam to create an automatic toggle, but neither works.
Thanks in advance!
With a little more digging it looks like past the reset (as the node seems to work even if it’s not reset each time the simulation is re-run), the initial state of the simulation mesh relative to the exclusion mesh(es) matters. Is it possible, when starting with closed exclusion meshes, to maintain the ejection quality the old SPC node had?
Because I’m starting with some of my simulation mesh point inside of the solids I’m trying to have them crash with, the new node doesn’t make any change as it doesn’t try to expel them. The old node did this just fine because it could understand an inside versus outside of a closed volume and force all points outside of the closed volume(s).
I’ve added a new file with an adjusted initial mesh state and closed collision mesh to illustrate this issue, Ideally if it’s possible to have that situation work with a zombie solver (ie. no reset in the collision node itself) it would replace the old SPC node completely!
And yes, it’s looking so much faster than the old node when set up right on my end as well!
That’s an easy enough fix. It was assuming all points started outside the mesh.
Adding a check when initialising the goal to set this state makes it work if they start inside too.
The reset input isn’t essential and can be removed now. What was causing the issue was actually the floor goal (it doesn’t work with the zombie solver because the indexing works differently). So here’s a version with an updated version of the floor component so it does all work with the Zombie solver:
Solid_pt_newCollide_checkfirst.gh (76.3 KB)
One minor thing I’m noticing if you develop this further in the future is that sometimes it doesn’t collide properly when the strength (k) is too low, by default at 100, and when the strength is too high it causes the mesh points to behave erratically. This looks like their (in my simulation zero length goal) is being overwritten with different rest lengths. It’s possible to find a sweet spot where the solid body prevents crashes and the points stay in the right place, but this tends to be a floating number depending on the waiting of other constraints in the sim.
Thanks again for the new node. It’s lightning fast and working great!
Hmm, testing it more, it does seem occasionally some collisions can be missed this way (I think when the point passes exactly through a vertex or edge). Once this happens, the collision goal thinks that vertex is on the opposite side to where it actually is, and it gets messed up, pulling in the wrong direction. I’m guessing this is what you are seeing that looks like changing rest lengths.
I’ll see if there’s a way to avoid this, maybe by making a more accurate (but slower) check, only once every few iterations.
Solid_pt_newCollide_4.gh (55.6 KB)
Tracked down the issue - it wasn’t what I first thought.
The problem was that when a particle had crossed the mesh once since the previous iteration, and ended up inside, I was pulling it back to that crossing. However, that was introducing a spurious tangential component. Switching to always pulling to the closest point fixes this.
Hi @DanielPiker , do you think it will be fixed asap in a new rhino6 or 7 kangaroo update?
I experienced too the increased calculation time in the latest Rh6 releases.
Your new C# component is significatively faster than the official SPC and the behavior seems definitely better and, since I’m working on a simulation project in these next months, I would like to know it.
(Thank you for your effort to keep KG such a great tool.)
Hi Andrea,
Yes - I’ll make sure this fix goes into the next WIP release. Thanks for the reminder.
Hi @DanielPiker, did you already fixed it in Rhino WIP/Beta ?? Since it seems, compared to your C# SPC, still very slow and the results different. Any chance to get the fixed one also on Rhino 6?
Thx in advance.