When compiling ifcgemo, there are frequent linking errors What are the errors?
See https://github.com/IfcOpenShell/IfcOpenShell/discussions/6782#discussioncomment-13386978
A profile in IFC is actually always 2d. This is not very apparent in the schema because the cartesian point can be 2d or 3d. But this is enforced in WR1 https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcArbitraryClosedProfileDef.htm#8.15.3.1.4-Formal-propositions If you run python -m ifcopenshell.validate (install the ifcopenshell python module) on your file it will check the where rules for you.
You have a couple more parameters in addExtrudedPolyline. Use the extrusion placement to rotate and supply a direction to extrude not along local Z (see image). Also, the following is not allowed per rule PlacementForShapeRepresentation so use the object position to move the roof in the correct position. https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcProduct.htm 0,//file.addLocalPlacement(0, 0, 0, 0, x, y, z), file.addExtrudedPolyline(item.m_points, 100),
The major problem with IFC is that the schema is very extensive and support for the less mainstream entities can vary greatly between implementations. I would recommend against trying to get centerline profiles to work. Rather, use a composite curve with the explicit segments. Personally I also think that center line profiledef is not specified precisely enough for implementations to handle it correctly. I also don't think its useful enough because in case of wall joins you would still either need...
Additional meta-data can be supplied in property sets, have a look at ifcopenshell.util.element.get_psets() but it depends on the model. Computation using your own code can be more robust, consistent and according to the norms and computation method of choice.
Hi, thanks for reporting. There are some self-intersection in the profile (see attachment). That should generally be handled, but some bits and pieces were still missing in the transition from v0.7 to v0.8. I'll commit some code changes this evening to get things to convert properly again. Thomas
I know this does not really count as documentation, but Bonsai makes quite some use of it and if you search by the operator names you might be able to mentally reconstruct some of its usage patterns. All help welcome in augmenting documentation :) Might have more luck posting issues at https://github.com/IfcOpenShell/IfcOpenShell/issues src\bonsai\bonsai\bim\module\bcf\operator.py: 54,5: bl_label = "New BCF Project" 69,5: bl_label = "Load BCF Project" 118,5: bl_label = "Unload BCF Project" 128,5:...
Hi, this is not really a question regarding ifcopenshell, but more pythonocc. Maybe isolate the inputs of your boolean op and ask the question https://github.com/tpaviot/pythonocc-core/issues or https://dev.opencascade.org/forums It might help to explicitly calculate in 2d. If this is the vertical face and a horizontal line. Reduce the face to a 2d line segment. Calculate the intersection yourself or use one of the occt apis.
I think what might be happening is that there is a large offset somewhere so the coordinates in the .obj are large / far away from origin. This causes issues in software that uses less precision. You might want to try running ifcconvert with --building-local-placment to ignore transformations in the spatial hierarchy from building and upwards where usually such large offsets are introduced.
Have a look at ifcpatch with the ExtractElements recipe. https://docs.ifcopenshell.org/autoapi/ifcpatch/recipes/ExtractElements/index.html#module-ifcpatch.recipes.ExtractElements
load specific elements by their GUID into the iterator? I saw, one could filter elements like 'IFCWALL' etc., but by guid..? include= excepts either a list of strings in which case it is assumed to be entity types. You can also pass a list of ifcopenshell.entity_instance (that you obtained with file.by_guid).
https://github.com/IfcOpenShell/IfcOpenShell/issues/4287#issuecomment-1925241676
The setting you're looking for is DISABLE_TRIANGULATION. If you use ifcopenshell.geom.iterator you can also call get_native() regardless of the setting. Btw. we're working on a much more powerful tree implementations. https://github.com/IfcOpenShell/IfcOpenShell/pull/4374 that will eventually also greatly speed up ray intersections. Currently ray intersections are still a bit brute force on the tree. Nothing concrete to show yet, but in a couple of weeks something might be ready.
https://github.com/IfcOpenShell/IfcOpenShell/discussions/4341#discussioncomment-8529993
Material is not a Property Set, but an Association. for rel in inst.HasAssociations: if rel.is_a('IfcRelAssociatesMaterial'): rel.RelatingMaterial
The attribute order is different: ENTITY IfcExtendedMaterialProperties; ENTITY IfcMaterialProperties; Material : IfcMaterial; ENTITY IfcExtendedMaterialProperties; ExtendedProperties : SET [1:?] OF IfcProperty; Description : OPTIONAL IfcText; Name : IfcLabel; END_ENTITY; https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcmaterialpropertyresource/lexical/ifcextendedmaterialproperties.htm
I think what you're looking for is IfcExtendedMaterialProperties in IFC2X3.
There exist three pset templates ./src/ifcopenshell-python/ifcopenshell/util/schema/Pset_IFC2X3.ifc ./src/ifcopenshell-python/ifcopenshell/util/schema/Pset_IFC4X3.ifc ./src/ifcopenshell-python/ifcopenshell/util/schema/Pset_IFC4_ADD2.ifc I thought that with the latest schema handling changes IFC4X3 will be used for all revisions of IFC4X3 including _TC1. This might be a fairly recent change. Could you update and if issue persists report at https://github.com/IfcOpenShell/IfcOpenShell/issues
Yes, but that's on failing to install mathutils, apparently nobody seemed to bother to fix that https://github.com/IfcOpenShell/IfcOpenShell/actions/runs/6150871394/job/16689762612#step:6:158 All help welcome :)
You're right should be fixed as of https://github.com/IfcOpenShell/IfcOpenShell/commit/7541293a3c06fff31b9ebf8502bdb49f9ee04bd1
All help is welcome on this front :)
Have a look at https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/project/append_asset.py and https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcpatch/ifcpatch/recipes/ExtractElements.py
Instead of ifcopenshell.geom.create_shape() you better use ifcopenshell.geom.iterate(). That way there is a global context to share and cache shared representation of various elements, which sounds like in your case it could speed up the runtime quite dramatically. Other than that, IFC allows for some pretty computationally expensive geometric forms.
See https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/util/shape.py#L155
See below. You have to actually pass the schema identifier to the file being created. import ifcopenshell from ifcopenshell.api import run # Create a blank model model = ifcopenshell.file(schema="IFC4x3") # Create Spatial Structure project = run("root.create_entity", model, ifc_class="IfcProject", name="Spatial Structure Trial") site = run("root.create_entity", model, ifc_class="ifcSite", name="TrialSite") facility = run("root.create_entity", model, ifc_class="ifcMarineFacility", name="OpenPort")...
Currently no such thing exist. Help is always welcome :) https://github.com/IfcOpenShell/IfcOpenShell/issues/203
It appears you are correct that the deletion of those two files only happens when the serializer object is being destructed https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/serializers/GltfSerializer.cpp#L60-L61 This can be accomplished with del sr in Python, although strictly speaking you never actually know in Python when the object actually gets freed. You might have to add import gc; gc.collect(). The actual result file is a member object of the class https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/serializers/GltfSerializer.cpp#L52...
Because you've added: with_progress=True You get return a pair of progress as integer and the currently processed elem. So either change to with_progress=False or to for progress, elem in ifcopenshell.geom.iterate(
Judging by the information you give us I'd be tempted to think it is related to binary vs text streams. If you open the outputs in text mode \r\n characters will get mapped to \n causing the chunks to no longer align. By random chance with binary floating pointing point numbers you're likely to have a couple of \r\n sequences.
Yes. import ifcopenshell.geom ifcopenshell.geom.serializers.gltf Combine with ifcopenshell.geom.iterator and call .write().
Combine ifcopenshell.geom.iterator and ifcopenshell.geom.serializers.obj. Search around for working code examples.
No, we currently don't have any explicit control over the output unit in the STP serializer. The only option I see now is indeed to use --convert-back-units but first patch the input file to have the unit you need in Python. Something like below might help, it's untested. import sys, ifcopenshell ifn, ofn = sys.argv[1:] # load input model f = ifcopenshell.open(ifn) # create empty output model g = ifcopenshell.file(schema=f.schema) # add the project (recursively adds units) g.add(f.by_type('IfcProject')[0])...
No, we currently don't have any explicit control over the output unit in the STP serializer. The only option I see now is indeed to use --convert-back-units but first patch the input file to have the unit you need in Python. Something like below might help, it's untested. import sys ifn, ofn = sys.argv[1:] # load input model f = ifcopenshell.open(ifn) # create empty output model g = ifcopenshell.file(schema=f.schema) # add the project (recursively adds units) g.add(f.by_type('IfcProject')[0]) # remove...
Still exists in the code https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcconvert/IfcConvert.cpp#L437 What do you mean precisely?
What you're looking at is an objectified relationships. It's an actual entity instance that sits in the middle of chair and space. IfcFurniture <- IfcRelContainedInSpatialStructure -> IfcSpace The inverse attribute from furniture to this relationship is called ContainedInStructure. So: chair.ContainedInStructure[0].RelatingStructure
TranslationPart of ObjectPlacement are not vertices, but rather the geometric "insertion point" of elements in world coordinate space. Instead use IfcGeom::Iterator to actual create TopoDS_Shape(s) (include DISABLE_TRIANGULATION in your IteratorSettings so that you get opencascade shapes) of the elements and iterate over those vertices (TopExp_Explorer TopAbs_VERTEX). But rather, if you use alpha shapes, vertices isn't that good either, better sample the underlying surfaces of the faces (TopExp_Explorer...
Do you have a minimal sample of what your approach exactly looks like?
It needs to be defined as in my previous post with parenthesis https://sourceforge.net/p/ifcopenshell/discussion/1782716/thread/69255b3a96/?limit=25#e981/c5c6/f635/cab7 I.e a boost preprocessor sequence https://www.boost.org/doc/libs/1_74_0/libs/preprocessor/doc/ref/seq_for_each.html
You do have to specify in cmake (or in your cpp file #define SCHEMA_VERSIONS=(2x3)(4). IfcOpenShell does not have a kind of plug-in architecture yet. It still depends on a explicit listing of supported schemas at compile time (of ifcopenshell itself or other client-side applications).
See See https://sourceforge.net/p/ifcopenshell/discussion/1782716/thread/0e2a360e58/?limit=25#78a4 IfcGeom.h should typically not be included directly in end-user code as it provides a schema-dependent interface. It's built multiple times within IfcOpenShell for the various schemas. https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/cmake/CMakeLists.txt#L792-L798 Generally in your own code include only ifcgeom_schema_agnostic/Iterator.h
With all the machinery to supply multiple schema versions at runtime, it hasn't become easier to build 3rd party C++ apps using IfcOpenShell. If you have ideas on on streamlining/documenting this process we'd be happy to hear your feedback. You're missing the defines set here: https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/cmake/CMakeLists.txt#L648-L662
This is a regular python error. You can subtract from a tuple, but you can concatenate (+). Also properties don't have any strong identity regarding their name, so even if you could subtract like that, it's not that a new property with the same name is equal to an existing property in the list in the sense that you can remove it. How about: property_set.HasProperties = tuple(p for p in property_set.HasProperties if p.Name != NAME_TO_DELETE) Also a general note. If you would do: for p in ifc.by_type('IfcPropertySingleValue'):...
https://github.com/IfcOpenShell/IfcOpenShell/issues/1559
You forgot to clone with --recursive, do git submodule update --init --recursive.
In your win folder there is a file named BuildDepsCache-x64.txt probably something went wrong there.
It has a similar approach indeed. Once you get it to work would be great if you can send in a Pull Request on github
Ok, so can you print the output of these commands: powershell -c "get-content .\patches\mpir.patch" powershell -c "get-content .\patches\mpir.patch | %{$_ -replace \"sdk\",\"%UCRTVersion%\"}" powershell -c "get-content .\patches\mpir.patch | %{$_ -replace \"sdk\",\"%UCRTVersion%\"} | %{$_ -replace \"fn\",\"lib_mpir_cxx\"}"" from this directory in the CMD shell C:\Program Files\IfcOpenShell-0.7.0\_deps And when I type this, I highly suspect it could be because of the space in "Program Files". So maybe...
From what I see product should be a singular item. That's just how the API is structured, but that doesn't mean that in the end-result it wouldn't be grouping the relationships. https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/pset/add_pset.py#L30 So I would recommend creating a for-loop over the instances you want to relate? Does that answer the question? I didn't understand it in full.
From what I see product should be a singular item. That's just how the API is structured, but that doesn't mean that in the end-result it wouldn't be grouping the relationships. https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/pset/add_pset.py#L30 So I would recommend creating a for-loop over the instances you want to relate? Does that answer the question? I didn't understand it in full.
Try ./IfcConvert when running from the directory containing the executable. In most linux configurations the current directory is not included in the "path". As opposed to Windows.
ifc thing is pretty new for me so I have to start from the bottom I hear you. Also IfcXML is an additional piece of confusion, because it's hardly used, there are two dialects (for ifc2x3 and ifc4) and the ifc4 dialect even though required, is nowhere really implemented. Actually IfcOpenShell only implements IfcXML reading. So if I were you. I would split the problem into the different tasks. A conceptual task first of how to map concepts from isybau to IFC (this may also need to be split into different...
That is essentially what happens here https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/geom/occ_utils.py#L108
Solved in https://github.com/IfcOpenShell/IfcOpenShell/issues/2494
The IfcOpenBot builds still succeed. They run the exact same build script. I would advise to disect what's going on in the build script and invoke the steps manually. My guess is the error is about this line. https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/win/build-deps.cmd#L205 We'd just need to figure out then why there are no valid patches in the input. Maybe related to the version or availability of powershell.
The IsDecomposedBy inverse attribute you show in your images is actually simply an instances of IfcRelAggregates https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/ifckernel/lexical/ifcrelaggregates.htm
Yes, this is a known issue. Unfortunately the script fails with even with older versions of vs when 2022 is installed. https://github.com/IfcOpenShell/IfcOpenShell/issues/1993 https://github.com/IfcOpenShell/IfcOpenShell/issues/2070
Tbh I think this is a fairly difficult undertaking. Good news is that we have access to the ifcopenshell serializers from python as ifcopenshell.geom.serializers, bad news is that STP and IGS have never been added there (because of lack of interest probably) But even then, it would allows for some control over what is being serialized, but not to the extent that you can tweak colors. What I'd suggest is reading the OCCT guide [0] wrt to their step writer (that's what we use for the serializer) and...
In it's simplest form you can do something like: f = ifcopenshell.open(...) g = ifcopenshell.file(schema=f.schema) h = ifcopenshell.file(schema=f.schema) g.add(f.by_type('IfcProject')[0]) h.add(f.by_type('IfcProject')[0]) g.add(f.by_type('IfcWall')[0]) h.add(f.by_type('IfcSlab')[0]) g.write('wall.ifc') h.write('slab.ifc') But there's a couple of caveats due to the complex graph nature of IFC. You'd probably better look into IfcPatch with the ExtractElements recipe or the append_asset higher level...
At the very bottom there is PythonOCC code for calculating volume https://academy.ifcopenshell.org/posts/using-ifcopenshell-and-pythonocc-to-construct-new-geometry/ off of IFC element shapes provided by ifcopenshell
ifcopenshell.entity_instance.entity_instance will return their attribute values by name, so: >>> inst #5384=IfcMaterial('Metall, Aluminium',$,$) >>> inst.Name Metall, Aluminium See here for the attribute names http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcMaterial.htm#8.10.3.1.3-Attributes
with [0] we are just calling on the PSet from the first available type Sure, it was just an example. Most straightforward is to just loop over the elemens that can have the pset assigned and check the IsDefinedBy inverse attribute that will point to the IfcRelDefinesByProperties relationship nodes ( or also IfcRelDefinesByType in ifc2x3 )
Ok, understand the problem a bit better now. You can copy over a pset just fine (e.g new_file.add(old_file.by_type('IfcPropertySet')[0])). But you shouldn't do this with the relationships because they are one-to-many (calling add() on the relationship would also add all related elements to the new file). So for the relationships just do new_file.createIfcRelDefinesByProperties(...). Does that help?
ifcopenshell.util.element.get_psets() should get you a long way
Definitely. blenderbim.org/ has been built on top of ifcopenshell, here's another quick example in python https://academy.ifcopenshell.org/posts/creating-a-simple-wall-with-property-set-and-quantity-information/ There's also several open and closed source CAD/BIM tools that implement IFC export support using IfcOpenShell C++.
Edit: for fun, if you take the string you reported and strip out the \U you can recover the value your after: >>> s = "007700530070006500530074006c006f00640069" >>> chars = [chr(int(s[i:i+2], 16)) for i in range(2, len(s), 4)] >>> "".join(map(lambda t: "".join(t), zip(chars[1::2], chars[::2]))) 'SweptSolid'
With python 2.7 you need to be careful to select the 2.7 or 2.7u. You have the wrong version. Before version 3.3 python had a compile time setting to use either 16bit or 32bit fixed unicode code points. For 0.6 we still provide both variants, for 0.7 we don't provide builds anymore for 2.7 because it's eol. https://github.com/IfcOpenBot/IfcOpenShell/commit/721fe4729aa5302efe1602971aae2558934ad098#comments
No worries :) I was travelling otherwise I would have responded earlier The entity creation you're referring to is automatically generated from the schema so has no missing parts. DIfferences between schemas can indeed be confusing.
I think this is the most recent instructions for that https://github.com/IfcOpenShell/IfcOpenShell/issues/2256#issuecomment-1174955939
The bSI certification process is being changed. My advise is to give it a couple months for public statements around this to appear.
More up to date python docs are currently on the bbim website https://blenderbim.org/docs-python/autoapi/ifcopenshell/util/index.html?highlight=util#module-ifcopenshell.util
If you write your schema changes into an Express file then you can use IfcOpenShell to read and write files according to that schema. In C++ you have to do code generation. In Python you can directly interface with the parsed schema (latebound) using the various tools in ifcopenshell.express. There are limitations though wrt to latebound handling and geometry interpretation because that needs early bound code generation. I must say though that IFC is extensible in itself, user defined ObjectTypes...
Actually, IfcSweptDiskSolidPolygonal is simply not implemented and handled as the parent type IfcSweptDiskSolid which doesn't have this attribute. Can you open an issue here https://github.com/IfcOpenShell/IfcOpenShell/issues so that it's a little bit more easily tracked in conjunction with the code changes. It's a not a lot of work to add - although the filleting is a bit inconvenient potentially because the occt api requires filleted vertices to be on a face (if I'm not mistaken) and one needs...
The stories are then: bldgs.IsDecomposedBy[0].RelatedObjects For the other information have a look at the direct attributes such as Elevation and e.g ifcopenshell.util.element.get_psets()
Hi, This doesn't seem to be a problem with IfcOpenShell. I checked two other free viewers (Solibri and BimVision) and they had similar (or worse problems). Better try and pick this up with Autodesk and use the latest version of the ifc exporter. Kind regards, Thomas
The BRep hierarchy is Solid > Shell > Face > Wire > Edge > Vertex Each higher level entity can have one or more of the entity underneath. Generally in OCCT the collection is unordered. Use BRepTools::Outerwire to get outer wire of face, the other wires (if any) are all interior wires, so you can use TopoDS_Iterator. Use BRepTools_WireExplorer to iterate the edges in order over a (closed!) wire.
If you use OCC, you can pass Bnd_Box and gp_Pnt or TopoDS_Shape to the containment queries. The tree is always in meter (as is the geometry returned from ifcopenshell by default). Have a look at the various OCC constructs such as TopExp_Explorer to extract vertices and associated points. Or look at the IfcBuildingStorey Elevation attribute (but remember to apply unit conversion)
I think that would have worked for USE_PYTHON_OPENCASCADE, but for USE_BREP_DATA you need an additional .brep_data. mywall.Representation = ifcopenshell.geom.tesselate(f.schema, shape.geometry.brep_data, 1.e-3)
There's two things to change: create_shape() returns an object depending on type of settings, but not the python occ or occt shape serialization directly. Use shape.geometry. The settings are configured to return a mesh. Use ifcopenshell.geom.settings(USE_PYTHON_OPENCASCADE=True) if installed or USE_BREP_DATA (occt string serialization).
You can use ifcopenshell.geom.serialize or ifcopenshell.geom.tesselate they return a IfcProductDefinitionShape
IfcConvert is a command line executable. It doesn't have a GUI (graphical user interface). To experiment it's easiest if you create one folder on your hard drive with some IFC files and IfcConvert.exe Open your Windows Command Prompt and go to that directory. One quick trick is in Windows Explorer type cmd in the directory path textedit box (the bar with This PC > Documents > ... - click on the right side to turn it into a textbox) Assuming your IFC file is named house.ifc you can then type something...
There is a whole classification API group https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/classification/add_classification.py Note that some tools will duplicate classification data into properties, but there is a dedicated construct in the schema. IfcClassification(Reference) and IfcRelAssociatesClassification
Are you talking about pythonOCC? https://github.com/tpaviot/pythonocc-core/ They are primarily using (ana)conda, so I'd set that up. I recommend miniconda. You can also install pyqt using that. Then select that interpreter to use in pycharm.
open() expects the filename on disk as a python str not bytes. If you have file content there is ifcopenshell.file.from_string() but it also expects a string so use ifcopenshell.file.from_string(ifcfile.read().decode('ascii'))
Can you share the file? You can probably set INCLUDE_CURVES to True in your settings in case the representation is purely linework, but it shouldn't crash regardless of the content.
Oops sorry, it's on IfcElement the subtype of IfcProduct.
You'd need to write a python script. Import the igs with PythonOCC and ifcopenshell.geom.serialize() the data to IFC using IfcOpenShell. Note that quite a bit of additional semantic content is required to obtain a valid and idiomatic IFC file (e.g certain types of entities such as IfcWall typically have multiple representations Body and Axis.) You can get an empty ifc file to which you can append your geometric data with ifcopenshell.template.create().
You'd need to write a python script. Import the igs with PythonOCC and ifcopenshell.geom.serialize() the data to IFC using IfcOpenShell. Note that quite a bit of additional semantic content is required to obtain a valid and idiomatic IFC file (e.g certain types of entities such as IfcWall typically have multiple representations Body and Axis.) You can get an empty ifc file to which you can append your data with ifcopenshell.template.create().
quick and easy way Yes and no, there isn't a designated API for it in IfcOpenShell, but using the product->HasOpenings() inverse attribute in the schema will give you a bunch of IfcRelVoidsElement with the RelatedOpeningElement() attribute. That will give you the IfcOpeningElements which are just products themselves so you can use convert() on them.
I got a notification about a reply I don't see online now anymore. Maybe it's already solved. The 2nd line below doesn't do anything: IfcGeom::IteratorSettings settings; settings.DISABLE_OPENING_SUBTRACTIONS; It's just a constant, equivalent to writing something like: 5; Use IfcGeom::IteratorSettings settings; settings.set(settings.DISABLE_OPENING_SUBTRACTIONS, true);
It does. Either you're not propagating the settings correctly or what you're seeing is not an opening but an IfcBooleanResult or just baked into the geometry altogether.
geometry()->as_compound()
Please use a recent version, https://github.com/IfcOpenBot/IfcOpenShell/commit/1b1fd1e6c5777cb27ca3a65357855421a8e77bf9#comments The website should be updated.
See here for example https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcwrap/IfcGeomWrapper.i#L459
From earlier discussion I remember you are using convert(IfcRepresentationItem*). In that way IfcOpenShell cannot know which openings are to be applied. You have to use the convert(IfcProduct*) alternative because that's where the information on representation items, global placement, openings (and materials...) comes together. https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/bf6522b1cd/?limit=25#ab52
sure just find another way to input the input and output filename in the script
Not sure what precisely you are after, are you looking to update an existing IFC file, modify an application or configure the output of IfcConvert for example. For IfcConvert there is the options --use-element-name or --use-element-guid If you'd like to postprocess an IFC file, you could do sth like this in python: import sys import ifcopenshell ifn, ofn = sys.argv[1:] f = ifcopenshell.open(ifn) for elem in f.by_type("IfcObjectDefinition"): elem.Name = elem.GlobalId f.write(ofn) But the reverse is...
Yes, the way how filtering works from the command line is very limited and has confusing defaults. The default for IfcSpace is include entities ={IfcSpace} and when you say included/excuded entities = something else, that defaults get overwritten, but not when you include by attribute. That makes sense in the case of the 3D formats, if you select a single building storey you probably still want the default entity filter to be in place. But in this case it's confusing. Note that you don't need to...
In the core of ifcopenshell (C++) there is no support, but you can have a look at how support for ifcjson is implemented in blenderbim for example by just leveraging the existing ifcjson implementation from Jan Brouwer (which in turn uses IfcOpenShell again) https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/blenderbim/blenderbim/bim/export_ifc.py#L64
return a shape at a relative location, not an absolute one Ok, it indeed depends on how you structure your code. I'm a bit lost in the discussion. fails without error Then there is probably an exception somewhere. How do you run your code? If you use a IDE such as MS Visual Studio you should be able to run in debug mode and see where the error occurs. Or if you use Linux you can use gdb. Otherwise it's near impossible to see the issue from these isolated lines of code. get a gp_Trsf from this local...