in the above example Distribute (in the Y axis) is giving an unexpected result. i.e. the second point (right to left) and third point are not distributed relative the the first and last points.
Distribute Points.3dm (3.2 MB)
Hello - the points are distributed correctly as far as I can see, there is no provision for sorting from left to right.
-Pascal
I am confused then. In the TOP view we can see the highlighted points which I think should be equally distributed from the first point on the left, that sets the lower y-axis extent of the range and the last point on the right (which is the highest point on the y axis) which sets the upper extent of the range. Every other point (between them) should then be equally distributed between the lower and upper extents, no?
Hi @pascal, I’d expect a Y distribute to move the points like this:
Purple is the new YDist.
Distribute Points 001.3dm (203.0 KB)
Regards
Jeremy
I think that is what the OP is looking for too.
Right, but as I say, Distribute does no sorting left to right before deciding on the limits. I’m not sure it should either - that is making an assumption that I am not sure is warranted in general…?
-Pascal
exactly… This was my point , most other 'drawing packages take the points on the outer limits of the range (admittedly this is usually 2D) as the point to calculate the spacing then walk through the points in a given direction to distribute them in order
if not you have to ensure every point is at least comparatively in the right place relative to the other points and then you are just nudging them up or down, left or right to be exactly equally spaced
I kind of think that it’s kind of random if you don’t make the assumption that the points are ordered in some way, and that ramdomness defeats any useful purpose (other than randomising!).
Look at it like you are doing the direction distribution (where you pick the two end points to get the direction) but only using the Y component. That would be useful.
Hi Jeremy - I don’t say it would not be useful to be able to do something else, but that is not what Distribute does - I can’t imagine in the general case where you have objects placed arbitrarily around 3d space that there would be any useful way to pick an order. 2d might be special, points might be special… but that (I say) is a different tool.
-Pascal
From the help: The Distribute command spreads objects out evenly between the end objects. Surely the general case in 3d space is just as much an anti-indicator for the existing functionality? But hopefully the user applies the tool with some degree of common sense.
Incidentally the direction mode, picking the two extreme points for the direction, doesn’t work either.
if nothing else a ‘constrained order’ parameter could allow for the user to input an orthogonal axis as the plane in which the ordering was decided. i.e. my points are distributed in the y-axis and the ordering is constrained along the x -axis
Sure but ‘end obects’ can only mean the max and min in the axis chosen, currently, since there is no other input - there’s nothing to tell Rhino how else to decide on the ends - why would it be left and right extremes? I understand what’s wanted in this case, just saying there needs to be a different tool with more inputs or assumptions made. Meantime, getting the desired order roughed in is the way.
-Pascal
maybe I am missing something fundamental (i.e. the underlying reason the command exists, in the first place and therefore how it is implemented - but I agree with Jeremy, I am basing my understanding on the doc’s), but anyway, if I am assuming I can only distribute in one axis (say y) and I have a ‘constrain order’ in the orthogonal axis (say x) the ‘end points’ are obviously the one’s with the highest and lowest values in the ‘order axis’. Everything that is in the middle is then in an ordered array based on the relative position to the ‘end points’. I.e. I order the points by sorting them against their position on the “Order axis”. I then adjust each point as an offset to one of the end points position based on what it takes to evenly distribute them…
Let’s just say that semantically ambiguous terms like “end objects” allow us to have very different interpretations (I accept that your interpretation fits with what Rhino’s distribute does, but to me it isn’t the obvious one).
I suspect that we are looking for a new tool which will “dress” objects along a line, in the way that a row of soldiers will dress their positions into perfect spacing on the parade ground.
hmm perhaps… I still think the notion of a ‘constrain order’ extension to the command that says ok, I know what axis distribute is working on i.e. the offset from a base (end) point for each subsequent point, now I use the order axis to at least figure out the end/order I apply the distribute offset to.
Without access to the source code it’s hard to know how far off I am with the pseudo code, but assuming all the points are variables with (x,y,x) coordinates, the distribute command (in this case) would simply be creating (in my example) the (x,y) field the points need to move/exit in, and then applying it to the selected range of points.
As for ‘dressing along a line’ I’d actually suggested this as further development of the ability to do basic point distribution 
Right, but there is no input for this. Without it, the only possibility is the extremes in the chosen axis. I think there could be more input, and it might make a fine tool but that’s not what this tool does - Now, you may say ‘fix it’, but I contend that there in another tool lurking here - I don’t see how some ordering assumption or input would not break what the tool does now, which is pretty straightforward.
@pharris65 Working in Right, would you expect the blue to become like red in the attached file, or like green, or something else?
DistributeQuestion.3dm (667.0 KB)
-Pascal
ok, I completely agree the “constrain order” is a new input … That’s been my point from the beginning.
As to whether this is a new function or an addition to an existing one (i.e. Distribute) my Software product managers are encouraged to use the ‘if it walks like a duck and quacks like a duck, it’s probably a duck’ rule of configuration sprawl 
I am not sure why an extra input breaks the simplicity of the function if it’s only an optional input??
As to the example, assuming you’re distributing on the z-axis, then the blue becomes the green (assuming the y-axis was the ‘ordering’ axis)
Right, I understand; my point is/was that the command is doing what is expected (Re: your topic), just not what you want - what you want is a different command. OK, maybe a more complicated version of the existing one, but off hand, not having thought too deeply, I think that would not be how I’d do it…
-Pascal
hmm
Maybe we can try and see where we agree. In general would you agree that the need to ‘distribute’ any group of things, is the use-case where we want some uniform arrangement of those things in relationship to each other, independent of anything else that might be around them? If so, then the usual, more traditional understanding of that term in any form of graphical design software is to think of the space between them, or the distance between the ‘things’ going from something non-uniform (unequal) to a uniform (equal) distance.
We previously agreed this is trivial in 2D space where it’s easy to define the ‘direction’ of uniformity in either vertical or horizontal planes. Why, well because if I have some array of things I can infer that the order they exist in the direction of distribution allowing me to figure out what that uniformity translates into (Omnigraffle, Illustrator, Coral, Powerpoint, Keyshot, Autocad to name but 6) all behave in this fashion.
In general if Rhino doesn’t have to worry too much about the ordering it get’s it right and behaves exactly the same as the listed software packages, unless for some reason the array isn’t positioning the ‘things’ in an already ordered (if not uniform) manner. i.e. Distribute does work as (I) expected, but not always.