gester

you don't have to make yourself any clearer. we simply have different bim expectations (and maybe definitions). you're but right in the vw development estimation. it's still not dynamic enough. rob

Right, it's the status quo now. On the other hand: our client has recently required the information how to use the delivered ifc file. And that's where bim begins. rob

that's what i mean, too. 2d output is still no bim for me. such communication is neither spatial nor fully parametrized. and that's why i value ifc data format, although it's implementation is not yet ripe enough, no matter what software package i use. rob

cool. will it work with bento either? rob

this is a very clear situation: the whole industry is changing, and new standards are being worked out on a daily basis. sticking to 2d and to dwg as a communication tool simply prolongs the accomodation time to new building process' mechanisms. the whole thing gets not only 3, 4 or 5d, there are new building contracts, the new project documentation delivery method (ipd) and the environmental questions, which are a fixed part of the project workout nowadays. stories in vw is a small step in the right direction. the question is: whether we (vw users) want small steps, bigger steps, or leaps? imo, if vw wants to be competitive, there's no time left for small steps anymore. in other words: the industry is changing, are we willing to change our personal working methods either? rob

that's why the lod (level-of-detail) hierarchy for the bim scheduling has been conceived. vico software company has even developed a tool for an improved scheduling, called flowlines (opposite to common gantt). people are working hard, and i'm glad it gets further rob p.s. i don't work for vico in any way

as i see it, the 'm' in bim is only possible when the information gets spatial. and that's the beginning. in other words: small bim is for me when the things get 3d. the real bim is 4d AND 5d (time and money). and that's what the hype is all about. rob

You're forgetting one thing: we already have DWG for interoperability during transition. i don't consider dwg as a future interoperability tool. it's only a status quo (unfortunately). and it's exactly the usage of dwg in those almost 30 years of building tasks' procedures which constantly winds up in such money losses that the whole industry is craving for a better performance. and i don't consider dwg as a tool for reliable communication to ensure the controlled workflow either. fractal and incomplete 2d information (which is the bottom line of any dwg drawing) is for me no information at all. rob

and this is the next reason to look for tools that include all these input sources you list into a single information pool. a kinda 'bridge over troubled water'. rob

facing the time and money losses in the real building processes reaching the 30% mark and even above, i don't think the real objects can be separated from the virtual ones. the whole bim hype is about inaccurate and missing information and the inability to communicate it properly while performing building engineering tasks in the real world. so it's about money. 'big boys' think they can cut out a big piece of the market cake, 'smaller boys' would prefer cooperation and breadcrumbs. rob

imo the first sentence contradicts the third, and the middle one is the clue. the information doesn't (and can't) depend on just one piece of software, otherwise all engineering projects' technologies should be the proprietary ones. the future IS information AND communication. there's no use of information piece which can't be submitted and understood. i can't see better tool to fulfill this than ifc. besides, nobody says the future is the 2d document. who knows what document type will serve the engineering processes in 5 or 10 years' time... rob

This has been the way VW has been perceived until now - a budget end CAD program with a bit of BIM. Trouble is, the near future of BIM is ALL or NOTHING. The chatter about BIM has exploded in the UK this year. There are conferences every week and leader articles in every journal. Almost none of them mention Vectorworks, because nobody is suggesting that VW can play with the big boys. It's no good talking about IFC and some rosy future of a level playing field - the big boys are not going to let you get a kick of their ball. Major contractors will settle on Revit or...well let's face it, Revit or nothing. Architects will work on Revit or they won't work at all. As a Mac office using VW, we've had to bluff our way onto jobs that contractually require us to use AutoCAD. This is ok, because we just make sure our DWG output is good enough to thwart any questions. How on earth our we going to bluff it that we use Revit when we're sent Revit project files or asked to supply them?? Please sir, can we exchange IFC instead?... Not a chance. you're mostly right, but that's why, as i understand it, ifc has been conceived as a cooperation tool to enable file exchanges between many apparently not (or hardly) compatible platforms. there's something wrong in the state of denmark when a cad software application dictates the way to perform an engineering task. i think the ifc standard development should be the highest priority of any cad software vendor. or has autodesk got other plans rob

but not if you have to calculate the amount of the demolished substance... rob

jeffrey, i thought the whole industry is working hard on supporting the ifc2x4 right now... rob

ok, i've generated a small ifc file from archicad v12. it contains two walls: the nearer one was made of 4cm aluminum plate, then i've changed model preferences to clear glass texture for front, back and sides. the other wall is a timber background one, without any textures, for a visual reference. the ifc file displays in the solibri model viewer... rob

thanks jeffrey for the matter-of-fact contribution, 1. yes, it's a wall tool, which has got a glass texture 2. the ifc data has been set automatically to ifcwallstandardcase 3. i wanted to see the wall as a transparent wall in the ifc file 4. the ifc file is meant to be sent to the branch designers, and not for the presentation 5. ok, fair enough, although i believe to have seen the archicad transparent glass export to the ifc file. i can't reproduce this right now, so i can't tell for sure thanks again for your input. @buildingdesignconsultant as i've stated before, it's for the design purposes, the wall item is a plain glass texture between aluminum structural elements. it's an early design phase, so i don't model double glazing. rob

nobody knows how to export a structural glass wall, which looks like a glass wall, to an ifc file? rob

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 i refer to the above jeffrey's posting over two years before, because i have current (vw2011) troubles in exporting walls to the ifc file. i've worked with archicad ifc exports, which render pretty well, without any manual improvements. this time i must switch to vw, and here i encounter some troubles. main reason for them is the structural glass wall of 4 cm compound thickness in my project, which exports as a solid element with standard thickness of some 15 cm (6 inches), as i can see in the solibri model viewer. i've tried with many class assignments, the only one with glass in its name being wall-ext-glazed, which won't export any glass material to the ifc file either. additionally i don't find any ifc class in the tree structure (aec>ifc data) to fulfill the task. i'm a bit tired of trying manually to achieve the status the likes of archicad perform without any additional workout. please tell me i'm missing something, which is quite possible in my vw experience stage, and that vw improved the ifc performance in this two-years-time. thanks in advance, rob

going back to the roots to undermine the whole software design concept won't help either but we're drifting... back to the topic: i'm a heavy archicad user, too. and in the ac v12 we also have troubles with the rigid storey settings (i dunno if the newer versions have improved on this issue, though). the entry storey on the ground level with the retail stores, as i conceived it, with flats on the back side on the 60cm higher level wouldn't work with the lifts. the lifts' doors stuck to the storey level at 0.00, and there was no force to rise them to the required 0.60, as the lift object doesn't have this parametric capability. and in the end i've wound up changing the main storey level to the 0.60, with all consequences of false wall foundations and heights to be corrected. the same with the lift overhead slab height, which sticks to the roof storey level, and has to be set to the value required by the lift object, not having much in common with the real construction nor finished roof level. so don't lament and try to find out the best way to proceed. other cad software vendors have their troubles, too. i still don't have the vw2012, but as i recognize, the best approach could be a combination of both layer and storey ways. rob

there's also a term called 'a technical storey', which is designed for the technical/maintenance reasons, not necessarily for the common peoples' usage as we know it. a crawl space in the foundation height is imho such a storey... rob

horst, thanks a lot, it does the trick. to be frank i didn't expect it that way, i thought it was the pdf export issue, besides i use mostly the preview app, but this reader feature is a neat solution. rob update: the trouble still remains with a transfer to the windows platform. the generated pdf doesn't get printed in thin lines, although reader previews show them onscreen. so back to the original question: can lines of various weights be exported as all-thin lines (like the line weight display toggle or sth)? thx in advance again...

they have various weights from many imports and i want them all thin. rob

hi guys, let's put this the other way 'round: how do i print all lines thin into a pdf document? thx, rob

i can't believe it's not possible to freely edit the dimensions of the bi-swing door parts. do we have a parametrized object or not? or am i missing something? we have here in europe many public buildings with escape way door dimensions 90+50cm (summing up to 140), with an active door dimension 90cm, and the other part only used in case of a fire. the equal division restraint of a bi-swing door is a big drawback.

the 'error machine' has the qt 10.0 installed, the older one the qt 7.6.9. does this mean the older quicktime version makes less trouble than the newer one? rob