ifcopenshell / ifcopenshell Goto Github PK

Open source IFC library and geometry engine

License: GNU Lesser General Public License v3.0

CMake 0.13% C++ 78.03% C 2.59% Python 18.37% Batchfile 0.08% Shell 0.01% SWIG 0.13% HTML 0.08% Makefile 0.04% CSS 0.05% Gherkin 0.39% JavaScript 0.08% Dockerfile 0.01% Mustache 0.01% PowerShell 0.01% Cypher 0.01%

ifcopenshell's Introduction

IfcOpenShell

IfcOpenShell is an open source (LGPL) software library for working with Industry Foundation Classes (IFC). Complete parsing support is provided for IFC2x3 TC1, IFC4 Add2 TC1, IFC4x1, IFC4x2, and IFC4x3 Add2. Extensive geometric support is implemented for the IFC releases IFC2x3 TC1 and IFC4 Add2 TC1. Extending with support for arbitrary IFC schemas is possible at compile-time when using C++ and at run-time when using Python.

In addition to a C++ and Python API, IfcOpenShell comes with an ecosystem of tools, notably including IfcConvert (an application to convert IFC models to other formats), the BlenderBIM Add-on (an add-on to Blender providing a graphical IFC authoring platform), and many other libraries, CLI apps, and more. Support is also provided for auxiliary standards such as BCF and IDS.

For more information, see:

Development is sponsored through your generous donations!

Name	Description	License
bcf	Library to read and write BCF-XML and query OpenCDE BCF-API modules	LGPL-3.0-or-later
blenderbim	Add-on to Blender providing a graphical native IFC authoring platform	GPL-3.0-or-later
bsdd	Library to query the bSDD API	LGPL-3.0-or-later
ifc2ca	Utility to convert IFC structural analysis models to Code_Aster	LGPL-3.0-or-later
ifc4d	Convert to and from IFC and project management software	LGPL-3.0-or-later
ifc5d	Report and optimise cost information from IFC	LGPL-3.0-or-later
ifcbimtester	Wrapper for Gherkin based unit testing for IFC models	LGPL-3.0-or-later
ifcblender	Historic Blender IFC import add-on	LGPL-3.0-or-later*
ifccityjson	Convert CityJSON to IFC	LGPL-3.0-or-later
ifcclash	Clash detection library and CLI app	LGPL-3.0-or-later
ifcconvert	CLI app to convert IFC to many other formats	LGPL-3.0-or-later*
ifccsv	Library and CLI app to export and import schedules from IFC	LGPL-3.0-or-later
ifcdiff	Compare changes between IFC models	LGPL-3.0-or-later
ifcfm	Extract IFC data for FM handover requirements	LGPL-3.0-or-later
ifcmax	Historic extension for IFC support in 3DS Max	LGPL-3.0-or-later*
ifcopenshell-python	Python library for IFC manipulation	LGPL-3.0-or-later*
ifcpatch	Utility to run pre-packaged scripts to manipulate IFCs	LGPL-3.0-or-later
ifcsverchok	Blender Add-on for visual node programming with IFC	GPL-3.0-or-later
ifctester	Library, CLI and webapp for IDS model auditing	LGPL-3.0-or-later

The IfcOpenShell C++ codebase is split into multiple interal libraries:

Name	Description	License
ifcgeom	Internal library for IfcOpenShell	LGPL-3.0-or-later*
ifcgeom_schema_agnostic	Internal library for IfcOpenShell	LGPL-3.0-or-later*
ifcgeomserver	Internal library for IfcOpenShell	LGPL-3.0-or-later*
ifcjni	Internal library for IfcOpenShell	LGPL-3.0-or-later*
ifcparse	Internal library for IfcOpenShell	LGPL-3.0-or-later*
ifcwrap	Internal library for IfcOpenShell	LGPL-3.0-or-later*
qtviewer	Internal library for IfcOpenShell	LGPL-3.0-or-later*
serializers	Internal library for IfcOpenShell	LGPL-3.0-or-later*

ifcopenshell's People

Contributors

Stargazers

Watchers

Forkers

aothms iras jf--- tridify luciferz2012 janbrouwer vtreem sasobadovinac whztt07 tpaviot isbe-tue sgrogan srounce fbosche shsteven theoryshaw larsmoa stgatilov inehci yorikvanhavre szwbuaa yltectus go2zo berndhahnebach ylcnky farialima mrozmanith neveroldmilk mcukierman avatar-z fxkulou andersgb sanderboer cnyzgkn jakob-beetz webdada hainan89 faddi donrv aahoo sigvemartin carlesrt lukasmhd ani-rudh softempire mitmadness usamaij arzezniczak whl2100 liweimax rainmanzj civilx64 balaprasanna nehczy linebreaker lukeb42 stinkfist0 bjorkstrom youaresoomean thomas-guenet countryschool fragcolor weihoutian gstariarch ifreeze-qiu hasashi2 xsoiou fatboy-hard lpaone pitmanmw skenezr jenniferzh jwerbrouck lp249839965 amtech frozar xyearn luoyuke jimmytum katakataka victor-haefner boltenweb vtxf foreverdavid jspataro791 wangzhefeng2000 jlfn1964 ezhangle plumpmath ifcopenbot pravesh-jamgade xjliu1204 wallashss neanex ifcwebserverteam vdubya tesla-coil dabiaoluo zpgit luzpaz

ifcopenshell's Issues

IfcConvert generates DAE that crashes Collada Importers

VS 2015 x64 RelWithDebInfo build:
IfcConvert.exe ..\..\test\input\acad2010_objects.ifc acad2010_objects.dae
Both ViewFBX and Unity will crash when trying to open the file. The crash seems to occur with all possible input files. OBJ works fine. OpenCOLLADAValidator tells the file to be valid.

I have been using mostly my old SourgeForge-based fork and noticed this now when testing the official repo/fork as I wanted to test the fixes in IfcMappedItem surfaces styles.

Coding conventions?

The coding conventions of IfcOpenShell seem rather mixed. What would be the "official" conventions to follow when I start to contribute?

Merge layerset_slicing branch into master

Allow Ifc2x3 and Ifc4 conversion from the same executable / library

As of now, whether to link to the 2x3 or 4 schema is a compile time option. This is inconvenient for users as they need to be aware of the schema of their model and have two executables ready. IFC4 is mostly a superset of 2x3, but there might be some incompatibilities (nobody really knows it seems).

One possible approach would be to have multiple separate static/dynamic libraries for the different schemas, that are built from the same source, with the same preprocessor directives that there are now. In run-time geometry interpretation can then be delegated to the respective library based on the schema identifier in the model file.

Erroneous space materials

When using the IfcConverter to convert the duplex house (with only space included) some spaces are not transparent. I see the same in other models as well. In solibri I see that theese spaces are a different colour then the other (I think they use a different geometry) but they are transparent.

Serialize arbitrary TopoDS_Shape as IfcRepresentationItems without tesselation

MSVC: allow choosing static or dynamic run-time

Requires #80

Error when converting ifc file using IfcConvert

I have tried this in both v4 and v5 with same result.

When I convert the attached ifc file It seems like some windows and opening elements are skewed a bit. Opening the file in solibri shows a different result. Do you have any suggestion on what is happening, is there anything I can do to fix this?

This is a screenshot from solibri showing the ifc file.

This is the ifc file:

wallwindow.ifc
Uploaded using ZenHub.io

Missing colors for IfcMappedItem-geometry

I have a case where colors are missing for some geometry. I have not been able to pinpoint the issue, but I have been able to create a minimal example file that reproduces the issue. The file can be opened in e.g. Solibri Model Viewer and here the color is correct. IfcConvert outputs the default gray material - even though there is a keyword IFCCOLOUR which should have been picked up by IfcConvert.

I created an illustration of how the material is associated with the geometry in the failing example, and how it is associated in a working file, see colormapping.pdf.

Note! The file is an exempt from a full model. I cannot share this file here, but if it will help I can send it to you by email.

GreenOnlyColour.ifc.zip

Error when exporting to svg

Hi,
I'd like to export 2D floor plans from IFC files but I'm getting a weird issue when trying to export as a SVG file.

./IfcConvert ~/IFC_Sample/SimpleTest.ifc test.svg
Scanning file...
Done scanning file   

Log:
[Error] Unable to parse .ifc file or no geometrical entities found

Whereas when converting to OBJ file no error is raised...

Is there something specific to the svg exporter that could break the conversion ?

Thanks

Error Logging reporting (geometrical) objects GUIDs.

Hi,

The current IfcOpenShell's error log correctly reports the IFC file line numbers where the issue manifested itself while exporting the geometry.

That is fine except that those STEP ids are very local within each (geometrical) object's description in the IFC file and don't match any of the GUIDs/names of the objects exported so there's little room to quickly point at which (geometry) object has been affected by the reported issue (partial or total conversion fail).

It would be quite helpful if the GUID of the object with internal issues was added to the error log too.

Thanks.

Make geometry export more efficient by separating position and normal indices

As of now, an index in IfcGeom::Representation::Triangulation refers to a unique {vertex, normal}-pair, as this is the standard for all OpenGL-based rendering. However, file formats such as OBJ and Collada have separate indexing streams. Maintaining index-pairs results in repeated pairs of indices and more vertices and normals emitted than necessary (especially note the many repeated identical normals):

    <source id="representation-2978545-positions">
      <float_array id="representation-2978545-positions-array" count="1548">0.718 0.015 2.5 0.718 0.015 2.936 0.718 0 2.5 0.718 0 2.936 0.718 0 2.5 ...</float_array>
      <technique_common>
        <accessor source="#representation-2978545-positions-array" count="516" stride="3">
          <param name="X" type="float"/>
          <param name="Y" type="float"/>
          <param name="Z" type="float"/>
        </accessor>
      </technique_common>
    </source>
    <source id="representation-2978545-normals">
      <float_array id="representation-2978545-normals-array" count="1548">1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 0 0 1 0 0 1 0 0 ...</float_array>
      <technique_common>
        <accessor source="#representation-2978545-normals-array" count="516" stride="3">
          <param name="X" type="float"/>
          <param name="Y" type="float"/>
          <param name="Z" type="float"/>
        </accessor>
      </technique_common>
    </source>
    <vertices id="representation-2978545-vertices">
      <input semantic="POSITION" source="#representation-2978545-positions"/>
    </vertices>
    <triangles material="IfcWindow" count="172">
      <input semantic="VERTEX" source="#representation-2978545-vertices" offset="0"/>
      <input semantic="NORMAL" source="#representation-2978545-normals" offset="1"/>
      <p>0 0 1 1 2 2 5 5 3 3 4 4 8 8 6 6 ...</p>
    </triangles>

Define export symbol to have IfcGeom as a dynamic lib

As per #76 (comment)

new CharacterDecoder.cpp

Hi Thomas,

thanks for your create work.
I just tried the 0.5.dev Version on GitHub.
If i use the last changes in CharacterDecoder.cpp, some Archicad Version 19 Ifc Modells don't work anymore.
Sometimes a lot of IfcProducts are missing, sometimes it can't find anything anymore.

TPO BIB-Gebaeude - Testdatei CKi_Teilausschnitt.zip

In the same file are some walls which are not correctly clipped. Maybe you know the reason why?

kind regards,

Christian

Possible issues with windows backslash separated paths in cmake.

See FILE(TO_CMAKE_PATH ${A_PATH} A_PATH_CMAKE) as a possible solution referenced in http://www.mail-archive.com/cmake%40cmake.org/msg13737.html

Make optional attributes of type boost::optional<T>

In fact this is already implemented in:
aothms@214c228

IfcConvert fails to open file if the file names contains non-ASCII characters (Windows)

As a workaround, rename the file.


>IfcConvert.exe ä.ifc

Log:
[Error] Unable to parse .ifc file or no geometrical entities found


>ren ä.ifc a.ifc

>IfcConvert.exe a.ifc
Scanning file...
Done scanning file
Creating geometry...
Done creating geometry

Conversion took 6 seconds

Wavefront OBJ serializer outputs low precision

In commit 43f5d44 WavefrontObjSerializer.cpp was refactored. One of the changes was to remove line obj_stream << std::setprecision(std::numeric_limits<double>::digits10);. This causes the precision of the OBJ files to be too low in certain cases, typically in IFC files with huge offsets or very large coordinates.

Add unit information to IfcConvert .XML output

See https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/f2ee2c03/

CMakeLists.txt for IfcMax

Marking this down as an FYI/public to-do if people wonder when they don't find IfcMax in the solution after running the Windows build scripts.

Provide a PYTHON_EXECUTABLE path to CMake so that the correct installation dir can be determined

At https://github.com/IfcOpenShell/IfcOpenShell/blob/master/src/ifcwrap/CMakeLists.txt#L58 a random python interpreter is picked from the path which might be unrelated to the PYTHON_LIBRARY and INCLUDE_DIR provided during build.

Build script fails under OS X El Cap

Building under OS X El Cap (10.11) fails with the follow error:

Undefined symbols for architecture x86_64:
  "_lzma_auto_decoder", referenced from:
      _xz_head in libxml2.a(xzlib.o)
  "_lzma_code", referenced from:
      _xz_decomp in libxml2.a(xzlib.o)
  "_lzma_end", referenced from:
      ___libxml2_xzclose in libxml2.a(xzlib.o)
  "_lzma_properties_decode", referenced from:
      _is_format_lzma in libxml2.a(xzlib.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I've made a PR to fix this issue:
#51

Implement remaining (not frequently used) IFC2x3 and IFC4 representation items

These are all non-abstract subtypes of IfcRepresentationItem. Most of them implemented, details follow.

IFC2X3

No support planned:

Ifc2DCompositeCurve (DEPRICATED, removed from IFC4, supertype supported)
IfcBezierCurve (DEPRICATED, removed from IFC4)
IfcBoundedSurface (No attributes, made abstract in IFC4)
IfcBoundingBox
IfcBoxedHalfSpace (supertype supported, no meaningful behaviour added)
IfcGeometricCurveSet (supertype supported, no meaningful behaviour added)
IfcLoop (No attributes, should be abstract?)
IfcVertex (No attributes, should be abstract?)
IfcRationalBezierCurve
IfcAnnotationFillArea
IfcAnnotationSurface
IfcDefinedSymbol
IfcFillAreaStyleHatching
IfcFillAreaStyleTileSymbolWithStyle
IfcFillAreaStyleTiles
IfcOneDirectionRepeatFactor
IfcPlanarBox
IfcPlanarExtent
IfcTextLiteral
IfcTextLiteralWithExtent
IfcTwoDirectionRepeatFactor
IfcAnnotationCurveOccurrence
IfcAnnotationFillAreaOccurrence
IfcAnnotationSurfaceOccurrence
IfcAnnotationSymbolOccurrence
IfcAnnotationTextOccurrence
IfcDimensionCurve
IfcDimensionCurveTerminator
IfcProjectionCurve
IfcTerminatorSymbol
IfcAngularDimension
IfcDiameterDimension
IfcDimensionCurveDirectedCallout
IfcDraughtingCallout
IfcLinearDimension
IfcRadiusDimension
IfcStructuredDimensionCallout
IfcLightSourceAmbient
IfcLightSourceDirectional
IfcLightSourceGoniometric
IfcLightSourcePositional
IfcLightSourceSpot

IFC4

No support planned:

IfcAnnotationFillArea
IfcFillAreaStyleHatching
IfcFillAreaStyleTiles
IfcPlanarBox
IfcPlanarExtent
IfcTextLiteral
IfcTextLiteralWithExtent
IfcLightSourceAmbient
IfcLightSourceDirectional
IfcLightSourceGoniometric
IfcLightSourcePositional
IfcLightSourceSpot

Lack of colors in version 5

IfcConvert v5 has a lot less colors than in v4. Is there a way to fix this? And if I include space they are not transparent, as they are in v4.

version 4

version 5

IfcConvert returns no geometry with normal IFC files when the flag "--include --entities IfcSpace" is added.

Hi,

I used IfcConvert with an IFC file somehow coming from AutoCAD. The file seems to use primarily IfcSpace and its geometry can't be converted unless using the flag "--include --entities IfcSpace". I added such flag and the geometry came out nearly OK, so far so good.

I kept the "--include --entities IfcSpace" flag for other IFC files which normally don't need the flag and the result was no geometry at all this time. I removed the "--include --entities IfcSpace" flag and the geometry came out all right instead.

It looks as if the "--include --entities IfcSpace" flag somehow stops the usual IfcBuilding/IfcBuildingStorey/IfcSite from being processed. Could that be the case? I used IfcOpenShell r339.

SVG serializer match group id to entity id

Hi,
I've been playing a bit with the IfcConverter in order to generate SVG files, but I didn't find how I can link a group that represents a wall to the IFCWALL from the .IFC file.

From what I can seen the id inside the svg are structured like product-product-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-body whereas in the source file I got xxxxxxxxxxxxxxx.

How can I keep the link between the source and the output ?

Thx

Turn Collada export into a streaming serializer

The IfcGeom::Iterator is designed in a way to allow streaming access to geometrical elements. However, due to the nature of Collada, with library nodes for geometries and materials that precede the instantiation of objects, everything is currently retained in memory.

To implement this in a streaming fashion three parts need to be changed:

Surface styles and default materials need to be queried before the IfcGeom::Iterator loop. This probably will result in emitting unused styles to the file
No longer retain the geometry definition and placement information, but solely retain placement information in memory and emit geometry directly
Switch to an XML library that supports streaming output

Embed more detailed version information (git commit id) in binaries using build scripts

Now that there are build scripts for all major operating systems. Run a git describe and capture the output in a preprocessor directive somewhere in order to have more detailed version information embedded in binaries.

Missing triangles for RIV in model 'Demohuset'

I experience some missing triangles for certain geometry in various models in the latest version of IfcOpenShell (81ee600). This issue is visible in several models, but I have extracted one object from the public available 'Demohuset' model that hopefully will help in determining the cause. Also note that many triangles have wrong facing normals - this is not a big problem for us as we remedy this by disabling back-face culling.

In Solibri Model Viewer the model is rendered correctly:

The OBJ output from IfcOpenShell is missing some triangles (note that this is rendered without back-face culling):

The IFC file (extracted from original): RIV-Ventilasjon-extracted-fan.ifc.zip
The original file IFC file is available from http://www.demohuset.no/page5321913.aspx.

I have verified that this worked with an old version of IfcOpenShell (462425f), but have not pin-pointed when the issue was introduced. I have built IfcOpenShell with OpenCascade 6.9.1.

Problem converting IFC to SVG for Equipments

Hi everyone,

The converter is working perfectly for IfcSpace, IfcWalls, IfcWindows, IfcDoors, IfcSlab.
But, I've got a strange issue concerning the converting in some elements like IfcFurnishingElements, IfcFlowTerminal, etc.
Sometimes, it works fine and sometimes, it doesn't. I don't understand the differences in the elements that makes them converting fine or not.
For example, in this svg of a space within it 2 storages, 1 drawer, 1 tv, 2 armchairs and 1 desk, only for 2 storages a path is made. After checking carefully the others objects, I can't find why it isn't working for the others objects.

I'm hopping someone cant explain me why and how i can correct this. Thank you everyone.
Fred

WELD_VERTICES flag enabled leads to invalid triangle meshes

If WELD_VERTICES is disabled resulting scene looks fine.
When WELD_VERTICES is enabled, part of the triangles are totally lost, on several ifc files, some triangles seem to degenerate.

The issue is reproducible with test asset
IfcOpenShell\test\input\acad2010_walls.ifc

The scene is built using a
IfcGeom::Iterator<float>
with following settings

    settings.set(IfcGeom::IteratorSettings::APPLY_DEFAULT_MATERIALS, true);
    settings.set(IfcGeom::IteratorSettings::CONVERT_BACK_UNITS, false);
    settings.set(IfcGeom::IteratorSettings::DISABLE_OPENING_SUBTRACTIONS, false);
    settings.set(IfcGeom::IteratorSettings::DISABLE_TRIANGULATION, false);
    settings.set(IfcGeom::IteratorSettings::EXCLUDE_SOLIDS_AND_SURFACES, false);
    settings.set(IfcGeom::IteratorSettings::FASTER_BOOLEANS, true);
    settings.set(IfcGeom::IteratorSettings::INCLUDE_CURVES, true);
    settings.set(IfcGeom::IteratorSettings::SEW_SHELLS, false);
    settings.set(IfcGeom::IteratorSettings::USE_BREP_DATA, false);
    settings.set(IfcGeom::IteratorSettings::USE_WORLD_COORDS, false);

Wall geometry sticking out

There seems to be a problem with walls consisting of multiple IfcPolygonalBoundedHalfspace boolean clipping results. The entity id of the wall with the problem is #9151.

IfcOpenShell	Solibri

Additionaly, the IfcStyledItem (#1453) of an IfcExtrudedAreaSolid (#1418) used in the geometry of wall #1460 doesn't get applied, so the default material is used.

You can download the IFC file here. We are using the latest master version. Thanks in advance for taking a look at this :)

windows buildscript

Just tried to build on windows 7 by provided buildscript. I had done this before sucessfully a few times (last one on 8th of January). I get an error on building depencieces. I do not know if it is the right place to report the problem?

Attached a file containing the last 9999 lines of compiling. Is oce the culprit?

bernd
log.txt

Improvements to 3dsmax cmake script

Follow up of #35 and #13

Apparently the 3dsmax installer sets some environment variables: ADSK_3DSMAX_SDK_20x0 (only for newer 2015 and up it seems?).
Use a simple for loop in CMake to see what is set in case no dir is explicitly set by the user.
Therefore the hardcoded path set to THREEDS_MAX_SDK_HOME in run-cmake.bat would no longer be necessary.
Propose to rename to ADSK_3DSMAX_SDK_ROOT for users to set a specific path.
Error out when doing a 32bit build and 3ds max > 2013
Set correct libraries for 32bit build if possible
Check existence of Max.h and maxutil.lib library, else error out
Add INSTALL target based on ADSK_3DSMAX_x86_2013 / ADSK_3DSMAX_x64_2013 install path

Don't use `TopoDS_Shape::Move()` to apply scaling

As discussed in tpaviot/oce#615 and https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/f1d8c8cc/?limit=25

IfcConverter: Obj file referencing the wrong mtl file

Currently the file reference in .obj is

# File generated by IfcOpenShell 0.5.0-dev
mtllib BIMhouse.mtl.tmp

It should not include the .tmp extension at the end.

Fix build scripts to known good revisions of OpenCOLLADA and OCE

These libraries introduce breaking changes from time to time.

IfcGeomServer instructions?

There seems to be lacking any kind of instructions for trying out IfcGeomServer.

cmake failure on windows build script

Since the layer slicing stuff is in master I gave the windows build script a try after a few weeks of quietness. I got an error on cmake. Does someone know what's going wrong here.

Is it the missing boost one. What do I need to look for, a dll ?!

cheers bernd

C:\Users\bhb\Desktop\ifcos\ifcosdev\win>run-cmake.bat "Visual Studio 12 2013 Win64"


Script configuration:
  Generator = "Visual Studio 12 2013 Win64"
  Arguments =

Dependency Environment Variables for IfcOpenShell:
   BOOST_ROOT              = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps\boost
   BOOST_LIBRARYDIR        = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps\boost\stage\vs2013-x64\lib
   ICU_INCLUDE_DIR         = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\icu\include
   ICU_LIBRARY_DIR         = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\icu\lib
   OCC_INCLUDE_DIR         = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\oce\include\oce
   OCC_LIBRARY_DIR         = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\oce\Win64\lib
   OPENCOLLADA_INCLUDE_DIR = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\OpenCOLLADA\include\opencolla
da
   OPENCOLLADA_LIBRARY_DIR = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\OpenCOLLADA\lib\opencollada
   PYTHONHOME              = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\Python27
   PYTHON_INCLUDE_DIR      = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\Python27\include
   PYTHON_LIBRARY          = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\Python27\libs\python27.lib
   PYTHON_EXECUTABLE       = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\Python27\python.exe
   SWIG_DIR                = C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\swigwin
   THREEDS_MAX_SDK_HOME    = C:\Program Files\Autodesk\3ds Max 2016 SDK\maxsdk

   CMAKE_INSTALL_PREFIX    = C:\Users\bhb\Desktop\ifcos\ifcosdev\installed-vs2013-x64

Running CMake for IfcOpenShell.
-- BINDIR: C:/Users/bhb/Desktop/ifcos/ifcosdev/installed-vs2013-x64/bin
-- INCLUDEDIR: C:/Users/bhb/Desktop/ifcos/ifcosdev/installed-vs2013-x64/include
-- LIBDIR: C:/Users/bhb/Desktop/ifcos/ifcosdev/installed-vs2013-x64/lib
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.5/Modules/FindBoost.cmake:1647 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.59.0

  Boost include path: C:/Users/bhb/Desktop/ifcos/ifcosdev/deps/boost

  Could not find the following static Boost libraries:

          boost_atomic

  Some (but not all) of the required Boost libraries were found.  You may
  need to install these additional Boost libraries.  Alternatively, set
  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
  to the location of Boost.
Call Stack (most recent call first):
  CMakeLists.txt:104 (FIND_PACKAGE)


-- Boost include files found in C:/Users/bhb/Desktop/ifcos/ifcosdev/deps/boost
-- Boost libraries found in C:/Users/bhb/Desktop/ifcos/ifcosdev/deps/boost/stage/vs2013-x64/lib
-- Looking for opencascade include files in: C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\oce\include\o
ce
-- Header files found
-- Looking for opencascade library files in: C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\oce\Win64\lib

-- Library files found
-- ICU libraries found
-- OpenCOLLADA header files found
-- Found SWIG: C:/Users/bhb/Desktop/ifcos/ifcosdev/deps-vs2013-x64-installed/swigwin/swig.exe (found version "3.0.7")
-- Looking for Python header files in: C:/Users/bhb/Desktop/ifcos/ifcosdev/deps-vs2013-x64-installed/Python27/include
-- Looking for Python library file in: C:/Users/bhb/Desktop/ifcos/ifcosdev/deps-vs2013-x64-installed/Python27/libs/pytho
n27.lib
-- Found PythonLibs: C:/Users/bhb/Desktop/ifcos/ifcosdev/deps-vs2013-x64-installed/Python27/libs/python27.lib (found ver
sion "2.7.10+")
-- PYTHON_DEBUG_LIBRARIES not found, defining SWIG_PYTHON_INTERPRETER_NO_DEBUG workaround for IfcWrap.
-- Found PythonInterp: C:\Users\bhb\Desktop\ifcos\ifcosdev\deps-vs2013-x64-installed\Python27\python.exe (found version
"2.7.10")
-- Configuring incomplete, errors occurred!
See also "C:/Users/bhb/Desktop/ifcos/ifcosdev/build-vs2013-x64/CMakeFiles/CMakeOutput.log".
See also "C:/Users/bhb/Desktop/ifcos/ifcosdev/build-vs2013-x64/CMakeFiles/CMakeError.log".

An error occurred

C:\Users\bhb\Desktop\ifcos\ifcosdev\win>

Cherry pick a subset of recent commits onto the 0.4.0 branch

This in order to do a 0.4.0-final release.

Build scripts need to be merged as well as they will be used for the build.

current master is not buildable

Hi,

when I'm trying to build, at the make command I have the following error:

Scanning dependencies of target _ifcopenshell_wrapper
[ 78%] Building CXX object ifcwrap/CMakeFiles/_ifcopenshell_wrapper.dir/IfcPythonPYTHON_wrap.cxx.o
In file included from /home/bxabi/Programs/IfcOpenShell/cmake/build/ifcwrap/IfcPythonPYTHON_wrap.cxx:3144:0:
/home/bxabi/Programs/IfcOpenShell/src/ifcwrap/../ifcgeom/IfcGeomIterator.h:89:3: error: ‘Kernel’ does not name a type
   Kernel kernel;
   ^
/home/bxabi/Programs/IfcOpenShell/src/ifcwrap/../ifcgeom/IfcGeomIterator.h:95:3: error: ‘IfcSchema’ does not name a type
   IfcSchema::IfcRepresentation::list::ptr representations;
   ^
/home/bxabi/Programs/IfcOpenShell/src/ifcwrap/../ifcgeom/IfcGeomIterator.h:96:3: error: ‘IfcSchema’ does not name a type
   IfcSchema::IfcRepresentation::list::it representation_iterator;
   ^

and many similar errors follow.

Is this happening only for me? What can cause it?

Windows build scripts: build ICU from sources

Requires svn as a prerequisite but we would get rid of 7-zip dependency. As ICU is not (IIRC) buildable as static library nor against static VC runtime out of the box on MSVC, we probably could apply/study the build scripts and patches at https://www.npcglib.org/~stathis/blog/precompiled-icu/ for help

Issues compiling IFCOS on windows for SVG Converter

Hi everyone,
As advised by Stinkfist, I'll continue explaining my issues here instead of Sourceforge. (https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/9dde835a/#9ffc )

My config : Windows 10 ; Visual Studio 14 2015 using Visual Studio 2015 x64 Native Tools Command Prompt; CMAKE v 3.4.1 and the latest code from https://github.com/IfcOpenShell/IfcOpenShell.
CMAKE started but an error occurred. Don't have a clue why and the CMakeOutput.log didnt help.
Here's the code :

C:\IfcOpenShell\IfcOpenShell\win>run-cmake "Visual Studio 14 2015 Win64"

vs-cfg.cmd: Warning: BUILD_CFG not specified - using the default RelWithDebInfo
Le système ne peut trouver le fichier BuildDepsCache-x64.txt.

Script configuration:
CMake Generator = "Visual Studio 14 2015 Win64"
All arguments = "Visual Studio 14 2015 Win64"

Dependency Environment Variables for IfcOpenShell:
BOOST_ROOT = C:\IfcOpenShell\IfcOpenShell\deps\boost
BOOST_LIBRARYDIR = C:\IfcOpenShell\IfcOpenShell\deps\boost\stage\vs2015-x64\lib
ICU_INCLUDE_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\icu\include
ICU_LIBRARY_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\icu\lib
OCC_INCLUDE_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\oce\include\oce
OCC_LIBRARY_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\oce\Win64\lib
OPENCOLLADA_INCLUDE_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\OpenCOLLADA\include\opencollada
OPENCOLLADA_LIBRARY_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\OpenCOLLADA\lib\opencollada
PYTHONPATH = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\Python34
PYTHON_INCLUDE_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\Python34\include
PYTHON_LIBRARY = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\Python34\libs\python34.lib
SWIG_DIR = C:\IfcOpenShell\IfcOpenShell\deps-vs2015-x64-installed\swigwin

CMAKE_INSTALL_PREFIX = C:\IfcOpenShell\IfcOpenShell\installed-vs2015-x64

Running CMake for IfcOpenShell.
-- The C compiler identification is MSVC 19.0.23506.0
-- The CXX compiler identification is MSVC 19.0.23506.0
-- Check for working C compiler using: Visual Studio 14 2015 Win64
-- Check for working C compiler using: Visual Studio 14 2015 Win64 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 14 2015 Win64
-- Check for working CXX compiler using: Visual Studio 14 2015 Win64 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Boost version: 1.59.0
-- Found the following Boost libraries:
-- system
-- program_options
-- regex
-- thread
-- date_time
-- Boost include files found in C:/IfcOpenShell/IfcOpenShell/deps/boost
-- Boost libraries found in C:/IfcOpenShell/IfcOpenShell/deps/boost/stage/vs2015-x64/lib
-- Looking for opencascade include files in: C:/IfcOpenShell/IfcOpenShell/deps-vs2015-x64-installed/oce/include/oce
CMake Error at CMakeLists.txt:74 (MESSAGE):
Unable to find header files, aborting

-- Configuring incomplete, errors occurred!
See also "C:/IfcOpenShell/IfcOpenShell/build-vs2015-x64/CMakeFiles/CMakeOutput.log".

An error occurred

Thank you for your help.

Sincerely,

Fred

Unicode characters in IfcConvert's XML output

I think something has changed during the past year or so regarding IfcConvert's Unicode handling. In some older files generated by IfcConvert e.g. J\X2\00E4\X0\tehuone in IFC file has resulted in J\u00e4tehuone in XML. However, in more recent XML files I'm seeing Jätehuone. Any ideas what might have changed? How does these behave for you other users?

Enable option to build Python from source in windows build script

The default now, to use the official Python.org installers, can be disruptive to users that have the same Python version already installed on their system as it uninstalls that pre-existing version. Also makes it difficult/impossible to have multiple copies of the IfcOpenShell build system on the same system. There doesn't seem to be another way to get official Python binaries (except for say portablepython and the like), so the only alternative seems to be to build from source. This is what the *nix build system does now.

@Stinkfist0 is this observation correct? thoughts?

Purpose of #define SHARED_PTR?

I was thinking of looking into OS X and/or Clang support in the near future. The codebase seems good with the exception TR1 (now part of C++11) features shared_ptr (and array) inclusion juggling between Boost, MSVC, and GCC TR1 implementations. As Boost is a mandatory requirement, all of this seems quite unnecessary. On a related noted, there would a small optimization opportunity by using make_shared for shared_ptr allocations throughout the codebase.

IFC to Max, improvments

Hi,

I am using the 3d Studio Max importer extensively and overall it works well but I would like to suggest some improvments:

   Read in “Bim” data with the ifc, a settings files that controls which data to be read.

   Create layers based on the different buildings and levels in the IFC file, (nested layers)

   Support for "Separating elements by their material layers", by using material id´s or groups.

   Support for instancing of objects instead of copies.

Some problems I have:

```
   Some entities doesn’t import.
```

   Some entities make max stop at import.

I can provide ifc files that has the problems.

Thanks,
Roger

MinGW support

Continuing discussion that originated in SF https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/45f215eb/

IfcConvert enhancements

Hi. Thought to open up a discussion of the enhancements I have made to IfcConvert in https://github.com/Tridify/IfcOpenShell-SourceForge before I start to reimplementing and cleaning up these to the new fork. Here's what I have done:

new functionality for IfcConvert (taken from the --help output):

  --names arg                     A list of names or wildcard patterns that 
                                  should be included in or excluded from the 
                                  geometrical output, depending on whether 
                                  --exclude or --include is specified. The 
                                  names are handled case-sensitively. Cannot be
                                  placed right before input file argument.
  --no-normals                    Disables computation of normals. Saves time 
                                  and file size and is useful in instances 
                                  where you're going to recompute normals for 
                                  the exported model in other modelling 
                                  application in any case.

  --use-names                     Use entity names instead of unique IDs for 
                                  naming objects and materials upon 
                                  serialization Applicable for .obj and .dae 
                                  output.
  --use-guids                     Use entity GUIDs instead of unique IDs for 
                                  naming objects upon serialization. Overrides 
                                  possible usage of --use-names for objects but
                                  not for materials.Applicable for .obj and 
                                  .dae output.
  --center-model                  Centers the models upon serialization by the 
                                  applying the center point of the scene bounds
                                  as an offset. Applicable only for .dae output
                                  currently.
  --generate-uvs                  Generates UVs by using simple box projection.
                                  Requires normals. Applicable only for .dae 
                                  output currently.

new IFCCONVERT_DOUBLE_PRECISION build option: typedef real_t either to double (ON) or to float (OFF) and use real_t throughout the IfcConvert codebase

In hindsight, --no-normals might not be that useful after all. Also while I started adding new options, I did this: https://github.com/Tridify/IfcOpenShell-SourceForge/commit/b5725e2b4703a87a03585e869e791a2cd3cfec78 Does this seem good idea to you? Also, thinking more about it, majority of the new options are not really geometry iterator settings, but serializer settings, so maybe we should add a new class or enum/field for the serializer settings that are used only in IfcConvert?

Using mmap

Hi,
I changed code in order to use mmap for file handling under linux (not tested under windows).
This should help when communicating with outside programs (bimserver for example).

I'll post the patch later ...

Regards.