Jeffrey W Ouellette

Select the worksheet, then go to your Attributes Palette and select "None" for the Pen settings.

NOT me...

Natalie, Please look at the attached files and images for the results of using Solid Additions, rather than Solid Subtractions, to create the waffle slab. 1) Create a Floor object of the basic supported slab, the thickness above the waffle coffers 2) Using the Wall Styles and Wall tool, create walls that are the width and depth of the needed primary concrete support beams under the slab above. Join the walls so it looks like a monolithic grid in Top/Plan view. 3) Create a 2D polygon grid of the shape and extents of the waffle coffers within each bay, between the wall/beams. This polygon grid can be made by drawing rectangles of the appropriate length and width of the bottom of the coffers. Then use Taper Extrude... command to created a 3D waffle grid, with a negative angle value (in this case -5.61). 4) Place four Loci at the corners of the bay, where the walls intersect. This is to help locate the object when it is a symbol. 5) Select the Loci and the 3D waffle grid and create symbol, using one of the loci as a insertion point. If you wish to make a 2D representation of the grid, just enter the group on the Tapered Extrude and copy the polygon. Exit Group and then paste the polygon in the correct place. Change the attributes, as desired. 6) Place the new waffle grid in each bay formed by the walls/beams. 7) Verify the Z-value of all parts in a Front view 8) Select all and select the command Add Solids. 9) Then use the IFC Data... command to add the IfcSlab entity to the resulting object. 10) Note that you can still edit the components of the slab by Enter Group. The resulting slab is less than 1/3 the size (4.8MB vs 15.7MB) of the same waffle slab created by using Solid Subtractions of the waffle coffers from a deep monolithic slab/floor. (BTW these are VW2009 SP4 files)

Natalie, You may be able to get better performance AND smaller size by using Solids Additions INSTEAD of Solid Subtractions. Robert and I have been experimenting this morning and I'll try to mock up the 11th floor for you to demonstrate.

Natalie, I tried a few experiments recreating a slab from the 11th floor of your model. I tried a couple different methods, all trying to lead to the same end, a monolithic waffle slab. In both 2009 SP3 and 2010 SP1, the waffle slab is a large collection of either solids operations (892 subtractions) or surface clips and one extrude. The resulting file is 15.7 MB. Any attempt to model the floor slab at this level of detail will result in a large file with editing of the waffle slabs being very slow. Converting it to a generic solid, after getting the waffle slab geometry correct did reduce the size of the slab from 15.7 MB to 3.8 MB, and make it more "responsive", but it is no longer editable. Bear in mind, I'm using a 1st gen MacBook Pro with an Intel Core Duo chip. It's definitely not the most powerful or fastest machine out there anymore. The only advice I would have is reconsidering the need to model the waffle slab and just model and export a simple floor slab. Leave the waffle cells as 2D symbols. You could then supplement the IFC model with DWGs that show the location of the waffle coffers, for those that need to know. If your consultants feel it is necessary, they can try modeling the waffle cells.

Whoa. It shouldn't take that long. At least not the model I saw. I keep hoping for a working Progress Bar, too. Natalie, you need to file a bug (see the link under the VW Community Links menu to the right). You can send the file to bugsubmit@nemetschek.net. We'll get the engineer's attention and see if there is something simple wrong, or not. In the meantime, you can send the updated file to me via YouSendIt.com, again, and I can try to take a look at it in its current state.

Natalie, At export, VW will not be responsive. A small "empty" dialog 'Export IFC' should appear in the middle of the screen after you say OK to the main export dialog. Behind the little dialog, the model (hopefully in Top/Plan view) will be constantly refreshing on the screen as the export works its way through the model. Depending on the size of the model, this will take a long time. The export translates the geometry and data for each storey/level into separate temporary files, then combines them into a single IFC model file at the end. The model I received from you earlier and examined might take no less than 20 min. to export. I've got larger models that take 40 min. and smaller models that take 1.

Jim (et al), The problem is in the use of DLVP referencing and custom symbols and records. When a user references a file from a source into a target, using the DLVP "true" referencing method, all resources of the source file are hidden from the user's view and interaction. However, plug-in objects are able to automatically reconcile themselves in this setup. Any custom resources, like user-defined symbols and record formats, remain hidden. If a user wants to create a multi-file setup, where the target document contains the database worksheet counting the objects in the reference sources, then the use "old style" layer import method of referencing is suggested. It creates a linked copy of all the source data in the target file (making it larger) and exposes all of the referenced resources as italicized strings in the various resource lists (classes, layers, resource browser-symbols, etc.). These resources are no longer invisible to the user and should be able to be counted using a Database Worksheet's Set/Edit Criteria command. Obviously we need to provide a better officially supported option for users which may include options in the Set/Edit Criteria of the Database Worksheets to actually search inside DLVP style referenced sources. Let's hear the votes for OR against such an option.

Send me the file.

Jim are you using Design Layer Viewports to import the plan of the source file into the target file? If you generalize the criteria, say look for all the fixture symbols, are they picked up in the database worksheet?

KeithW has actually presented one valid method for "curtain wall" modeling in VW. Another version of this method is to use a Wall Style that is the thickness of the glazing (1/4" to 1")and to insert Mullion objects for verticals and custom symbols/shapes for the horizontals. This is the methods that I used for the Ellicott Heights project. Besides being able to insert doors and vents where I wished, this technique allowed me to use the same Database Worksheet functions to determine the quantities of the wall. For the OGC AECOO Testbed last year, we (as well as ArchiCAD and Bentley Architecture) were actually REQUIRED to model the curtain wall according to Keith's method, so that EnergyPlus' model data transfer could properly "read" the qualities and quantities of the curtain wall. The point is, there is more than one means to the same ends, but the means are informed as much by the requirements of the end, as they are shaped by the technology available, or convenience of, the means.

Thom, Could you please elaborate on what you mean? Maybe list what workflow requirements you feel are necessary for such a tool/module? Especially explain how these might differ from the irrigation objects (line, emitter, head) provided in Landmark, today. Thanks.

I don't believe so. As I said IFC is a extended STEP format. Send me a .STP and I can experiment.

Well the irony is that VW DOES support STEP Files (ISO 10303), but only through VW Architect IFC export/import functionality, currently. IFC is a combination of STEP (ISO 10303) geometry with building industry specific semantic data. However, this may be a good Wishlist Forum item...

The crash reports go straight to the people that need them most, the engineers, without any "middlemen". You could also contact your Distributor and/or Tech Support and email them the file. They may be able to pass the file along and get it matched up with the crash reports.

Andrew (et al), If you want to get the best results for tracking down the problems and getting a resolution then please check in "Vectorworks Preferences" that the option "Error Reporting" under the "Session" tab is set to "Send crash details and usage patterns". This is new technology and functionality to VW that is now the single most important means of finding and fixing problems. To curb any concerns, NNA does not collect ANY personal data. The crash logs and use logs for Vectorworks 2010 are the only pieces sent to NNA automatically, nothing else. But these logs are very informative to our engineers in finding, analyzing, diagnosing, and fixing problems such as this. Our beta testers used this functionality and provided an enormous value to our engineers to get the best, highest quality initial release, of a VW version, out the door. Also, follow up each crash/issue with a bug report so it can be paired with the logs to better define the problem and get better personal attention from NNA staff. I would encourage EVERY user to verify the same setting to get the best troubleshooting results.

Shaun, I must disagree strongly with assertion about the representation of a stair in a BIM. Your proposal is in no way "standard" to the current data model for BIM in either IFC or BIM applications. I think difference in conception is, in some ways, harmful to the public's understanding of what BIM is, or isn't, and what applications are capable BIM tools, or not. Today, the generally accepted BIM specifications for building model representation include that a building is logically divided into storey/level/floor "containers". All elements are located in, or directly related to, that container. The data structure of IFC and many BIM applications rely on this container structure to locate and analyze the geometry and data of analogous elements. While their are legitimate concerns about elements/objects/systems that cross, or serve, multiple storeys simultaneously, there are also accepted conventions, at least in IFC specifications for the depiction of those instances. Stairs are NOT always so simple to be connected and similar from floor-to-floor, even in a single stairwell. Indeed, I'm sure Orso can come up with a few examples, as well as my own from the Ellicott Heights project.

I'll be doing the same test, soon enough, with VW 2010 (got a long list of other things to get to first). When I have them complete, I will post the results as I did with the 2009 file.

Without looking directly at the file/project in VW and IFC format, I can only provide the following answers: 1. The stairs SHOULD NOT be changing at export. This may be a bug in the particular version you are using. I have not see this result myself. 2. Right now, IFC import/export implementation for ALL vendors doesn't support colors or textures, as there has not been clear guidelines or implementers agreements to support this exchange requirement. IFC can technically support it, though it isn't easy. Today, IFC compatible application set their own color schemes, if any, for IFC files on import. 3. The walls losing thickness at export from VW shouldn't happen. And they should show correctly in Solibri. The results importing back into VW, though, is a bug, and a serious one. We'll have to file a bug report and get on it. 4. How have you created your ceilings? They need to have IFC Data attached to them to be exported. If you use the Floor command, or simply use an extruded plane, select the object, then select the "IFC Data..." command from the AEC menu. When the dialog appears, select the "IfcCovering" entity from the list. In the next dialog, select the checkbox, "Use standard properties for this symbol." Then select the IfcCovering in the list below and scroll down and select "Predefined Type". From there select the pulldown that appears at the bottom of the dialog and select "CEILING". Choose OK to exit the dialog. The ceiling should export correctly. 5. I'm not sure what you mean by "Spaces between columns get filled with walls". I'd have to see it first. 6. Classes don't get transferred. Again, this is a technical and implementation issue. There is currently a request to maintain "Layer Names" for objects at export(AutoCAD-centric, but we all know they are Classes in VW). We'll see where this goes in the international standards body over the next year. I am available online/offline to all users regarding IFC import/export issues. I can help examine and troubleshoot files, as well as locate implementation issues and get them filed as bugs and resolved. I want everyone to learn the best use of VW to get the best results and understand the limits of IFC, in general, but also be aware of the capabilities. Also understand the capabilities of other Applications is important when using IFCs. I personally do testing against our competitors products and other products that our users may be inclined to exchange information with. In the Autodesk 2010 application family, Revit was the least compentent import performer. AutoCAD Architecture and NavisWorks did the best, nearly perfect, with a complex VW model. This thread has illustrations of results from various applications: http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Main=26247&Number=126141#Post126141

Andrew, Petri is only partially correct, as usual. This was true prior to 2010. 2010 DOES provide this new functionality. It is called Automatic Drawing Coordination. This new functionality allows the user to use Sheet Layer Numbers and Titles, Viewport Name and Drawing Title, the Sheet Border/Title Block object, Section Line/Section Viewport indicators and Drawing Label object to create links between models (Top/Plan View) in Design Layers and Section Viewports on Sheet Layers. Some new elements have been added to make this possible. New data fields "Sheet Number" (Sheet Layers) and "Drawing Number" (Viewports) have been added. The Drawing Label has been made more intelligent, so when it is placed in the Annotation Space of a Viewport, the user has the option of applying the Viewport data and have it reflected in the Label, the Section indicator in the plan. It also "knows" which Sheet Layer it is on and updates, in all locations necessary, when moved to a new Sheet Layer. This is probably one of the most significant improvements to VW that impacts so many users' daily project workflows.

VW simply uses any system fonts. Add to it your system, it should be available to VW.

But the technology to do it, has not.

No. Or, I should say, not directly. The current IFC export implementation does not make a "parametric" object. It exports the geometry of the object as a surface model with the appropriate data. It is the burden of the importing application to read the data describing the door/window and map the information, and geometry, to the desired native application parameters for that particular object.

The new Stair object does not provide this functionality. Layer-to -layer linking, with a 2D object on the layer above, still works with the Custom Stair tool (which is actually the old Stair PIO), however.

No, not yet.