Hi Michael,

I've found out some strangeness and an inconvenient feature of the array command.

1)
The Array-Curve command creates the right number of items along the close curve (free-form or polyline), but the objects aren't placed evenly - the first object cover the last one. It only happens when I type the "item count". For typing "distance", there is the identical number of the actual objects and the computed item count.

---

2)
The Array-Circular command seems not to be well-behaved for vertical or radial step options. Have a look at the next pictures... ( array_circular.3dm)

This is ok....




...it isn't...



It is the same for the radial step option.

---

How do you feel about it, Michael?

Petr

Hi Petr - thanks for testing the array commands!

> 1) object duplicated on Array curve on closed curve

This is a bug, it's fixed for the next beta, thanks!


> 2) Vertical or radial step with 360 degrees

This one I actually set up this way purposely. Here is the reasoning - forget about vertical and radial step for a moment - just doing a basic 90 degree array, you get this result, which I think is expected:



Notice that there is an item at 0 degrees and at 90 degrees. It behaves this way for all angles, with the exception of 360 degrees, since that would result in a duplicated object. For 360 degrees it changes the spacing so that there won't be a duplicate object at 0 and 360.

So the special case is done here to avoid the duplicated object.

Now, once you add any vertical or radial step, there will no longer be an exactly duplicated object at 0 and 360 degrees, since the one at 360 degrees will be moved by the stepping action. So since there is no duplicated object, the "avoid duplicate" special case for 360 degrees will not be applied in this case, the special case is only applied for 360 degrees with no stepping.

That's what my reasoning was... But I can see how it could be confusing that adding any stepping changes the spacing... Maybe it is better to make 360 degrees always use the same spacing regardless of the spacing like you were expecting. What do you think?

- Michael

Hi Michael,

>Maybe it is better to make 360 degrees always use the
>same spacing regardless of the spacing like you were expecting.
>What do you think?


I was doing another test of array with touching objects like this and was thinking it out..

Currently, when I want to cover the 360 degrees with a steps (height=8, segment=60°) I type "6;300;8;0". If however I want the subsequent piece at 360°, I can type "7;360;8;0".
If you altered the current array behaviour with vertical and radial step options according to my expectation, I would type "6;360;8;0" for covering 360 degrees. But what extra piece at 360°? Would I have to type "7;420;8;0"? It would be even more confusing...

Besides, I thought about adding the "Step angle: Iterate angle" field to array-circular command. I mean you could type Item count along with Step angle while Angle to fill would be ignored. It would be clear, then - 6 times 60 is 360.

Petr

Hi,

A comment on the images posted by Tyglik (images 3 and 4 in msg 273.4).
For array on open curves, I personally expect the first object to be placed at the beginning of the curve and the last object at the end of the curve (exactly how it currently works). Same for circular array with (for example) a vertical step. If I choose a vertical step of 1 and an angle of 360, I expect the last object to be just above the first one...
So I hope that if there are changes in the current implementation, this kind of behaviour will remain at least as an option...

BTW, I would prefer a default "angle to fill" of 360° instead of 3600.... ;-)

Cya

Petr wrote:
> If you altered the current array behaviour with vertical and radial step
> options according to my expectation, I would type "6;360;8;0" for covering
> 360 degrees. But what extra piece at 360°? Would I have to type "7;420;8;0"?
> It would be even more confusing...

Yeah, with the current way it is easier to add one item to get the spacing you wanted. I think you're correct that having to extend the angle in order to get another copy at 360 degrees is worse.

So that means that I will leave it the current way for this - only 360 degrees with no stepping will have the special case spacing.


> Besides, I thought about adding the "Step angle: Iterate angle" field to
> array-circular command. I mean you could type Item count along with Step
> angle while Angle to fill would be ignored. It would be clear, then - 6 times 60 is 360.

I kind of try to avoid this type of thing where there are similar fields, where one is ignored if another is filled... I was just thinking that maybe I could put in a toggle switch on the "Angle to fill:" label, so that when you clicked it you could flip it to "Step angle:" instead. I'm talking about the same type of toggle (with a little cycle arrow) that the Circle/Center command has when you are picking the radius - you can click on Radius there to switch it to picking the diameter instead.

- Michael

Schbeurd wrote:
> So I hope that if there are changes in the current implementation, this
> kind of behaviour will remain at least as an option...

If I understood him correctly, I think that Petr's later analysis was a vote for keeping it the way it currently is.

> BTW, I would prefer a default "angle to fill" of 360° instead of 3600.... ;-)

:) This was another bug that is fixed for the next beta. It was a problem with converting some text of "360.0" into 3600 if your locale has certain characteristics. You Europeans with your commas and decimal points all reversed are always causing problems!! :) :) :)

- Michael

>> :) This was another bug that is fixed for the next beta. It was a problem with converting some text of "360.0" into 3600 if your locale has certain characteristics. You Europeans with your commas and decimal points all reversed are always causing problems!! :) :) :)


We do our best to keep you busy ! ;-))
Thanks for fixing it !

Hi Michael,

>I kind of try to avoid this type of thing where
>there are similar fields, where one is ignored
>if another is filled...

However in the Array-Curve command prompt there are two fields - Item count and Distance - and an applicable is underlined.
So you can choose either that kind of behaviour or this how you mentioned. Anyway I think it would be useful feature.

>If I understood him correctly, I think that Petr's later
>analysis was a vote for keeping it the way it currently is.

Definitely!

>You Europeans with your commas and decimal points all reversed
>are always causing problems!! :) :) :)

hehe....

Petr

> However in the Array-Curve command prompt there are two fields - Item
> count and Distance - and an applicable is underlined.

I thought you might mention that! :)

The problem is not quite as bad in that case since there are only two fields for the entire command. When there are more fields, this type of implicit toggle becomes more awkward.

It shouldn't be hard to do the toggle switch, I will give that a try.

- Michael

I've got the toggle switch working now for the next beta, so that will let you switch between "Angle to Fill" / "Angle step" methods for the angle field.

There is still quite a bit of other stuff to do before the next beta is ready though.

- Michael

On other quick note on your helix example - another way to extract an edge is to select it and do a control+drag on it which will drag off a copy of it.