2. Moving a Column should move all attached beams. (another obvious one and just imagine setting a simple grid first and then just moving the columns to correct positions.)
3. Define the fixed points of the column and let the other point be movable hotspots so resizing columns (after the engineering calculations) is fast.
4. Choose if the column shows and on which stories.
5. For each floor show the Mass center and rotation center defined by the placement of columns (this maybe useless to US colleagues but people working in Europe should watch out that those 2 points should be as close as possible. If we had a script language this would take me 10 minutes to write down. Its extremely simple but imagine giving your civil engineer a plan and when he gives it back to you with columns resized to have columns much larger than expected.)
6. Beams with other than rectangular profile.
7. Sloped beams. ( Just simple have graphical hotspots an enable to move the beam or make it tapered)
8. Beams are not always linear. Using arcs is absolutely necessary.
9. A general move enchament proposal: Except obvious logical connections (i.e a beam that intersects another beam is “Connected to it” or a beam attached to a column is connected to it ) we may define wall-beam connections ,that is a beam over a wall, and when moving (define that move with another name.. e.g RelationalMove,) the beam the connected beams walls columns move accordingly. Algorithmically is simple. All intersected elements extend so that they can follow, all attached elements (attachment happens at points) follow the movement of attached point, and the analogous happens with walls. A great time saver.
10. Hmmmmm stuck on the tenth
Any help
oreopoulos wrote:This would be nice but complex assemblies (as in classical orders) would be more useful to me (see item 10 below).
1. Free Form Columns (that is obvious of course)
2. Moving a Column should move all attached beams. (another obvious one and just imagine setting a simple grid first and then just moving the columns to correct positions.)Similar to your wall request. Of course, this should also be optional; that is whether elements are attached or not. I haven't tested to see if this already works for intersections when the elements are selected as it does for walls.
3. Define the fixed points of the column and let the other point be movable hotspots so resizing columns (after the engineering calculations) is fast.Even having stretchy columns would be nice. This sounds like a nice expansion beyond that.
4. Choose if the column shows and on which stories.Multi-story is essential. This is something that should be consistent for all model elements.
5. For each floor show the Mass center and rotation center defined by the placement of columns (this maybe useless to US colleagues but people working in Europe should watch out that those 2 points should be as close as possible. If we had a script language this would take me 10 minutes to write down. Its extremely simple but imagine giving your civil engineer a plan and when he gives it back to you with columns resized to have columns much larger than expected.)You're right, I haven't run into this in US practice.
6. Beams with other than rectangular profile.Clearly, essential.
7. Sloped beams. ( Just simple have graphical hotspots an enable to move the beam or make it tapered)Also highly desirable. I'm not sure what this would do to the complexity of the interface.
8. Beams are not always linear. Using arcs is absolutely necessary.This would also be good though the need is uncommon enough here that I don't mind faking it with curved walls.
9. A general move enchament proposal: Except obvious logical connections (i.e a beam that intersects another beam is “Connected to it” or a beam attached to a column is connected to it ) we may define wall-beam connections ,that is a beam over a wall, and when moving (define that move with another name.. e.g RelationalMove,) the beam the connected beams walls columns move accordingly. Algorithmically is simple. All intersected elements extend so that they can follow, all attached elements (attachment happens at points) follow the movement of attached point, and the analogous happens with walls. A great time saver.The relational issues can get very complex. I haven't seen how Revit handles it lately, but It seemed quite limiting in the early releases. This is a HUGE strategic issue which deserves careful long term planning. It seems that if we start cobbling together various relationships ad hoc, we would probably have an unruly mess.
Nevertheless, being
10. Hmmmmm stuck on the tenthThat's easy. Columns and beams should be definable as complex assemblies (by applying GDL macros probably). For example: A beam could be a complete entablature including the architrave and frieze (perhaps even the cornice) with metopes, mouldings, etc. A column should be able to include a plinth, base, shaft (fluted or not) and capital (with acanthus leaves for corinthian, volutes for ionic, etc.). And, of course, it would be nice to be able to do basic steel sections with gussets, angles and welds.
Of course, with this one, the curved beam becomes essential for constructing rotundas. Wouldn't it be nice if ArchiCAD could
This is really just part of my big picture wish to merge the GDL capabilities into all the element types. Perhaps I should resuscitate or restart that one. It's one of my favorites.
Still looking?
