Shouldn’t 3 objects, when ‘radially-arrayed’ be positioned at exactly 0-90-180 degrees (relative to the initial object’s angle towards the origin of course in case someone’s nitpicking is on overcharge)?
I think the logic is here that the angle is divided by 3, otherwise with full 360 degrees you would get duplicate objects at 0 and 360. I think in plain Rhino it works different, since the 360 case can handled with some extra code behind the scenes.
Workaround could be:
yeah, it makes sense, however Rhino works properly
I consider this either bug or major inconsistency that needs fixing ASAP.
At least a boolean needs to be added to the component in case, for whatever reason someone needs the current behavior. I certainly don’t.
it says “Polar Array of geometry” not “polar array of the space between the geometry copies” 
@ivelin.peychev after your request polar array component, without further code, would divide 360° by 4 giving 120°, resulting in
with 0° and 360° both receiving a geometry.
I am pretty sure you want the geometry on 0°, 90°, 180° and 270°.
Maybe unexpected, but the GH polar array is at least consistent by not putting geometry also at the end
Doing an _ArrayPolar in Rhino over 360° gives same result as Grasshopper Polar Array component, but not with any other fill angle.
If you ask me the _ArrayPolar command is the one being inconsistent…
My point is that with the GH polar array you have complete control yourself, and the node setup from @Gijs will get you the <>360° ArrayPolar behavior.
not the way I understand what the result should be you consider the number of objects not the number of spans between the objects.
Also 360 degrees is a special case that makes spans and objects the same number
If Rhino’s command is inconsistent also means the LinearArray is inconsistent as it should take spans into account not the number of objects and in the picture below one should see 6 items (5 spans) (5 copies)
