I think “Distribute Along Curve on Surface” would be my dream version of this tool. Being able to keep the objects aligned with a surface’s normal direction while controlling the space between objects would be ideal.
Until this is implemented in Rhino,
Armadillo plugin does exactly that, and much more, in case it would be an option for you.
Thanks for the tip! I’ve used ArrayCrvPLUS before, but never Armadillo. I was sad to see ArrayCrvPLUS disappear.
I understand that Armadillo does all that and more, I simply don’t have a need for all of the additional features in Armadillo.
It seems like all of the pieces are there in Rhino 6, they just need to be assembled in a new way to make them even more useful.
Hi Mike - seems like that may get a bit tricky for gaps - just off the top of my head - I don’t know how Jarek does it - but in a linear distribution, finding spaces between bounding box edges or centers is straightforward since they are all parallel, but on an arbitrary wiggly curve, are the bounding boxes aligned to the curve normals? If so where do you measure the gap? The closest points on a bounding box might or might not be very useful since adjacent ones will not be parallel. If you do not use bounding boxes, then it gets complicated too. etc.
Got an example?
Hi Pascal, yes, the spacing on irregular curves and shapes is tricky. I use oriented bounding boxes and also two methods of measuring: curve length or equidistant. It would be possible to do it very precisely independent on curve or distributed objects shapes, and with precision, but that would need some sort of iterative approach of “sliding” each next object from the previous object position and checking spacing at each step. Tricky, definitely
I see how the calculating the space between can get complicated. I’m sure this is also why the spacing breaks down even in Armadillo when you offset the objects above or below the curve.
Maybe this is a different way around the same problem I’m having. Would it be possible to add a base surface to FlowAlongCrv for orientation? Maybe it would be Flow Along Curve on Surface. I know that Armadillo can do this well, but I’d love to see it in native Rhino.
There are times when creating a base surface for FlowAlongSrf is insufficient, especially when the target surface has compound curvature. Here’s a simple example:
If I want to place a circle of gems (or whatever) on top of this surface I can use FlowOnCrv using the isocurve as a target, but the gems won’t be normal to the surface.
I could use FlowOnSrf, but I get very different results with different base surfaces:
UV Curves gets me a base surface that’s too long. the distances between objects will be very different on the base and target surfaces.
UnrollSrf fails because the surface is doubly curved.
Smash gets me a surface that is very close in dimension, but it’s not straight so I can’t lay out my gemstones with regular spacing on it. Hence, my original request for Distribute Along Curve.
If I can use Flow Along Curve and still make my objects align with the normals of some target surface, then I could fine tune the spacing between the flowed objects using the current Distribute command on the parent objects on the base curve.
Hi Mike - I believe in the example you give
FlowAlongSrf ought to do it, but you may need a rebuilt target surface to even out the spacing - is that what goes wrong? If so, Rebuild (DeleteInput=No) the target surface to a very dense point count like 16 by 64 (around) and use that, then delete it.
Although, in a test just now, it worked out perfectly on the basic revolved surface - maybe I need to re-read your post.
In your example, make a
PlanarSrf from the UV curves and use that as the base surface…
This is the exact problem that got me diving into this. Rebuilding makes little to no difference.
Here is what FlowAlongSrf does in this situation.
Both surfaces have been rebuilt to 64U and 16V. On the base surface I’ve got 20 gems with a gap of 0.20 mm between them. On the target surface, i’ve got 20 gems crashing together.
Flow Tests.3dm (2.9 MB)
As far as i can figure it out, it’s because UV curves gives me a rectangle that is approximately as long as the outer circumference of the surface. This is considerably longer than the curve that I want to flow onto.
I get closer with FlowAlongCrv, but again, I have to match the surface normals somehow. In this example, it’s pretty simple, but often I’m doing this on a more complex surface and there’s not one angle that works for all of the surface normals.
I’ve gotten further with ArrayAlongCrvOnSrf which is what made me think of adding a target base surface for FlowOnCrv.
Yeah, I see, you’re not filling the circle. If you make that base surface as long as the target curve, does that do it (Scale1D)
Actually, yes. That does make the spacing better.
I had never considered changing my base surface from the frame that UV Curves makes. I’m going to have to try this workflow out in some of my other projects to see if it works consistently.
I agree this would be a really great tool to have in V7 if possible.
Hi Mike - another thing to try here is
ArrayCrvOnSrf - it is not the easiest to use, OK, it is hard to use, but it may actually do what you want as well. You need to use the Multiple option (20) and specify the diameter of the object plus spacing (1.5 in this case)
I’ve worked with this one a bit too. On occasion it does a fantastic job. Unfortunately, I often need to array tapering gemstones and ArrayCrvOnSrf can’t handle that.
Ideally I’d like to have one very reliable, Rhino-only workflow for laying out different gem settings on convoluted surfaces. My biggest frustration with FlowAlongSrf was that it messes up the spacing so much, but now I’m thinking that there may be a better way to set up my base surfaces.
Hi Mike, I see the issue and have run into this many times on different types of surfaces as well. Good conversation as you need to show those students the right way. I assume GIA is not using Matrix any longer and you guys are using Rhino only. Different ballgame in some instances. In that simple example I would roll out polar array and call it a day.
Armadillo is a good deal, especially at the educational rate. I’d buy Armadillo and get on with it. In fact, I did.
Agree 100% - Rhino needs a robust editable ‘Array object on curve aligned to surface normal’ tool. Given that the vast majority of jewellery cad designers are using Rhino (or a ‘plugin’, Matrix, Rhinogold, etc) - this is sorely missing. I can get by using ArrayCrvPlus, however Matrix has had a fully-functional, editable solution for years now. As a die-hard vanilla Rhino user, that’s the biggest hole I can see for users like me, and is the single biggest thing missing in Rhino at the moment for the jewellery industry.
Stuller/Gemvision/Matrix is developing all these new features like Live Booleans (which are now becoming commonplace in 3d software) - McNeel needs to step up and make vanilla Rhino a viable option for jewellery cad designers.
Maybe that’s why they get the big bucks…? (Matrix is like 6x the cost of Rhino)
Oh, I know, I used to use it. It’s stupid expensive (£5,000 give or take) and a real PITA to use. Bogs you down with so much superfluous stuff.
may I add a +1 for the important need of us jewellers to have an array/distribute along curve tool with Srf normal alignment.
- Live Booleans exists also in Apps that are within Rhino’s cost range. It’s been available in Zbrush since a few years, a great system where you can adjust many booleans operations, unions and difference, while continuing work on the model until you like the results and then commit the Boolean.
Having it in Rhino where controlling scale and translations distance is easy and precise will be very nice.
But perhaps it is something more difficult to develop with Nurbs…
with best regards