Hi @maje90
To try and address some of the points specific to Kangaroo-
I have been looking a bit at the AleaGPU library which could potentially allow me to use the GPU for parts of the Kangaroo solver. It probably involves rewriting quite a lot of code though - it’s not just a question of importing the library and flipping a switch.
I want to make sure that any changes I make still keep the modular nature and allow the creation of custom goals using C# and Python. As fun as it is to make flashy particle animations (where the solver only has to do one specific and limited thing fast and draw it to screen), Kangaroo is primarily intended as a useful and flexible tool for designing a wide range of things to be physically made.
Most of the solver’s time is spent in the Calculate method of the goals. Kangaroo is structured so that these goal calculations are all independent of each other, and they are called in parallel (just using the Task parallel library for CPU processing though, which gives only a very modest speedup).
Some of them are essentially doing a few simple pure vector math operations, but some have more general .net code, including calls to various RhinoCommon functions, so couldn’t easily be rewritten in a way suitable for GPU.
I think potentially it might be possible as a start to make a few specific goals that use the GPU - probably one for large collections of edge lengths, and one for sphere collisions.
One other reason Kangaroo gets slow for collisons involving thousands of particles is the broad-phase collision detection. When you have n particles, each of which might be colliding with any of the others, what you definitely want to avoid is doing the full pairwise collision calculation for all possible pairings.
So typically you divide or sort them in some way that you can quickly rule out a large proportion of these pairings, and then do the full collision check only for these. Kangaroo does use a simple broad phase algorithm in the SphereCollide and Collider goals, but this part definitely could be improved.
Getting it fast enough to run big realtime 3d fluid simulations is unlikely and not a priority, but I would like to at least make it easier to do things like fabric draping at a reasonable interactive speed for big meshes.
Here’s a Kangaroo demo that runs fairly smoothly with 10k particles (it’s a 1-to-many interaction rather than many-to-many, but I think shows that collision is probably the main issue)
As for the remeshing-
See my other reply here. I actually found and fixed a Plankton bug recently. I need to go through and make sure everything it affects is updated, but I’m fairly positive that the remesher can be made much more stable. It’s code I wrote a long time ago though, and whenever I look at it I get the urge to rewrite it completely from scratch to structure it in a more logical way. There’s still a lot I want to do with remeshing, making it more modular and customisable, better integration with Kangaroo, different relaxation options and more. This is something that I need to set aside a decent block of time to concentrate on though, and so far other priorities keep getting in the way.
About speed of remeshing - this is a fair bit harder to parallelize than particle physics, because although many topological updates to different parts of the mesh can be applied at each iteration, they are not independent - you don’t want 2 nearby edge operations trying to apply conflicting updates to the same neighbourhood, and with the mesh constantly changing there’s no easy way to split it into independent parts that can be updated in parallel.
Just calculating and caching all the edge lengths first would be easy to put in a parallel method, and I can try at least this for probably a modest speedup. The other heavy bit is probably the projection to the closest point on the target surface/mesh.