Jeffrey W Ouellette

When exported via IFC, the geometry for the current "3D Display" setting for the Site model is exported. That is, if you have "3D Display" set to "Existing Only", then that geometry only will be exported. Currently, the IFC export is focused on the 3D geometry and not the 2D geometry which can display the existing/proposed conditions in different ways via contour lines.

Use Viewports and Section Viewports and create a sheet layer with a plan viewport in the middle and sections viewports showing the elevation of respective walls, rotated as needed.

Christiaan, I think you ought to direct some of your pleasure to where it is really due, Peter Besley of Assemblage, for bringing the issue to our attention in a way that it could be addressed easily and simply by the NBS and Stephen Hamil's team.

Christiaan, Try reading the documentation on using Callouts as Keynotes. This should overcome your problem. Just setup a Keynote Legend where the Callout display is the Note Description, not Numbers, Letters, or the Note.

Look to Wacom and their Intuos and Bamboo lines

Peter, Could you send me a PDF, jpg, or vwx file of an example of this system in use on a drawing? I would like to add it to "user examples" for future reference. Just look for my email address in my profile (clicking on a poster's name will give you a pull-down menu).

Dan, Have you filed a bug and submitted the problematic files, yet See "Bug Submit" link in the VW Community Links Box above)? This would help our engineering staff out immensely to improve the situation.

Oh Bill... Personally, I don't have a problem with the new help system. It is what it is. I must admit, though, that I don't even really use it that much. IF I have a really burning question, that I don't know the answer to, I just pick up the phone. or walk down the hall to bug Robert or the engineer responsible. I know I'm spoiled. However, I do think the Callout/Keynote system still needs a bit of tweaking. I'd like to hear more feedback about UI, workflows, expectations, and results. I've gotten a lot so far, but more is always better. Some feedback so far includes: 1. Selecting the note from the Keynote Legend directly, NOT the database; 2. A better note database editor inside Vw; 3. More Default notes database content examples, including Uniformat/MasterFormat/OmniClass formatted descriptions;

Bill, Bill, Bill.... Doesn't ANYONE read the help documentation anymore? (See "Placing Keynotes")

Jenny, The Vw 2010 improvements to the Callout tool, Keynote Legend, and Notes Manager were made to address this very situation. When the Callout option "Place as Keynote" is selected, the resulting pulldown menu allows the user to "subscribe" the Callout to a particular Keynote Legend. The best way to make this work across multiple sheet layers (for example, multiple demolition plans) is to place the "Demolition Notes" Keynote Legend on "Notes/Legends" Design Layer. Then subscribe all the Callouts to this Legend. Next, create a cropped Sheet Layer Viewport of the Keynote Legend and place it on all the sheets you wish to see it. This way it will stay coordinated for all demo notes on all pages and only need to reference the Keynote Legend once.

Currently, we don't support it directly. But, A9PE does support import of IFC files (which you can export from Vw), which are then saved/published as 3D PDFs. This way the model structure and all the objects and data associated via IFC are preserved (in other words, you don't just get a big single chunk of dumb geometry). The Vestbanen Competition in Norway used this very technique in publishing the finalists' models to the web: http://www.statsbygg.no/Utviklingsprosjekter/Nasjonalmuseet/Tre-vinnere/ BTW, the winner, Kleihues + Schuwerk, designed their project, forum artis, using Vectorworks Architect 2009 and 2010 - :-)

In the Navigation Palette, there is a tab for all external file references. You can also access the Organization dialog from the View menu at the top menu bar.

Another idea would be to try ParaCloud GEM for modeling the desired form and all its intricacies: http://paraclouding.com/GEM/ Then, export as a DXF from GEM and Import into Vectorworks. You may have to tweak it a bit, or just use it as background to model over.

See my response to speed in the immediately above post...

Anaelle, What I meant was not about the 2D plan origin, but the referencing scheme where the user can choose to reference the file from a relative location or and absolute location in a particular folder, machine, or server. For the long reference update times of true referencing DLVPs, I wonder if you could perform a test by putting ALL the project files on a single machine and try opening the "slow" files. The point is to test if the network speed, or any choke points in the network are causing the delays in the updates, not the amount of data. A lot of optimization has gone into 2009 and 2010 to handle referencing, but the Vectorworks app has NO control over the quality of the network's ability to transmit this data. All it takes is one bad hub, wire, connection, or workstation settings to bring network speed to its knees and compromise the experience.

Anaelle, I must admit that looking at your PDF made my head spin before I fell off my chair. ;-) There is a great deal of complexity going on here, that I must also admit, I don't understand. Stan and I have had these discussions before, as I have had with other users in the past trying to do the same thing. Most of the time, I am overwhelmed by the level of complexity of these referencing schemes to get a project completed. Forgive me if I'm going to be a bit to philosophical here, but without actually troubleshooting actual files, this is where I must speak from. From my own perspective, learning/dealing with BIM has had a profound influence on rethinking the HOW of production as much as the WHAT is being produced. Ultimately, a set of drawings are needed in the same way they have been for a very long time, and will continue to be needed for some time in the future. With BIM, the model, the repository for the basis of all information displayed, is the new focus /requirement that adds a new dimension. Most times, users look at the end product, the drawings, and start from this point determining the workflows, human effort, and data structure for the project. In a CAD-centric, drawing-centric, 2D paradigm, this makes sense. Information must be sliced and diced in ways many people can get a lot of work done at the same time. But coordination is a nightmare, because information is not intelligently linked or directly derived from one view (plan) to another (elevation/section). In a BIM-centric paradigm, a complete, intelligent, 3D model is the focus of all workflows, human interaction and data structure. At some point, all the data, in it's "raw" form has to come together in a centralized way to create a singular instance of the database, as a whole, where the data can be queried, sliced and diced, and annotated for consumption or "rendering" in views necessary for documentation. In short, I think stepping back and re-examining a "typical" large project data structure from another point of view would be useful. Instead of saying "I've got 4 people, each responsible for these types of drawings", what about starting from "what will this virtual construction, this database look like, when complete, and how do I get that info in and the required views/drawings out in the most efficient way with the tools I have? I think this forces everyone to reconsider the modeling/drawing responsibilities in a way which may change the way the files, models, and drawings are ultimately structured and produced. I am sorry if this sounds a bit glib and abstract, but without going beyond diagrams, it's hard to be more concrete. The current technology of Vectorworks in a collaborative environment is what it is. The challenge for everyone is figuring out the sweet spot of leveraging it, or ignoring it altogether.

Anaelle, The advantage of DLVPs over the old fashioned workgroup referencing is file size. A DLVP is a "true" reference, it only marginally increases the size of the target file. The "old style" WGR is a full copy/paste of the data/model info into the target file, thus increasing the size of the file by the amount of data referenced. More to come...

Anaelle, Thanks for the info. Let me take some time to digest and respond this weekend. You can send any info to me at: jouellette@vectorworks.net

Peter, It sounds like you may have found a bug or two that need to be sorted out. The system was not meant to behave erratically. For Vw2010, the intent was to make the Notes Database system robust and persistent across all the design and sheet layers of a single file. Interaction with the Notes Database from multiple files SHOULD be predictable and consistent. If not, then it is a bug and needs to be fixed, immediately. My earlier testing did not seem to uncover the same problems you are now experiencing. I would like to have your issues formally submitted as bugs so that our engineers can address them.

Anaelle, I would be interested to see what kind of projects and the DLVP setups you were using. I realize that it is very easy for the DLVP system get out of hand and unravel. I would be interested to know more about how the team and project data were organized to handle modeling/drawing necessary information. Answering the following questions (and files) can help me provide some answers/help: How large was the project? (How many stories, how much area?) How many people were on the team? Who was responsible for what modeling/drawing? What was modeled vs. what was drawn (2D only)? What level of detail was modeled vs drawn? Were Sheet Layers used? How was printing of drawings handled? From which files were drawings printed from? What were you trying to do with the DLVPs? Reference floor plans from multiple files into a central model or layers from a central model to multiple files? Were there problems with visibility control of classes or layers? Were you using absolute or relative settings for the referencing? Were files being shared by a peer-to-peer network of computers, or was a central file server being used? Mac or PC, or mixed? I know these seem like a lot of questions, and there will be many more, but they are all relevant to getting a better understanding of what worked or didn't work and why. I would love to help you sort this out as I am working on revising collaboration documentation for Vectorworks offices/projects, over the summer. You can also contact me offline or PM. It would help me to be able to examine the files, first hand, to see where you found the pain and offer suggestions.

.rvt is a proprietary format of Autodesk. As far as I know, NO other application reads/writes/imports/exports .rvt directly (Navisworks? it is an Autodesk product also). I believe any interaction with other applications native formats must occur through plug-ins that connect to Revit via a translation API, or their functionality must just be plug-ins to Revit. Autodesk has it locked down pretty hard, unlike dwg.

Show off...;-)

Jim, You can refer to the following post for an example of how to create curtain wall designs beyond the scope of the WindowWall tool: http://techboard.nemetschek.net/ubbthreads.php?ubb=showflat&Main=28812&Number=140540#Post140540

Troy, Enable the option "Mesh smoothing with crease angle:" in your Document Preferences. Set the value to "1" to start, then increase it a bit to see if you can get the results you want. As our Parasolid implementation matures, I sure we will all see improvements of various aspects of the application. Just give it time... Clash detection is somewhere on our radar, but in the meantime, I think using Solibri, or even Navisworks, is an even better (though expensive) solution. These apps are really purpose-built for these kinds of processes and give the user the power to tailor the details of clash detection.

Of course, HE had to chime in....