László,
I will try to come up with some pictures for you. In the meantime here are some thoughts:
The requirements for stairs are perhaps the most difficult of any in the program. Some elements are defined primarily by graphic means (slabs, roofs, etc.) while others are defined almost entirely by specification (furniture, fixtures, etc.). The more an element requires definition both graphically and by specification the more difficult it becomes to create a simple interface for its manipulation. Add sophisticated modeling requirements and the complexity of the assembly (and sub-assemblies) and you have the real challenge of making a stair.
The new stair tool as I see it should include:
- Graphic adjustability should include: the length and width of each run of steps, the size and shape (polygonal) of landings, the radius and angle of curved stairs, and the floor to floor height for each stair assembly (in 3D & section).
- Specification of library parts for balustrades and treads at least, perhaps for structure as well. These would be assigned as multiple parts associated to the same assembly. New subtypes would be needed for these stair parts and new global variables for values such as rise & run of the current set of steps, nosing overhang, tread thickness, structural thickness, etc.
- A basic set of library parts for railings, newels, balusters, treads, etc. should be included along with the ability to modify them or create new parts.
- The ability to define/cut the floor penetration automatically including a material setting for the surfaces of the hole.
- Flexibility in the definition of the 2D symbol with line types, text font & content, plan cut height, etc. all user definable. A ceiling plan view would be nice if such a function (e.g. for creating proper ceiling plans) were to also be added (yes, this is a hint
). Inclusion of custom 2D GDL symbols would also be good if possible.
The form/function of the tool I see as follows:
- The stair would be defined by a 3D poly-line representing the center or walking line of the stair or the outside or inside edge (much like the reference line of the wall tool). This would be drawn in the same fashion as a 2D poly-line with the addition to the pet palette of defining whether an edge represents steps or a landing. It may be that each run of steps will necessarily be followed by a landing, but a landing could consist of several edges; so perhaps one would need only click the pet palette to start each new run of steps with landings following automatically.
- Once defined the width and shape of each run of steps and landing should be adjustable. This will undoubtedly be the truly difficult part. Graphically this calls for an element that behaves as a multi segment wall (if there were such a thing) that is also adjustable like a slab. It might be that the tool should be limited to simple straight runs of constant width at first with the more complex options left for future revisions.
- The vertical dimension should be defined initially as the overall (floor to floor) height for the complete assembly. This should default to the current story height with the option to adjust it later or set it in the info palette before drawing. Landing heights could then be individually adjusted afterward.
- Dimensional constraints and defaults should be defined in the settings dialog. Optional constraints for rise and run should be available but not required. The number of steps would be determined by the constraints or overridden by a fixed value from the user. The number of steps in each run would be distributed according to their relative lengths. If a fixed tread depth (run) is specified then each run of steps would be drawn in incremental lengths. Defining and managing these constraints is potentially the most complex part of the stair function and the biggest challenge for the design of the interface. This has the greatest potential for frustrating the user if the relations and effects of the constraints are not clear.
- Different base types of stairs should be predefined to make their creation easier. These would include, at least, straight run, L-shaped, U-shaped, curved and helical (aka spiral) stairs. These types would all be based on the same internal definition of a stair based on the 3D poly-line and constraints as described above in order to maintain the greatest flexibility and consistency for the future.
- It is essential that a clear environment with the necessary global variables and functions be created to permit the creation of custom stair components. It is not possible nor appropriate for Graphisoft to create all the various handrails, balusters, treads, nosings that may be used or imagined by all the Architects in the world.
In Conclusion
The initial release of a new stair tool should at least permit the quick and easy creation of basic stair types such as straight runs, L-shaped, and rectilinear U-shaped stairs. It should also allow flexibility in the choice of handrails and balustrades, including a basic (but realistic) set of standard parts included by Graphisoft, and allowing the creation of custom parts by both third parties and end users. It must also provide serviceable symbols in plan so that it is not necessary to model the stair on one layer and draw it on another as we do now.
While the new tool may be (and perhaps should be) fairly simple to start with, it should be developed with the full range of possible future developments in mind. In addition to the more advanced options for stairs I have described above, I believe it also should ultimately be able to include all manner of vertical conveyance including escalators, ramps, elevators, etc. As long as the tool is being redesigned it should be planned to be as complete and versatile for future development as possible.