I noticed this when I made a test with array on curve. I don't think it's a bug but some kind of behaviour I don't understand.

On the left, the array is made with "Flat" rotation mode. On the right it's done with "None". Can someone (Michael ?) explain why some elements are placed on the other side of the curve in "Flat" mode ?

Greetings

Hi Schbeurd, as you suspected this is not a bug but is a side effect of the "flat" style.

The "flat" style rotates the object around the world Z axis, but swings it around to point as much as possible in the tangent direction of the curve. The spots where you are seeing the switch over there are places where the curve tangent has passed to the "other side" of the world z axis direction.

The "flat" style is really intended to be used on curves that do not have any part in them that approaches the upwards/z-axis direction too closely. For curves that do not point too close to upwards, it lets the object rotate relative to the curve but stay stabilized in the upwards/z-axis direction.

See here: http://moi3d.com/forum/index.php?webtag=MOI&msg=263.10 for another discussion on it.

Here is another example - given this input:

Using freeform will generate a rotation around the curve that gradually twists around the curve tangent. This will produce only gradual changes from one object to the next, but is not "stabilized" with regard to any particular direction, so it is even possible on longer loopy curves for the object to eventually flip up-side down.

Freeform example:


Using flat will rotate the object around the world z axis, and try to point it as much as possible in the direction of the curve tangent. This essentially stabilizes the object with regard to the z-axis direction, but it behaves poorly when the curve tangent approaches the vertical/z-axis direction, rotations will become sort of wild in those points and the orientation at a point exactly along the z-axis is not well defined since the rotation axis and "stabilizing direction" are pointing in the same direction there.

Flat example:



"None" just copies the object to that point without rotating it in any fashion:

None example:


Please let me know if you need any additional explanation.

- Michael

Hi Michael,

The explanation is clear for me ! Thanks ! :-)

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.