The ScalePositions has been added to Rhino 6. Based on last week’s development team meeting, we need to figure out the best way to incorporate this feature into Rhino.
In some ways, it is like Scale, in others like the Solid options on several UDT commands.
Should this command remain a separate command, or get integrated into others?
How similar is it to the Distribute feature found in 2D drawing programs, or the Align command in Rhino?
I would say it is not similar enough to merge with these- at least I don’t see how to do it gracefully (I think DaleF has a Distribute item on his pile - we get that request pretty regularly - yep: http://mcneel.myjetbrains.com/youtrack/issue/RH-15100 ) ; on the other hand a ‘PositionsOnly’ option on the Scale commands seems perfectly reasonable to me.
-Pascal
But if you had distribute would you need ScalePositions at all? I can imagine a few rare cases, but moving one object and running distribute would cover the vast majority. Maybe that is a better route - and ditch this command completely?—
Brian Gillespie
Well- perhaps, but the Distribute idea would need more smarts- like Align it is a 1D operation so far. It might be that this could be done and it might end up making sense and being useful in Distribute, but I still say it is not the same thing.
For example, just in 2d - if you have a grid of objects - now you’d need to know where to move which object to get Distribute to give the same effect as scaling positions. That seems like more work and harder to grasp, to me…
-Pascal
Yeah, I see. I’m playing devils advocate here, because as we all know, Rhino is complex enough already.
What about adding History to Array?
The only use I’ve heard for the ScalePositions feature is to fix an array that is spaced incorrectly.
I use “ScalePositions” (my scripted version) to compress or expand space between diverse objects, most often for 3D printing. Of course, it does not check for resulting interferences when compressing, but in my case most of the time I manually adjust any interferences I find after.
–Mitch
Hi Brian, the problem I see in trying to shoehorn the functionality into Array/History or something is that it then becomes much more restricted in what it can do (only works when all objects are the same) and it requires planning - a constrained workflow, ugh - and, it is much harder to grasp, IMHO, as a process and therefore even less discoverable. Since we have Scale commands already, and users’ actual requests for this center on the idea of scaling, it seems to me adding a command line option is a compact and discoverable way to add this functionality in the least restrictive way. But that’s just what I think…
-Pascal
Ok, so then it seems to me that we only have two options:
The benefit of (1) is that we don’t add yet another command. The downside is that it requires another step - activating an option (or worse in the case of sticky options paying close attention to make sure the Scale command is doing what one expects - for small scale values, this may be visually imperceptible).
The benefits and downsides of (2) seem exactly the opposite of the above.
I’m not sure what the right answer is now.
I think option 1 is worth a try. The benefit of finding it easily inside Scale, where it fits pretty naturally in my opinion, seems worth the extra step to me.
-Pascal
OK - @dale can you prototype adding a “PositionsOnly” option to the Scale, Scale1D, and Scale2D commands?
Hi Brian, and @dale
I think it essential to:
1: make sure this is a non sticky option, scaling positions instead of geometry and vice versa is way too easy to miss.
2: make it possible to have a macro/alias to shortcut to position scaling. and make sure it gets it’s own place in the GUI. These type of feature additions are very valuable but buried inside an existing command, they are missed by the masses.
-Willem