Chad Hamilton HAArchs

Pat, you are right - so many ways to get things done!

In order to calculate the occupant load from the data in the Space Object, create a Space report. Figure out which VW fields or user fields you are going to use to enter the room function and occupant load factor - International Building Code calls it Function of Space and Occupant Load Factor (Table 1004.1.2) Enter the proper occupant load factor - VW is entering this data as a text string, so you need to convert it to a number using the Value function in the worksheet. In the database header, create a function something like Number of Occupants = ('Space'.'Area')/Value(Occupant_Load_Factor). Insert the cell number or field name with the occupant load factor. Then in the next column, use the rounding up formula = IF (A-Int(A)>(A+0.01),Int(A)+1,Int(A)) to round up the value of Number of Occupants the next higher integer. See the example file below. In your report, hide the Number of Occupants column, with the fractional number of occupants, and show the rounded-up column. Space_Label.vwx

You're looking for something like the CEILING function in Excel - I don't think this exists in VW, but the logical equivalent using available functions would be to compare the orginal number to it's integer (VW integer function rounds down to the nearest integer) - if the original number minus the integer is greater than the original number, then add 1 to the integer. The worksheet formula would be = IF (A-Int(A)>A,Int(A)+1,Int(A)) where A is the original number you want to round up to the nearest integer. Depending on your judgment, you could also use = IF (A-Int(A)>(A+0.01),Int(A)+1,Int(A)) where 0.01 added to A would eliminate adding one whole occupant where the fractional number was very small.

There is another option that might make more sense. Looking at your model, there must be a floor or landing at the top of the stair, on the opposite side of the wall. Create a second layer, call it Upper Level or something. Set the wall height of the lower floor (the one you've been drawing on) to reach to the layer above. Copy the wall from that layer, and paste it on the upper level layer, then adjust the wall height to whatever you need. Set your door to the upper level. The joint between the upper and lower level should read as seamless - you should be able to set it so it is. This would be a more correct solution than trying to work around with a casement.

You bet - post again if you need help.

Not a stupid question - what you've found is a limitation in VW. Doors are 'glued' to the bottom of the wall - raising the door, like with command-option-M, moves the entire wall up, and setting door height simply lowers the top of the door relative to the floor. For a work around, try using the window tool, set to Casement. Under Settings, go to Jamb & Sash - set Sash Width to some very small number, like 0.01 inches, and set glass thickness to 1.75 (or 1.375, depending on door thickness). Under Classes, set Glazing to something other than Glass-Clear - define a class texture that matches whatever texture your doors use.

A variation on this theme - understand how the old employee puts the drawing together, then write a description of they way they do it as a mini office drawing manual. Create some in-house templates and drawing resource files based on other drawings. that would help the office work more efficiently. With your recent training, or by cribbing from VW training information, self-critique the way the office is doing drawings and come up with three ways the work could be done more efficiently. Then present the whole package to your boss.

Really? I thought everyone who managed projects knew the MS Project interface. We use Smartsheet, which is a cloud subscription that looks and feels very much like Project, but costs less. If the managers don't know basic programs like Excel and Project, maybe it's time to find new managers ;-)

Personally (and all these work preferences really are personal) - I prefer having fewer tools to remember thinking about, and have the related options in each tool. For me this is a more powerful workflow. Speaking about move/copy tool - I rarely use it - I normally use CMD-D (duplicate) with VW preferences set to duplicate in place, then CMD-M and enter dimensions for a precise move.

Sorry, but this sounds like a bad idea - normally we read drawings from more general to more specific, so details are keyed on more general drawings and are given drawing and sheet numbers letting us know where to find the detail. It's possible, even likely, that a detail will apply at many locations in a set of drawings - a window sill detail, for example. Trying to key a detail back to where it applies would often result in a number of back keys being necessary. Providing a reference back to a location earlier in the drawings probably doubles the coordination work in keying the details, without providing any important benefit.

We tend to use parametric objects whenever possible. As the design is refined from schematic stage through construction documents, it is so much easier to make changes parametrically than to adjust (or possibly re-model) a modeled object. Sometimes we add custom modeled elements to parametric objects - for example, a modeled sunshade in front of parametric windows or curtain wall. Sometimes we turn stair railings off in elevation views and draw them in 2D rather than modeling very complex elements.

That's a really good idea - do you know which is more memory / rendering time intensive? To date, we've only used texture map with no bump map.

The way to hide a column but not delete it is to set the column width to 0 or some other very small number, which effectively hides the column. This is a "hack", but works fine. Once you're working at the "worksheet on drawing' level, this is reasonable and won't create problems down the road as different items are reported in the schedule/worksheet. You need to document this in your office standards, so people will know what's going on when they are trying to read or edit info in this column and it's not appearing. One way is to format "Schedule" (as in for the drawing presentation) and "Editing" versions of standard schedules, and keep these in your Office Standard resource folder.

Pat has provided the correct answer - the short answer is that you can add database headers to any worksheet, and any new database header row can report bizarrely different information, if that's what you want. I'm guessing that's not what you want. I assume you want to report related information that is separated into different record formats for some reason. My best example is Cabinet Schedule - using the Report menu, set up a report for Base Cabinets - you can select the fields you want to show up in your schedule from the dialog. But you probably want to report upper cabinets and wall cabinets in the same schedule. One way would be to set up a new , separate report, and post the reports (schedules) near each other on the drawing. A better way would be to set up a new database header in your original Base Cabinet Schedule, using criteria that will find, for example, Upper Cabinets. This will give you a way to report whatever makes sense to you in a single Worksheet / Schedule. You could put Doors and Windows into a single schedule as Pat suggested - the worksheet format is very flexible in allowing different reporting in each database header.

That can happen if you have many (or all) cells selected and you change a column width or row height - otherwise, I don't understand how that is happening. Can you explain more what the condition is right before you make a change, and the change you are making?

For a similar problem, we used a roof face as the ceiling, set to the correct slope and 1-1/2 inches thick, and used the grid tool with a class to only show on 2d reflected ceiling plans. We used a gridded surface texture on the ceiling/roof plane for rendered views.

I currently use a late-2015 iMac - it is 27 inch, with a 4 Ghz i7, 16 Gb of ram, and a Radeon R9 M395 graphics card with 2 GB of ram - this configuration is wonderful with VW 2017. This processor is probably comparable or somewhat faster than what is available on the new 21 inch models, and the graphics processor is faster than the new models, but I am extremely happy with the performance on the iMac. I've thought that the difference in cost between the higher and mid-level models pays for itself in longer useful life, but that's just me.

Not sure exactly how the user defined fields were already populated, unless you brought in an object with records from your earlier project. It seems like you could either - 1. Select the space object(s) and clear the user defined fields in the OIP. 2. Possibly more useful, define a record format with all the extra fields you need, named appropriately so users know what to expect, and attach the record format to each space object you place in the file.

I can’t stress enough the importance of annotations to a BIM program, especially the ability to use keynotes in a drawing. Drawing objects are only one-half of the architect’s design documents – notes and annotations are the other half. A drawn object is meaningless in any set of design documents without an annotation that identifies what the drawn object represents, in the form of a legend, note, keynote, or some other written description. Keynotes need to be – easy to access easy to extract information from for use downstream, to develop specifications easy to edit, especially global revisions to identical keynotes throughout the document set. Currently, Vectorworks fails in each of these key areas. The current notes database scheme is arcane and difficult to use. There is not an easy way for users to extract information from the notes database – while it is possible report the database to a worksheet, inexplicably, data for the actual note is not accessible in a report. But the most significant failure in my view is the inability to globally edit identical notes within the program. Through the life a design project, notes must be revised numerous times, including – refining notes as the design becomes more specific correcting errors coordinating the entire set of notes to a standard Under the current Vectorworks keynotes design, a task as simple as correcting a spelling error requires finding and changing every instance of that keynote in the documents, a process that is painful, does not take advantage of automation, and is likely to introduce errors. Revit is not any better at keynotes documentation – in my view this creates both an opportunity and a threat for Vectorworks. We can spend more resources to implement a functional keynotes system and move ahead of other programs in this regard, or wait for Autodesk to develop a better keynotes scheme and fall behind.

True, you cannot hide a row - only a column. The other really useful feature of having multiple database headers is for Cabinet Schedules. Since VW has separate parametric objects for Base Cabinet, Upper Cabinet, etc., the only way to get all the cabinets into one schedule is to have a database header row for each cabinet type. But this works seamlessly - no way of knowing in the final schedule that there is more than one set of data. Except of course that you cannot sort or summarize between separate database headers, which to me is not a problem.

start by looking at a few walls in the OIP - check their heights and offsets under "Height" - it's likely that these settings were made to make the walls work in a Layers-only set up, but don't work in a Stories and levels setup. Check the 'Top Offset' setting in particular. Once you've diagnosed the problem with a few walls, you'll be able to fix the rest of the file. Also check your Layer heights in the Story setup - if you have furniture at odd levels, you may have your furniture on a Layer with an elevation setting that doesn't match the corresponding story. Again, no panic, just look up the correct elevation and set it correctly. we use stories and layers as our preferred setup, because it allows the model to respond quickly to design revisions easily. The key is understanding how stories and layers work, and setting the model up correctly.

One easy way to hide a column is to set the column width to zero - to restore, you'll need to select the columns on either side and reset all three of them.

It's essentially a pseudo relational database, using the key note number as the relational key. One weakness - changing the number of a keynote breaks the key pair relationship - then you have to either track down that keynote and change the key manually, or remember to re-edit the summarized data in the keynote edit worksheet. We are still testing this system to use on larger projects.

My biggest issue with the VW keynote system is not being able to easily edit keynotes after they are written. Almost always, we keep the same keynote number throughout a set, so 3.01, for example, is a particular note about concrete for the entire project. Thanks for your comments.

I've been struggling with finding a way to use keynotes effectively in Vectorworks - and for us, one of the most essential aspects is the ability to revise keynotes as a project proceeds through the design process. Our office uses keynotes with a numbered prefix keyed to the CSI division format, and all keynotes have the same number throughout a project. We only place keynotes in a sheet legend if the keynote actually appears on a sheet, and keynotes may frequently appear on many different drawings - plans, elevations, sections. Attached is a sample file showing an alternate system for placing and reporting keynotes, based on a keynote record format attached to a custom symbol. The system uses worksheets on each sheet layer to report the keynotes on that sheet, and a separate 'master' worksheet to handle global editing of keynotes. Global editing is limited - text or reference fields may be edited, but editing the actual keynote number will break the link - the keynote number is providing the key link to the worksheet. I'd love to get feedback or suggestions that would improve this system. 170527 VW 2017 test.vwx