Feature Description
bpy.ops.bim.add_array can only offset copies along a straight line (X/Y/Z). There is no way to array elements around a centre point.
Cases this blocks today:
- columns, bollards or seating arranged on a circular plan
- balusters around a curved or circular balcony
- fins, louvres and radial structural members on a curved façade
- spiral stairs and helical ramps — copies that rotate and climb
Proposal
Add a Radial array type alongside the existing linear one:
| Parameter |
Meaning |
| Angle |
the sweep — per copy, or as a total |
| Rise |
climb along the rotation axis — per copy, or as a total. Non-zero turns a flat ring into a helix |
| Axis |
X / Y / Z, or an arbitrary vector |
| Centre |
the pivot, measured from the arrayed object's origin so the array travels with its parent |
| Rotate copies |
whether copies turn to face along the sweep, or orbit while staying upright |
| Full circle |
closes the ring so no copy lands on top of the original |
Three requirements that aren't obvious
1. The sweep must be allowed past 360°. A spiral stair routinely wraps more than one turn — 22 treads at 30° is 630°, or 1.75 turns. Every existing subtype="ANGLE" property in Bonsai is hard-clamped to under a full turn (x_angle to ±180°, roof slope to 0–90°), so this has to be a deliberate exception rather than following the house convention.
2. Angle and rise need independent per-copy/total modes. A stair is normally known as one total and one per-copy quantity — the floor-to-floor height is fixed by the building while the tread angle is a design choice ("30° a tread, 3 m floor to floor"), or the reverse ("540° of sweep, 180 mm risers"). Tying both to a single Offset/Distribute switch makes the ordinary specification unstatable.
3. The derived value should be visible while editing. Whichever half of each pair is typed, the other is the one that needs checking — the riser height implied by a floor-to-floor total is what building code actually constrains, and it exists nowhere except as a computed number. Without it you have to build the array and measure it.
Acceptance
- 22 copies at 30° per copy about Z with a 180 mm rise per copy places copy 21 at a true 630° and 3.78 m above the original — not folded back to 270°
- 17 copies at 30° per copy with a total rise of 3.0 m reports the derived 188 mm riser in the UI
- existing linear arrays are unchanged: layers already written to
BBIM_Array place identically, and bpy.ops.bim.add_array() with no arguments behaves exactly as before
Feature Description
bpy.ops.bim.add_arraycan only offset copies along a straight line (X/Y/Z). There is no way to array elements around a centre point.Cases this blocks today:
Proposal
Add a Radial array type alongside the existing linear one:
Three requirements that aren't obvious
1. The sweep must be allowed past 360°. A spiral stair routinely wraps more than one turn — 22 treads at 30° is 630°, or 1.75 turns. Every existing
subtype="ANGLE"property in Bonsai is hard-clamped to under a full turn (x_angleto ±180°, roof slope to 0–90°), so this has to be a deliberate exception rather than following the house convention.2. Angle and rise need independent per-copy/total modes. A stair is normally known as one total and one per-copy quantity — the floor-to-floor height is fixed by the building while the tread angle is a design choice ("30° a tread, 3 m floor to floor"), or the reverse ("540° of sweep, 180 mm risers"). Tying both to a single Offset/Distribute switch makes the ordinary specification unstatable.
3. The derived value should be visible while editing. Whichever half of each pair is typed, the other is the one that needs checking — the riser height implied by a floor-to-floor total is what building code actually constrains, and it exists nowhere except as a computed number. Without it you have to build the array and measure it.
Acceptance
BBIM_Arrayplace identically, andbpy.ops.bim.add_array()with no arguments behaves exactly as before