Chad Hamilton HAArchs

No - updating a viewport is just a rendering operation in a local window. Saving and committing data is different. Think about working in a non-project sharing environment - you work on the drawing, add some data, then save - if you go to viewports containing views of the data, they are not updated, they need to be updated. Imagine you have two identical viewports - update one, the other is not affected until you update it. And you don't want to have the viewports automatically updating - you want them to update on demand. Otherwise you would be constantly waiting while the machine performed updates. Project sharing works the same way in this regard - you work on the drawing in your Working file, save and commit. The data is saved to the Project file. No viewport is updated until there is a demand to update it. For users in other Working files, the data isn't even read into their copy of the Working file until that user demands a Refresh. If another user has a viewport affected by the new data after a refresh, that viewport isn't updated until there is a demand for update by the user. Viewport rendering isn't data - it's just making data visible.

I do not believe the act of updating a VP by one user in a Working file will affect the version of the VP in another users Working file - this seems to be a local operation, and you would want it to be local to each user to avoid eating up computer time. Any data that is changed that might affect a VP is updated on Commit after the 2nd user refreshes.

you raise a very good question - and it seems like building it as one two story element would make sense. However, if you build it floor-by-floor, you will be able to take advantage of global parameters for heights and levels in the 'Stories' interface. Plus, if your two story curtain wall spans multiple floor levels, you will need some workarounds to have it show properly on the second floor if the curtain wall is modeled on the first floor.

I agree, this would be tremendously useful in checking and managing files for correct classing. Incorrect classing by designers seems to be a major cause of visibility problems and confusion. I could even imagine some self-checking fields that could throw flags ('if this object is a stair, why is it classed as a wall to be demolished') for example, that would help find problems.

Yes, screen capture works, but that is clumsy and takes multiple steps - seems like including a print button should be very easy.

Only option is to model the table from scratch, add chairs and create a symbol.

Wouldn't it be nice to have some options to have chairs on just one side of the table? Or make non-square tables? Many school desks are non-square, and designed to group together in different interesting ways, and no manufacturer offers a VW plugin with parametric options.

There also seems to be a problem exporting to DWG - multi line fields are not supported, and need to be corrected in the target program by hand.

Better documentation would help. After working with the title block for a few hours, I think the tool is fairly flexible - it is fairly easy to add custom fields to the title block, but this is not well documented. Searching in help turns up outdated info, as far as I can tell. The tool is apparently designed to link only to values in the Project Data record, which isn't accessible the way normal record fields are, but only through dialogue boxes in Settings, or the Custom field in the OIP. Can't find the documentation for that, either. It doesn't seem possible to arrange the order of fields so they show up in a logical order in the OIP - this would be a nice improvement. The fields for Revision and Issue don't seem to be able to be modified, and the Issue set has "approved" as a required data field, which requires a workaround if that is not office practice (I don't know any office where this would be meaningful, but other than requiring users remembering this unneeded procedure it's a small annoyance. on the plus side, the tool has a lot of well-executed custom options - one example is the Drawing Stamp function, with checkboxes and pulldown menus for options.

Small but useful thing - it would be good to have the ability to print any dialogue or UI pane, either for record, for marking up corrections, or documenting standards. Printing to the system dialogue would allow for creation of pdfs.

I think the advantage of an LOD setting concept would be in how the parametric tools work, and how content providers put information together. There is so much potentially valuable data out there prepared by manufacturer's, but it's prepared at LOD 4 for shop drawings. Getting the same data at LOD 2 or 3 would be incredibly valuable, but this would require cross-platform, industry-wide adoption of an LOD setting.

I agree, except LOD and scale are not exactly comparable, depending on the detail level of the model - an LOD 1 model would have LOD 1 level of information regardless of scale, whereas an LOD 3 or 4 model would have highly developed information in detailed views at large scale, but simpler detail at smaller scale.

For designers, it would make the most sense to include LOD settings at the view level, or even at the document level. Having parts of a drawing set to different LODs wouldn't really make sense, and I don't know of any BIM standards that would support this. Ideally, LOD levels would support settings at the parametric tool and resource level - elements within the parametric object or resource would appear or not depending on the LOD level set. I imagine that this is something that would be implemented by VW for tools and resources, and by content providers in BIM shop drawing or product drawing resources that we would bring into our files as designers.

We disagree - from your description of your work, you're working outside the area that VW has developed parametric tools - so you're spending a lot of effort modeling the unique elements you're working with. Try working with the hybrid tool - it may make your life easier, by providing a link between modeled elements and conventional view projections. And FYI, we do all our work in 3D.

The idea of having an LOD selection for 3d parametric tools would be genius - one setting that would add or strip away a level of detail from within the tool settings.

In the US, Red-Built offers revit families - http://www.redbuilt.com/reference/revit-families - technically these aren't sheet metal webs, rather they are bar trusses with wood top and bottom chords. I see that on MiTek's website, they claim they will model your project structure and share the BIM with you - http://www.mitek.co.uk/Software/PAMIR/PAMIR---More-Benefits/

I completely disagree - top/plan view is an abstraction that allows one to work productively without other distracting elements - it's like any other abstraction that strips out the elements that aren't immediately essential and lets one work on and present essential elements of a model.

You will get a screen hint when a blue bar appears - if you release your mouse button when the blue bar appears at the docking location, the palette will dock. You sometimes need to search around as you drag the floating palette to find the blue bar. Normal docking locations are to the left and right margins of the program window, outside the drawing area. Once you've docked a palette, the area immediately below the top and immediately above the bottom of the program window becomes available for docking , as well as the area between other docked palettes.

Creating a window style does do what you asking - editing the window style through the resource browser will modify all instances of that window style. Works great, even in sharing mode.

Go to File/Document Preferences/Units/Structural - you can choose from many Imperial, metric, and structural units, as well as define custom units. I believe VS will use whatever units you set in the document a script is running in.

We normally use the 3d cabinet tools. Increasingly, we model everything because - 1. It helps us visualize the design 2. It helps our clients visualize the design 3. Modeling the project speeds the process of design revisions that occur between schematic design and final construction documents 4. the parametric objects speed the process of scheduling casework (our projects tend to have tons of casework in classrooms and other spaces) 5. All of this speed the process of making multiple sections, elevations and visualization drawings I agree with all of Christiaan's points above, except that there's little point in modeling. Like everything else, it becomes easier the more you do it.

We should all, including VW, pay more attention to established standards for Level of Development (LOD). As clients, regulatory agencies and contracts begin to catch up with BIM standards, we will increasingly see LOD standards required for every stage of a project. We may put more modeling effort into some areas for preparing good-looking renderings, but overall we need to know and apply consistent modeling standards.

We also use many office-standard classes - to keep things simple, we keep the most used ones in a master sheet template. We keep a file with all our classes saved as a template in our Office Workgroup Standards folder, under Workgroup/Defaults/Standards. When we need a new class, our HAA Standards folder shows up as an option under the Import Classes menu (under New Class in the OIP). Our Workgroup Standards folder is a shared resource across the network, and uses a similar folder structure as the VW User folder, but stored on our central server.

Not sure 25 years with VW qualifies as "new"

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