Bimx File Revit

[Candi Ruman]

Vectorworksdoes not convert IfcEntities into native objects (yet). It's meant as a reference, similar to a dwg-file. The question is your use case. Do you have to work on the imported architecture or are you only referencing it? If you have to work with the model, the best way would be remodeling it according to the ifc file.

As @elepp states, IFC will only import as 'ifc entities' which will be 3d solids, rather than 'parametric' objects. Unlike ArchiCAD and Revit that attempt to convert IFC objects to native objects, Vectorworks doesn't. I tend to subscribe to that thinking, although I know others don't.

The idea of IFC is not for round-tripping models. It's for 3D coordination and data-extraction. The only way I could ever see round-tripping work effectively is if each software vendor agreed to an 'ifc work mode' to work natively in an IFC file format, similar to how Bentley and Autodesk developed a 'DWG work mode' for Bentley in order for Microstation to work 'natively' wth DWG. It works but severely limits the functionality of Microstation.

The currently situation is far from reliable in Revit particularly where Revit's rules do not allow some of the modelling techniques in Vectorworks and as a consequence we often find walls unjoin, and spaces connect to the wrong walls after conversion. The only way you can ensure a reliable facsimile of your work in revit is to convert the ifc to revit and then validate the revit model.

I think you may have unrealistic expectations of IFC exchange. From what you write it seems to me that you expect that an MEP element is exported from Archicad and its should be imported into Revit as the same MEP element types, with all its parameters transferred and working properly.

Geometry transferred from one BIM application to another using IFC is mostly recommended to be used as reference geometry based on which users can model their own geometries in their own software. BIM software are so different internally, one from another, that it is practically impossible to transfer the same parametric behavior between them, this is why IFC exchange is mostly for reference geometry.

I'm talking specifically about duct, pipe and cable trays which are system family with proper clear definition. I'm not talking about special Archicad/Revit properties. i expect from the global properties (length, diameter, width, height) to be shared in a way that would be easy to translate them on another BIM software.

Hallo!

have you found anything to convert IFC ducts and pipes to native revit families?

I tried add-ins "MEP Hangers" (it has convert option ), but it gives to me error for "MagiCAD for AutoCAD" IFC export

The viewer can be used as a stand-alone JavaScript application. In combination with open source CLI model conversiontools, it represents a low-cost, high-performance way to get your IFC models on the Web, that allows you the freedom toconvert and host your models on your own server or GitHub repository.

This section shows how to add your own models to the viewer application. These instructions rely on the mostrecent versions of XKT (V8 or later) and the conversion tools, which you can learn aboutin Viewing an IFC Model with xeokit.

The optional viewerState section specifies how the viewer should set up the initial state of its UI, right afterits loaded the initial models. See the complete list of available viewer states in Viewer States.

The table below lists the complete set of available configurations. Think of these as user preferences. These may beprovided to the viewer within project info files, as described in Model Database, or setprogrammatically on the viewerwith BIMViewer#setConfigs(), as described in Configuring the Viewer.

In Model Database we saw how a project can specify directives for how the viewer should set up theinitial state of its UI, right after the project has loaded. The table below lists the available directives. These canalso be set on the viewerusing BIMViewer#setViewerState(). So far, we have:

This section describes how to deploy models that use older versions of XKT that don't combine geometry and metadata.For those older versions,we need a little extra plumbing to deploy an additional JSON metadata file for each model.

XKT versions prior to V8 only contained geometry, and needed to be accompanied by a JSON file that contained the model'sIFC metadata. In this section, we'll describe how to deploy models that use XKT versions prior to V8.

Let's imagine that we want to deploy the Duplex and West Riverside Hospital projects, using XKT V7. For each modelwithin our database, we'll deploy a geometry.xkt, which is an XKT V7 file containing the model's geometry, anda metadata.json , containing IFC metadata for the model.

The ifc2gltf tool from Creoox, which converts IFC files into glTF geometry and JSON metadata files, has the option tosplit its output into multiple pairs of glTF and JSON files, accompanied by a JSON manifest that lists the files.

To integrate with that option, the convert2xkt tool, which converts glTF geometry and JSON metadata files into XKTfiles, also has the option to batch-convert the glTF+JSON files in the manifest, in one invocation.

This feature extends BIMViewer with the option to load models comprised of multiple XKT files, combining the XKT files into a single tree view for each model, and enabling the unloading of the model to unload all its XKT files in one shot. In other words, instead of having a separate model and tree view for each XKT, we can now group a bunch of XKT files together to behave as one model in BIMViewer.

In older versions of XKT, as mentioned above, we would have the metadata in separate JSON files, so that each XKT file would have the geometry, and would be accompanied by a JSON file containing its IFC metadata.

BIMViewer, and the rest of the xeokit SDK, remains backwardly compatible with this XKT+JSON separation. The split-model loading feature also remains backwardly-compatible, as demonstrated in the "WestRiversideHospital_Combined" example project, described below.

In the viewerConfigs we're enabling the viewer's Scalable Ambient Obscurance effect, which will create ambientshadows in the crevices of our models. This is an expensive effect for the viewer to render, so we've disabled it forthe "electrical" model, which contains many long, thin wire objects that don't show the SAO effect well.

If you were to substitute Server with your own implementation, your implementation might get that info from adata store, such as a relational database, populated with metadata for all the objects in your project's models, keyedto their IDs.

By now, you've probably noticed that our file system database is structured tosupport RESTful URIs, whichour Server constructsfrom the project, model and object IDs we supplied to the viewer's query methods.

The viewer will also enable Scalable Ambient Obscurance, since that's specified by the saoEnabled property inthe viewerConfigs. The viewer will also set various other configs on itself, as specified in that section.

Let's take a quick look at some of these methods to get an idea of what sort of UI state we can control with them. Thiswon't be an exhaustive guide - see the BIMViewer class documentation for the complete list.

Bim Collaborative Format (BCF) is a format for managing issueson a BIM project. A BCF record captures the visual state of a BIM viewer, which includes the camera position, thevisibility and selected states of the objects, and any section planes that are currently active.

Our viewpoint JSON will look similar to below. Before saving this viewpoint, we've hidden one object, selected anotherobject, and created section plane to slice our model. The viewpoint also contains a PNG snapshot of the viewer's canvas,which we've truncated here for brevity.

The viewer displays a modal dialog box whenever we load a model. The dialog box has a backdrop element, which overlaysthe viewer. Whenever the dialog becomes visible, the backdrop will block interaction events on the viewer's UI.

By default, BIMViewer loads whatever object colors and opacities are in the XKT model files, without changing them.Sometimes, however, certain types of objects may have colors that make it hard for us to view the model.

For example, in some IFC models, IfcPlate types may be used to represent windows, and those types are often given opaquecolors. That results in the windows of our model being opaque. For this example, we can make the windows transparentby configuring the BIMViewer, or just that model, with a custom color or opacity, for that IfcPlate type. That would makeall IfcPlate types transparent again. There are two ways we can do this - programmatically via BIMViewer.setConfigs, orfor each project individually, via the project's index.json file.

In the code below, we'll configure all IfcSpace, IfcWindow, IfcOpeningElement and IfcPlate typesto be transparent, and while we're at it, we'll make IfcWindow types to be always blue. Note that all values are in range [0..1].

Note that prior to v2.4, BIMViewer did change the colors and opacities of IfcOpening, IfcSpace, IfcWindow and IfcPlate bydefault. We've removed that in v2.4, because it was confusingand users wondered why those object types did not have the colors/opacities defined for them in the model.

The other way we can set these color/opacity customizations is per-project, within the viewerConfigs section ofa project's index.json file. If we've also set them via BIMViewer.setConFigs, then these will overridethe ones set via that method.

As an example, we've done this for the OTCConferenceCenter demo model, which otherwise has its windows opaque, which would make it hardfor us to navigate around that model. Therefore, we provide a custom map of colors and opacities for certain IFC types viathe viewerConfigs in the project index.json for that model, as shown below.

The snippet below shows how it's done, using a partial set of the translations expected by the componentswithin the BIMViewer. We'll just show the translations for the faces of the NavCube. We'll also load the translationsinline, rather than fetch them from a separate JSON file, as we would in practice.

3a8082e126