Plan C: Make flat meshes per Vor cell (that’s a bit tricky, mind: avoid Delauney on random points) and use K2 to relax the mesh in the exact way that we do in tensile mebranes (using forceA for naked edges and forceB for clothed ones + some gravity).
For sure PlanC is the ideal solution … but if you play with “bend” values … PlanB is not that bad
BTW: In case that you try a nurbs compromised solution and if you use Polyline Centroid … then IF the “connecting” curves are bezier spans and the end tangent is horizontal [some recursion could attempt to do the “ideal” other tangent] … then the surf combo could (?) look “smoother” (?).
But if I was you I would forget the Vor topology and use 4/3 pts (normalized or random) surfaces and then “inflate” them in a couple of milliseconds. That’s a very clean and very fast solution mind (shown a random inflation depth and random elimination result by projecting flat stuff in some revolved target surface) :
Thank you! Unfortunately, I’m having trouble getting Dendro to recognize the dendroAPI.dll file. I want to experiment with this plugin though. I would like to try and mimic OMA’s sponge wall from the Prada Beverly Hills store.
The rendered images you posted of this too look amazing.
When I type the command ‘Grasshopperdevelopersettings’ a window pops up with a blank libraries folder box and a check box labeled ‘memory load *.gha assemblies using COFF byte arrays’. I assume this is the COFF check box?
It’s true this approach relies on using spheres of the same size (otherwise you’d need to calculate a weighted Voronoi diagram). The size of the Voronoi cells doesn’t need to be linked to sphere radius though - that’s just a result of how his points are distributed.
Talking of distribution, a suggestion for one way of getting a nicer distribution here would be to apply a few iterations of Lloyd’s algorithm (repeatedly moving the Voronoi points to their cell centroids). Making the cells more centroidal means their boundaries will be at more equal heights:
very nice spherical solution. it would be way better (computing wise) to first filter out the curves by a simple ie. curve end point distance from a plane sort filter. this way you will have half the intersections to calculate and no area calculations needed later. In complex definitions avoiding areas and intersections that are not needed in the beginning, can make a real difference, especially as the geometry data adds up.
in this definition (scalop.gh) you may earn half the power, roughly from 3.1 down to 2.3 sec, which is not bad at all. in the case of scallopsizes.gh, it drops from 30 to 7 seconds, giving a real advantage.
i recreated it with end points because had not saved them at all. first version was with evaluate curve to find the middle of each curve, which may be a tad slower, or not. the logic is just to find a point to compare against it’s projected one anyway.
the reason scallopsizes_distance.gh gains 23 seconds is because the last, intersection / splitting part is the most resource intensive, so numbers of intersections goes up, times goes down.
in general, try to avoid calculations, especially geometry ones. the basic problem of grasshopper is that in every almost step it creates geometries, so it is very resource intensive, as opposed to non graphical programming. that what is being said at least, i am no expert.
furthermore, it does not use the outputs very interactively, which is another talk, for GH2.
edit: correct definitions. check what time gains we have, things can slip.