Polygonal closed curves - Sweep 2 failure

Hello,

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.

Can anyone help me with that?

auditorium-180113-2.gh (15.9 KB)

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

  1. Scale the upper polygon instead of offset (Offset add control points. Offset loose open the cure)
  2. Use loft with the 2 polylines
1 Like

Thanks, with loft the problem is solved.

I would strongly recommend a workflow as briefly outlined in the attached.

Arena_sectors_V1.gh (126.3 KB)

Thank you for the help Peter.

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 ?

Rhino 4? Hmm …

Screen Shot 089

Screen Shot 088

Screen Shot 087

BTW: If you manage the def to work I’ll make you a gift (just for fun it uses C# thus is not suitable for no other purpose at present time).

I mean going from here:

To there:

in a couple of milliseconds (~ 20 with an i7) no matter how many seats and human figures you want to place.

3 Likes

I’m working on it !

If you want to use offset then just simplify the result to remove the extra control points. Then it works fine.

Capture

Thanks for posting the printscreens, I added the missing elements, it’s now working.
Impressive job !

I want to control the inclination of the arena, and the number of rows.
Can you explain how you manage the geometry ?

I

thanx, simplify does the trick !

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):

I was referring to both the profile and the steady tread/variable step

I think i got it !

Arena_sectors_V1-PARAMETERS.gh (120.4 KB)

It is working perfectly, thank you so much for the help.

I want to place the seats but I don’t know how to join the exterior wires on each level. Any idea how I can solve this?

BTW, is your gift still on the table ?


Arena_sectors_V1-PARAMETERS-01.gh (124.3 KB)

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).

Arena_sectors_V1A.gh (141.3 KB)

After inserting again the Item and Add components I see that this is actually a1M miles away from what I can handle !

but here goes nothing …
I placed seats on the planes
I guess to show the occupied places I can run the script again with vacancy at x%


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).

Arena_sectors_V1B.gh (142.4 KB)

Since you are using Orient do not attempt to place big numbers of detailed human figures .

1 Like

Thank you so much for the help.
Your solution is very accurate and precise.

I keep it small and simple for now, basic seats and no human figures.