Hi Peter,
As I already explained to you when you showed me this before - youâre only seeing dramatic speed differences by comparing it to using Mesh Cage Morph in the wrong way.
When using it correctly, even the not particularly optimised version of what I first posted back in 2018 is comparable in performance what youâve shared here - differences on the order of a few milliseconds, not orders of magnitude like youâre claiming. The new version in the WIP is faster (and works with multiple geometry types, and when the inputs use data trees, but more on that later).
To clarify what is going on - at some point after sharing the original MCM component, someone asked about a version that would also work on Breps.
When applying any sort of morph to NURBS geometry which can include trimmed faces, it gets more complicated than simply morphing each individual control point as we can for simple types like meshes, because if we did this, the trimmed parts would no longer match up along the seams and the Brep breaks.
Deformations in Rhino (such as Twist, Bend etc) make use of something called âUniversal Deformation Technologyâ (UDT), which performs an iterative fitting process as part of the deformation, adding new control points when needed.
So the version MCM2 I shared later was making use of this UDT, to allow it to work on Breps. However, this process is relatively costly, and because the control point can change during the process, the weightings cannot be cached. Therefore this version is not suitable for use with very large meshes, where the original version is orders of magnitude faster (for simple geometry with hundreds of control points, it doesnât matter as performance is unlikely to be an issue here).
You also need to make sure you are using the W input for âCalculate Weightingsâ correctly when looking at speed. When either the thing being morphed or the reference cage changes, weightings need to be recalculated. When applying the deformation with a different or changing target cage, the already calculated weightings can be reused, so W should be set to false. It makes sense to use a button input here rather than a toggle, to avoid accidentally leaving it on and recalculating when not needed.
In the Rhino WIP there is now a component included in Grasshopper which switches between these 2 approaches, so it will use the faster method with caching for types such as Meshes, Subds and PointClouds, while also working with Breps (which will always be slower than for meshes, but now with an adjustable tolerance for the fitting, which can make it faster than before). It also works when the input is a list or tree of items, which required a slightly different approach to the caching.
This has actually in been in for a while, but weâll be making a proper post about it soon.
Thereâs also an experimental component in there, dedicated to morphing only meshes when performance is important, using multithreaded C++.
)