Chad Hamilton HAArchs

If there is much repetition in unit types, you might try creating unit types as symbols - this should save crunching geometry. Another different strategy would be to separate core and shell into one model, and residential units into another. I'm not a fan of separating models by floor, because then coordination between floors becomes more difficult.

Nice!

Yes, you are right - here is the formula pasted from the file - "I3" would be "A" from the written example. =IF(I3-INT(I3)>=0.01, (INT(I3)+1), INT(I3))

From the date of the post, I'm pretty sure this is a VW 2017 file - we tend to stay up to date. Here is a copy of the file exported to VW 2013. But you should upgrade, the enhancements are worth it. Space_Label_v2013.vwx

Is there a reference file available that provides definitions for ifc data fields? I've looked on the BuildingSmart web page, but can't seem to find it. The page http://www.buildingsmart-tech.org/ifc/review/IFC4Add2/ifc4-add2-rv/html/ has definitions from ifc to english - it would be very useful to have an index from english to ifc, to give a sense of where to look for something.

Note that the worksheets that appear on each sheet layer are set to report only keynote records on that sheet. If you edit a keynote from the worksheet on the sheet layer, you won't be editing all the keynotes if any show up on a different sheet layer. We find having a keynotes worksheet on a separate layer, set to report all keynote records throughout the file, is a good way to implement this. You could do it other ways - you could put the keynotes editor worksheet on every sheet layer, or you could just open it from the resource brower.

Here is an actual file that has the worksheet, plus the symbol elements - this later version works bi-directionally. A couple of caveats - when placing the worksheet on a drawing to act as keynotes, edit the database criteria to return keynote records from that drawing only (edit the criteria for the sheet or viewport name). When editing keynotes - we set up a design layer in our files called "Notes Management", with a version of the keynotes worksheet set to report all values for keynote symbols. Values in all keynote fields must be exactly the same - this is relatively easy to monitor and correct in the Notes Management layer. To change the text of a particular keynote globally - edit the keynote in Notes Management. 17070_RES_Model_171029_Stand_Alone.vwx

Yes, common info on title block file. We create a viewport reference to the common title block. Then a viewport of that reference for each sheet layer in a drawing file.

We set up a title block file for each project, and use a viewport reference of that title block in each other file we set up for the project. We usually have a separate model file for each building (of a campus, for instance), and with some larger buildings, we may split the building into multiple files. We separate 2d details into separate files, also referencing the same title block file.

We keep the building model in one shared file, which tends to approach 200 mb as a file. We keep the title block in a separate, referenced file, and 2d details in individual files. We keep alll sections, elevations and schedules derived from the model in the model file. Due to sheet size (typically we stick with 30 x 42 inch sheets), we will frequently split our models to follow what fits on a standard sheet - this also tends to keep our models within the same storage size range. For publishing, we link related files, so we can publish the entire project from the model file. Other than periodic file sharing bugs in the conversion from VW 2017 to VW 2018, this system works well with minimal problems.

To set basic parameters of Doors, Windows and other objects, you can set up a standard template for future use – 1. Create a new, blank document (or use a previous template if you have one) 2. Review the parameters of each object and set them to normal dimensions or values. 3. Do this for all the tools you want to affect. 4. Set default line weights, text size and formatting, etc. 5. Under the File menu, select "Save As Template" - navigate to your User Data and Preferences folder, which is defined under the User Folders pane of Vectorworks Preferences (User/Libraries/Application Support/Vectorworks/2018/Libraries/Defaults/Templates on a Mac - similar for Windows. 6. Once you save your template, create new documents by selecting "from document template" rather than "create blank document" in the new document dialog box. Your standard preferences will show up in documents created from this template.

I second this - and this should include not just door tags but window, plant id, wall tags - anything that is an id symbol should be page-scaled.

Assuming you are talking about VW files - we use both Macs and PCs in our office, and share all files through a server. You can also exchange files from one machine to another if you don't use a server, but VW runs the files as well on each machine. We also use Project Sharing in a multiplatform environment - one thing to note is you must set up file sharing using SMB, not AFP, as PCs cannot read AFP file protocol.

We have been moving towards as little paper as possible, both for long term archiving as well as day-to-day filing, so we keep almost everything on our own server. As paper comes in, we scan most rhings and file them on the server. Here is our hierarchical file system. HA Filing System.pdf

Check out this video - Check known dimensions on a design layer - if all else fails, try scaling your import so that the dimension of an object in the DWG file is correctly dimensioned to the scale of the design layer.

This sounds like a very good idea.

Interesting - we run a local server, with cloud backup every fifteen minutes (I think - some short period of time, anyway). When a file gets corrupted or a user does something unfortunate, we go back to the cloud backup. Day to day, everyone works off the fileserver.

In my opinion, this would not be good. I think it would be better to have the program behave as expected, and in my view the analogy would be between the behavior of data, revisions and viewports in a shared file should be the same as in a regular Working File. To deviate would be confusing, and one more thing to have to keep in mind while working. Again, the basic reason for not auto-updating viewports is to avoid chewing up machine computational time when you really want to be working.

I set up two computers next to each other so I could check and verify the conditions we've been bouncing around. 1. On machine A, add an annotation to a VP, then run 'save and commit' - refresh on machine B - the annotation immediately appears. 2. On machine A, update a rendered VP to show the rendered textures, sky, etc., then 'save and commit' - with the same sheet layer visible on machine B, hit 'refresh' - no change on machine B until 'update selected viewport'. 3. Add some data to the model on machine A - I added some geometry that would stand out very visibly, then 'save and commit' - on machine B, 'refresh' - the new data does not appear in the VP until you also 'update selected VP' This works with any data that's added, including adding rendering textures, but anything on machine B that would normally require a viewport update still needs a view port update. Adding annotations do not require a VP update, rendering operations, or model revisions, do require a VP update. They will only show up after 'refresh' plus 'update selected viewport'.

Isn't dropbox just syncing to local files? How do you get around the issue of losing data in dropbox if the local file is deleted?

Don't you have a landing at each stair, with a break in the handrail? Christian's method is what everyone I know uses - if you need to run the rail continuously through the landing, you could model that single piece of railing as a separate element and use it on as many levels as you need.

This is my experience - if you add annotations to a viewport in a Working File, then save and commit, it is pushed through to the Project File. If you invoke the "Update Viewport" command to update a viewport in the Working File, whether for rendering, modeling, or to update any other new data, that does not cause viewports in Project File to have updated views. To me that makes sense. For example - imagine user A is working on updating the design documents, and user B decides to do a complex render of a view of the school, then saves and commits. User A's file would be essentially locked up while the viewport rendered - that's why we have control over when viewports are updated. I have no idea whether this is on purpose or not, but it does make sense to me.

Shows how different users' perceptions are - I always use class hierarchies because for me it's very difficult to find what I want in a long list - makes my eyes glaze over. Points up the benefits of a customizable interface.

I think the interesting thing about discussing interface design is how to get all that data organized visually, and hierarchically. Some of us respond better to the visual organization, others to the written data organization. i personally like the idea of expanding or collapsing tabs - allows me to see information together that I think is important.

I don't mind the nested dialogues, specially the new style list down the side. To me it's certainly preferable to multiple dialogue boxes. I think nested dialogues help organize the clutter when there are miles of parameters to wade through. Particularly for related parameters normally used together. Agreed, nested dialogues are tedious.