I get to a point where I would like to “project” weights associated to a series of curves to a fine mesh (I will explain later the reasons, by now it’s sufficient to know that these curves have been manipulated with other tools not obtainable just with weight on mesh methods). I ended up with a method which uses Weight on Mesh from Curve, but revealed to be rather slow and the calculation time is more like exponential with the input quantities (curves/vertices), while I need to build some robustness for very large meshes and very high number of curves.
I don’t know which workaround could speed up times, by now I’ve tried to work around it by using Weight on Mesh from Points, it actually looks quite faster but it’s just missing the vertex/weight association so the isolines get all messed up.
I made a debug display which shows the input vertex/weight association is correct (same weight all vertices belonging to the initial curve, all curves increase from 0 weight (bottom) to 1 (top)
Whatever radius parameter I set, many vertices remain with weight unassociated. Be careful because in this case, if little or no weight smoothing is performed while the values are missing, too many iso values are generated and the splitting lines become so many that the procedure will require 20 to 40minutes or total hang up.
I would also like to understand why the component Mesh Iso Splitting to Lines is indicating partial results because of missing license, since I’m not using the “Ext” version (and which is the part of the results which should be missing?)
This one is not so useful for this kind of job and I didn’t describe it well enough. For one weighed point it will just take one mesh point (the closest if at a distance less than radius). This tool was intended to be used for the “Smooth Weights on Mesh”.
It is also very badly optimized because it is used by another tools that uses parallel calculation.
At the moment I don’t really know what could be best. Perhaps points cloud could be useful or RTree (many examples of uses on forum) or something with Fields. I didn’t do something like that as weight usually comes from a calculation on mesh.
My bad, I forgot to remove a message and nobody told me that before you! It will be corrected in next release.
This is at least reassuring that it was not missing anything, I was just pushing the boundaries
Since I needend strictly one association for each mesh vertex, I ended up using Point Cloud Closest Point. It is quite efficient considering that it is looking, for each mesh vertex, the closest point in another cloud which comes from the flattening of a collection of curves subdivided at constant length.
The delicate part is to make sure that this subdivision is fine enough so that the actual closest curve is selected. To do that, the subdivision length is estimated using the minimum curve/curve distance (Wombat)
As a side note, since you talked about next updates, is that the Mesh Iso Splitting to Lines seems having difficulty in tracing the last contour ( Iso value 1 in my procedures), on the boundary. I checked and also forcefully set the weights to 1 on the boundaries, their value is also fixed, but trying to obtain that last contour always yields an empty result. No problems with the 0 value, which is on the other boundary.
To work around that, I set the border’s W to something like 1.001, and then I ask for the 1 value. In this way I always get a contour very close, but not exactly, on the boundary
In the following example you will see the problem replicated and the “1.001 trick” used, as with the search procedure used. You can connect the highlighted alternative weight list to replicate what happens when assigning weight = 1 and requesting for it as an iso value
The other solution could be to limit distance when putting weights on vertices, then keep trace of the indices then smoothing weights with fixed weight for all vertices that have a “good” weight.
