I want to make a circular-like auditorium, where I control the angle of the seating and the depth from the first line as well as the number of sides of the polygonal basis.
My definition only works for 6 and 10 sides, any other number bugs.
I tried to fix it by resetting the section curve, but I still have the bug.
Some strange behaviors
I first open it in Rhino 6.0 and GH1.0 so no SWEEP 2 here on your file !!!
In Rhino 5 and GH 0.9 your components seems old. Update Rhino
2 way to cope with the problem
Scale the upper polygon instead of offset (Offset add control points. Offset loose open the cure)
Unfortunately some of the info (list Item , addition) is not loading properly on the Rhino 4 I use.
Could you send me a screenshot of the definition so I add the missing elements ?
What geometry? (the seats closed profile ? or the steady tread/variable step ?)
In general the inclination is derived from the tread length, the start step height and the variable (visibility clearance) value added to each next step. Step is variable in order to allow people to see things (otherwise why doing it?). In fact in real-life we calculate that clearance a bit differently … but this is not real-life anyway, he he.
Additionally and according the local Building Regulations there’s other restrictions related with similar arrangements … but that’s a bit complex to implement without extensive use of coding.
Note that steps are required in aisles (subject to Regulations as well) depending on some max step value.
Anyway: the def provided is just a very entry level (and primitive) indicative approach and by no means a complex and complete real-life C# design tool for seating arrangements in public places.
This is the real thing (IAAF, CIS standards etc etc):
Get half gift in order to prepare yourself for the full thingy. It does the planes for a classic Plane To Plane transformation (the job that the Orient component does). You can vary the deployment according a vacancy percentage and control how many seats are skipped at aisle axis (this is not pro approach mind, we never make aisles along these axis - but anyway).
But … there’s an “issue” here: these planes serve to place seats that are anchored in variable step heights … meaning that IF the tread is not OK for resting the human feets (+ seat Length + circulation space) … hmm + hmm.
As I said that’s C# and is 1M miles away from what a novice should/may expect.
Truth is that this part is doable with native GH components (but doing things with these is far more difficult for me than writing some lines of code) … but for the rest of the gift things are totally different (dealing with Instance Definitions and zero response times etc etc).
Er … that’s wrong. Because you place your seats in such a way that the feet rest at the previous row > but the step is variable > no no. So you need a regular seat (so to speak) that must being placed “back” in order to allow space for the feet in the same row (plus [optional] space for circulation - behind the seat, that is).
BTW: Change your plane size (they are a bit enormous)
OR … you need to do some maths: IF the max step is < 40 cm then you need a seat with variable mount height AND planes at a steady Z increment. That seriously restricts visibility for big N of rows … but any design is a compromise anyway. We do this in multi-layered stadiums/theaters etc because a very steep base seat deployment yields some even steeper deployment in the upper layer(s) and … some vertigo .
Added an ability for 2 sorts of planes: for seats (steady: the capacity) and people (variable: the vacancy). Plus the info panel informs you about the max step (in order to decide the type of seat as above).