Robert Anderson

Petri, I don't know that I'd call IFC "geometry-poor." It really just doesn't support parameters. Parametric support is in fact being discussed for a future version of IFC. It's a two edged sword. What do you want: simpler geometry but parameters in a "dumbed down" version that all BIM applications can agree on, or exact geometry and data but no parameters? Each alternative has its advantages. I think there are very good and valuable workflows to be had with IFC-as-it-is. BIM is one of those "intuitively obvious" topics that people "just get": "of course! virtually build a building on my computer in 3D!" ...but when you really look at the workflows, exchanging of parametric (natively-editable) models creates more problems than it solves (in my opinion). It's possible to deliver an IFC model as an "instrument of service" without forcing the recipient into a strict intellectual-property-licensing scheme. I consider this a strength and not a weakness.

Make a symbol from your window wall or other custom geometry. Now use the "Use Symbol Geometry" option in the Window tool to add your window to your project and scheduling, etc.

DWorks, this is what we mean by IFC not being "parametric". You have an expectation of IFC that is just not part of the protocol, at least as the schema currently stands. IFC is about sharing and referencing data-rich 3D building models, not about file exchange from one native format into another. You can draw with walls and floors in a program (say Vectorworks) and get it into another program (say Revit, ArchiCad) and get accurate 3D geometry and data and semantics (i.e., high-level object type). You cannot edit it as you could a native object. TIP: In Vectorworks, you can edit the geometry of an IfcEntity object by using the "Enter Group" command and standard geometric editing tools.

Hey, Groovatron (wish I'd thought of that name!) Your problem has all the earmarks of an out-of-date video driver. Go to our knowledge base (you can access it from the "Support" tab of Vectorworks.net) and type in a search for "video card". There should be several topics available on this.

Chris, you know, it's kind of funny if you look at it just right. On one hand, you're very idealistic, very touchy-feely cooperative: On the other hand, you decry IFC (which after all has been developed in a cooperative method as you describe for projects) as So, which is it? I personally think the KISS approach to interoperability as forwarded by the openBIM initiative is the way to go. Today. I think exchange/sharing of parametric models is (for the present) the wrong approach. Why? When you propose that Nemetschek AG develop a parametric standard, that is just the strategy that AutoDesk is using with its RVT/RFA standard. Any standard that is exclusive will fail, because professionals like (understandably) to use their preferred tools. Parametric standards are problematic. While NAG could develop such a standard (and bSI is looking to do the exact same thing for a future version of IFC,) software developers make their living not by being the same, but by differentiating their products. So any parametric standard will by necessity be "dumbed down". Is this what users want? Or would they prefer having absolutely accurate geometry with data that they can use, reference, query? They can do this today with IFC.

See my comment on jsibert's other post about IFC/Revit product data.

jsibert1, I wholehearted agree with you as to the importance of this; I would think that almost all manufacturers would welcome a single, consistent, data rich form of product data delivery that would apply to all platforms. Now, having said that, and being very involved at high levels with the BuildingSMART alliance who runs the IFC biz, let me say that there are still technical challenges to this. The IFC powers-that-be have in general been working hard on just getting the exchange between programs up to a reliable quality level. They are making progress on this, and have signed up many software manufacturers (Nemetschek Vectorworks included) to obtain a second round of certification on IFC 2x3 using their new automated testing service. I believe the prospect of automated testing of IFC exchange is a long-overdue improvement in quality certification of the standard. I am also involved with R&D groups at Georgia Tech headed by the esteemed Chuck Eastman who are focusing (among other topics) on this topic. There is a will out there to see this thing done. That said, until there is a published standard for IFC-for-product-data (which will probably be an IFC "Model View Definition" or MVD), I doubt that Reed or any of the other "Revit houses" will stick their necks out. I mean, I think it could be done, but why should they take a risk? Their perception (wrongly) is that Revit is the standard. Only time and the marketplace will disabuse them of this notion. It can be a little frustrating to see how long it takes for "open standards" to be promulgated. But that's community politics for you

Bryan, you are in all likelihood not seeing opacity because you have Quartz (I see you're on a Mac; if you were PC, it would be GDI+) turned off in Vectorworks preferences. Turn it back on and [poof] all is as it should be.

Chris, thanks for the visual aids. I'm not sure I agree that it's, ahem, "a pretty simple join". 3 different wall styles, 2 different exterior materials. Anyway... Would you not in an ideal world want the insulation (rigid?) hatching to merge? Are they different types of insulation in the exterior and "party" walls?

Chris, can you provide a graphic example? Are you talking about a so-called "Y" join?

jsibert, please send a file that exhibits this (along with a brief description of the problem) to bugsubmit@vectorworks.net Thanks!

On "display" tab of Advanced Section Properties, check "Show Wall and Slab" components and the "Merge..." checkbox indented below it. On the "Attributes" tab, choose "Separate Cross Sections" and check "Use attributes of original objects."

Responses: 1. I really do not recommend using spaces on sheet layer viewport annotations. More than any other kind of notation, Spaces are viewed in multiple viewports and therefore must be created in the design layer. Spaces are definitely part of the model, not a view-specific note. 2. The default class can be whatever you want. 3. I don't know. I have not seen this with rectangular spaces -- will look into it. Feel free to enter a bug..

Peter, you're right -- it would be simpler. But more limited, also. I don't think this is a "workaround". It is a little more involved than the old 'additional data' method in VW-2010 and earlier but removes all limits on what you can display on the space and give you total design freedom on how you can display it. The trade-off in having vastly improved features is, sometimes you have to learn how to use them. The method for showing area is described in the sections of the online help that I mentioned.

Sounds like "silverpoint". See: http://www.silverpointweb.com/overview.html

Oh, I'd like to add a some other points on the new Space Labels: Space Label symbols can be multi-color, multi-class, multi-font, multi-whatever; Space Label symbols can include any graphics you want as well as text. Any Space Label text and graphics are scalable in viewport "advanced properties" using the text scaling factor.

The Space Tags are controlled by symbols. The symbols are drawn at 1:1 and the Space Object handles all the scaling, etc. So the symbols control everything using "variable" text (similar to linked text, but more powerful). For a complete discussion, look for the following topics in your online help: "Using Custom Space Labels" "Creating Space Label Symbols" HTH, Robert

Dimensioning is like any other notation. A few guidelines and observations follow: 1. Dimensions that show up on more than one view (i.e. more than one drawing) MUST be placed in design layer. For architecture, this includes controlling dimensions, grid dimensions, etc. 2. Dimensions that are "detailed" dimensions (i.e. that show up on one and only one drawing) may be drawn in the DL and specially classed (for that drawing only) or drawing in the SL annotation. 3. There are an awful lot of people who, contrary to much of the above dimension discussion, use sheet layer VPs for sheet formatting only. They don't "trust" VP annotations and draw everything on the DL. 4. Prior to Vectorworks 2011, if you wanted a dimension in a working plane other than the ground plane (aka layer plane), you HAD to draw that dimension in the viewport annotation. Now it's optional. As of Vectorworks 2011, I don't believe there are any circumstances where dimensions must be placed in sheet layers. 5. Text scaling "advanced properties" in Viewports will handle the dimension scaling / readability issues for dims on design layers.

Yes. Vectorworks, ArchiCad, Revit et. al. all have different "schemas" (collections of parameters) to describe our native objects. Translations of one native schema to another native schema is not only hard, it is, frankly, very unlikely to ever "live up" to user expectations. Just look at DWG, a relatively simple schema, and how few software apps have anything approaching round-tripping for that. In its current incarnation, IFC does not try to support parametric descriptions of objects. It delivers geometry, semantic typing, and static data attached to objects (think 3D symbol with a really complex record format attached.) But really, this limited approach can be looked at as a strength also. If all you have is data-rich geometry, and you can incorporate it accurately in your project, then that is a workflow that can work very well for consultant coordination, and it doesn't matter in whose program the IFC data originates. I can use Vectorworks, my structural guy can use Scia Engineer, my HVAC guy can use DDS-CAD, and as long as I can coordinate their assemblies into my project (and make space for them, check for clashes, etc.) then I'm happy. I don't need to, nor do I want to, edit their work as native BIM objects. BTW, I think the IFC in Vectorworks 2011 is (by far) the best we've ever shipped, and can hold its own with just about anybody.

Orso, you are right. I'll bring this up with the administrator of the wiki.

I'm shocked that no one in this discussion (who is seeking VS or SDK support) has mentioned the Vectorwiki: http://developer.vectorworks.net/index.php?title=Main_Page If you're a serious VS or SDK developer, this needs to be one of the tabs on your home page.

yoginathaswami, thanks for finding a simple shape that eludes the logic of our roofer. I will submit this as a bugfile.

Sam, is it necessary to have the textual information directly in the callout? This seems almost more like a scheduling application. You can have a schedule with an identifier field which orders it. Then you could make a custom tag symbol for the ID Label tool which accesses your record to extract the identifier text. So you could have a callout (actually an ID Label) which would display the identifier and the ability to reference the schedule which contains the longer information. This allows for a density of data within the drawing (so you don't need multiple layers).

The cursor in Vectorworks will change depending on the active tool you have selected. Other than the full-screen cursor preference, these are all set within the program and cannot be changed by the user. For example, when you change to a drawing function, the cursor changes to a small cross. For most standard picking operations, the cursor is an arrow. You can make changes to some of the interactive cursor settings, such as how visible and in what color you would like to see your snap and pick boxes, etc. Look at the "Interactive" tab on the Vectorworks Preferences dialog.

Chris Manus said: Chris: The truth is that many government organizations (GSA in the US, Senatti in Finland, Staatsbygg in Norway, etc.) are working very hard and spending real money on open (read: IFC-based) interoperable solutions. I have attended many conferences and workshops, and sat around the table with a bunch of expensive guys. Agencies don't throw that kind of money at stuff they don't intend to use. The truth is that some state- and university-based agencies have tried to implement (as you say) "single file-format delivery" or (as I prefer to call it) vendor specific BIM delivery. The most high-profile of these was the state of Texas, which published a Revit-based standard and then, only weeks later, retracted it, and re-assigned the guy in charge of it. Expensive and embarrassing (for someone). The truth is that establishing open, extra-proprietary standards to do something as complex as design and build a building take time, and it's a two-steps-forward-and-a-step-back kind of process. Mixing politics and technology is a frustrating process, but there's no other way to do it. It may not be important to you, Chris, but I think you should speak for yourself.