Vectorworks, Inc Employee Popular Post PVA - Admin Posted September 14, 2018 Vectorworks, Inc Employee Popular Post Share Posted September 14, 2018 The point of this thread is to collect, collate and discuss needed improvements to the stair tool. For the purpose of this discussion, it should be assumed that all changes are possible, up to and including rebuilding the tool from scratch. However, we will leave the decision on how go about it to engineering, instead we will focus on what exists that needs improvement, what exists that does not work at all, and what the tool is not yet capable of that it needs to be in order to satisfy our architectural users specifically. Everything from the creation UI through the final resulting geometry is on the table and mutable. I will collect the items here, and if one or more spread into a more specific and complex discussion, I will split those off into their own threads as needed, but we can treat this overall as a single massive feature request which is not how we normally do wish list items. I, and I’m sure many here feel this issue is important enough to bend the normal forum rules at least for now. The below are in no particular order. Please try to avoid “We shouldn’t do X until we do Y” or “Don't listen to Bob, it should be done the way Charles said!” types of deadlocks, we will let the engineering managers handle implementation and scheduling. What we should focus on here is what is needed conceptually. Section and Clip Cube Appearance: (These issues have been identified and plans have been made to correct them, so we can leave this aspect out generally for the time being.) Length/Height Limitation: It is not possible to create a greater than 2-story or 3-”sided” stair. Users must stack multiple stair objects on top of one another. This is felt to be a regression since Custom Stair was capable of simply adding more platforms and flights to accommodate. Users need to be able to create a single stair objects that can span as many vertical stories as their building has. Railing Geometry: The generated railing geometry is very often incorrect. This is most easily seen on a default U configuration stair, the inner bends twist and warp in an unacceptable manner. Rectangular handrail profiles seem to suffer the worst in terms of bending and breaking randomly near corners, but even round profiles that manage the bends properly are faceted and not actually round which looks particularly bad in renders when using reflective textures. This is compounded by the fact that even when these railing objects are correct enough to be used, it is not possible to apply a directional (usually wood) texture to them as the mapping is warped and bent. Users are limited to solid colors or textures without any patterns at all. To go further on railing geometry, if users choose to disable the rails and handrails built into the Stair tool, they then turn to the Railing/Fence plugin object, which does not acknowledge or interact with the stair tool, making even manual clicking on each tread and platform location to draw out a railing impossible without excessive editing. This makes what would appear to be the most obvious workaround available even harder to work with and both of the above result in users creating extrude-along-path objects with their own custom rail profiles, which of course have to be configured manually each time the stairs core parameters are altered. Users should be able to add their own 2D symbol as the profile for handrail/guardrail/post geometry right in the Stair UI. We could never hope to preempt every possible configuration, so the ability to fully define it from scratch should be handed over to the user. Often, railings are mounted not to the stair itself but to the nearby walls. However, the current stair forces the user to pick one, regardless of whether walls are adjacent to each flight and platform. This is far from the most pressing issue, but the ability of stairs to detect adjacent walls and allow users to override railings on those sides is needed. A decision needs to be made: Will Stair objects contain their railings as part of the Stair plugin, will we offer a Handrail tool that is capable of linking to and intelligently adapting to a Stair object, or will we offer both for different scenarios? In-place edit-ability: Users want and need the ability to select and edit at least some parameters, if not all, while in the 3D drafting environment. Currently, all input must be done via dialog boxes or OIP fields. OIP fields would even be acceptable if it were possible to click or right click on a stringer, tread, platform, or railing of a stair and simply choose “Edit” and be taken right to the appropriate field in the appropriate palette or dialog. Visual Stair Creation: Designers are visual people. There is a reason they don't do data entry as their career. They understand what they can see and touch above many other ways of thinking and expressing ideas. Stairs all now have to start from a predefined simple template, when the opposite is often needed. A drawing mode that allows users to mouse click between the starts and stops of flights, modifier keys to insert platforms, winders or curves, or even multiple click creation where the user defines the depth and angle of each tread would be welcome improvements. The best example I could find of this UI was in Chief Architect where this is the default method of creating stairs. The current methods of adjusting portions of a Stair are limited to distances and angles and it isn't always clear where each value is in the dialog and what it controls unless you confirm the change and hop back out of the dialog which it time consuming, when this method of defining a stair would probably be the second or last choices of most designers. If we want to predefine many of these stair modes, they would best be stored as a Style resource instead, for stamping down standard stairs that only suit standard situations. Not forcing users to always start from these points. We want to encourage creativity and this does the opposite. Preview/Viewing Resulting Changes: It is very difficult to get an idea of how applied changes in the Stair Settings dialog box actually appear. Yes it’s possible to view the stairs in all of the standard views, and this is an improvements over older versions, but it needs to allow free rotation, pan and zoom via the cursor in the Settings dialog. Especially when attempting to correct railing detail issues, a perfect orthographic projection is often not helpful as it obscures the areas users need to focus on. Not only should there be more free view control in this dialog (or, perhaps the removal of the dialog entirely and have changes appear live in the drawing?) but the preview itself should be expandable all the way to full screen as it is in the Image Effects dialog. In either case, there is far too much need to bounce in and out of the Stair settings dialog repeatedly when making changes.Documentation: There are a number of very commonly needed construction drawings required as output for stair filing. Plan view with riser counts, top front and side views with full dimensions, section views, etc. These could be created automatically for users on a defined sheet from a button right on the stairs object info palette and linked so that if the user made updates to the stairs, these viewports would update themselves automatically, or at least allow the suer to update them when ready, but keep them linked so that a change to a single stair object didnt require a lot of manually editing its associated viewports as it does currently. Wrap-around Stairs: There is no clear provision for creating wrap around stairs as are commonly seen on decks, patios, porches and main entrances. These types of stairs are common enough that our default Stair tool should be capable of handling them. Custom Treads: A method of overriding any given tread, especially those at the top and bottom of a flight, needs to be included. Users need to be able to define the shape of a tread manually to allow for not only artistic customization but also to accommodate existing construction during renovation. This would also allow for the aesthetically pleasing gradually-flared bottom treads very commonly seen in high end construction. If a user needed to, they should be able to manually define the plan profile for each individual tread themselves. This would of course necessitate that they be able to disable all automatic limitations that force stairs to adhere to a code. The designer should have this freedom. Stair Types: The current possible configurations are U, O, L, Straight, and Circular. These do not allow for stairs with a continuously variable curve, flared stairs, or S-style stairs that require at a minimum two inner and outer radii. Users are currently forced to cobble together multiple separate stairs to accomplish this and this makes layer and level height changes significantly more time consuming. Texturing: It needs to be possible adjust the texture mapping on rails, posts, treads, platforms and stringers separately, not simply allow users to change which item gets which texture as can mostly be accomplished now with Class Attributes. This is a broader issue that also affects Windows, Doors and more complex Wall setups, but it bears listing. Underside ceilings: It needs to be possible to add a smoothed ceiling to the underside of stair objects. The geometry generated currently on the bottom of stairs is often very polygonal and mesh-looking, and users must manually add the intended flat ceilings to these areas, and manually update them if they change stair, layer or level heights. This is more important than ever now that we have interior panoramics exports and walkthrough/webviews that will have viewers staring right at this geometry as they walk around. 12 Quote Link to comment
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.