This is a very simple implementation of a rotation input for the array modifier.
It has options for selecting the rotation mode and an option for using the rotation as the end point rotation,
so you can make it 360° and just increase the count and it will stay a full circle.
It also avoids a performance penalty like the one in T76102 that you usually get with an object offset.
Note it is different from using object offset as the rotation is always done around the object origin before translation.
That way you can have a linear array with differently rotated objects, or a circular array with not rotated objects (can be seen in the demo file and in some images in the comments).
How to use it?
The Rotation subpanel in the Array Modifier contains 3 properties.
- Rotation (in the mode choosen by 2.)
- Rotation Mode (exactly like in the object transform panel)
- Fill Angle (disabled for quaternions)
If Fill Angle is turned off, then the rotation is an offset between the elements. The next object is always rotated from the prior by the angle chosen.
If Fill Angle is turned on, then the chosen rotation is the end rotation (total rotation of the last element). This option will try to be smart about full rotations to avoid duplicates.
The rotation is applied around the origin of the duplicated object. That means that without translation (offset subanels disabled, no object offset) the object is always rotated around the object origin. If a translation offset is in place, it will always rotate the object around their new moved origin.
Here are some examples:
Using it with rotation only for circular arrays
Using it with translation and rotation (demo to grasp the concept)
The current UI looks like this:
Here is a demo file which shows a few things where this is useful:
Here is also a demo file where I played around with it for testing:
- Why could this not work with a duplicator system? Why the array modifier? Instancing is faster!
While it is true that instancing is faster and there are better ways to duplicate your geometry, a better duplicator system would not serve the niche of this modifier. For example rotational symmetric boolean cutouts or rotational symmetry with a continuous surface and subsurface following.
- Why is object offset not good enough? It is relativly fast to setup and addons can speed the process up.
There are multiple reasons why people (myself included) don't like using the object offset for circular arrays.
- A lot of setup. You need to parent additional emptys to the object. Usually one, but if you want a different rotation center even two. This only really works well/fast if you are at (0,0,0) and have no rotation and scale.
- Hard to control as you only choose the rotation of one step and you need to setup drivers to make it work with multiple instance counts. Also translation and rotation at the same time is really non intuitive. Also you need to go outside the array modifier to another object to change the rotation and then go back to change the count. A lot of people use an external calculator to get the offset angle (not everyone knows about the freedom in the value text input). This is really important as changing the count is something that is done quite frequently.
- Unnecessary clutter as there are more objects to name and manage visibility. There is always at least one more object needed per array. That can accumulate very fast. Especially if you have objects with multiple arrays for example to create easy icosaeder symmetry.
- Less performance if you move your object, as the modifier stack needs to be reevaluated due to the dependencies. (This can become really bad for either high poly objects, which shouldn't use array anyway, or just large modifier stacks)
- Further Discussion
One thing has been left out of the Manual part, and that is the bit about how it tries to be smart about avoiding duplicates. I would like to get a discussion going on that. Currently for Quaternion the fill angle option is completely disabled as it seems not very useful since you can never do a full rotation. Quaternion should really be used for motion trails or similar effects. For Euler Angle, Fill Angle makes the specified rotation the rotation of the last element. In the case that the rotation is a full rotation and the last element would be in the place of the first one, it acts as if there would be one more element. This results in the expected behaviour, where choosing a count of 8 and a angle of 360° will result in 8 equally spaced meshes. For Axis Angle, I decided to make that the default behaviour to avoid the jump when it hits 360°. Thats what made the gif animation at the top possible.
One could reduce the smartness if unwanted by introducing yet another option for "omit last", that would switch between the described behaviours.