Return independent geometry copies with unique ownership, preserve parent lifetimes, and teach the Python wrapper to own derived results. Keep serializer inputs non-owning and replace Collada's deferred object with copied triangulation elements.\n\nGenerated with the assistance of an AI coding tool.
The optional adaptor element list was never assigned, so simplify IfcConvert to use its geometry iterator unconditionally.
Generated with the assistance of an AI coding tool.
Rename header-scope aliases, enums, and helper types while retaining descriptive names where dropping the suffix would create a collision.
Generated with the assistance of an AI coding tool.
Update the stale pointer-form example and pass the IFC file required by the current serialization API.
Generated with the assistance of an AI coding tool.
Apply the rename manifest, normalize serializer filenames to the classes they define, and update includes and CMake source lists.
Generated with the assistance of an AI coding tool.
To fix wrapper depending on `ifcopenshell.geometry.kernel.opencascade.so` plugin, which breaks wasm module import (wrapper imported first and it fails because occt kernel isn't loaded yet and loading kernel first since it needs some symbols from the wrapper).
`geometry_serializer` seems to need `OpenCascadeConversionResult.h` from the kernel just to be able to refer to structs (`ConversionResultShape`, `OpenCascadeShape`) and include with relative path already allows it.
Produces errors in wasm builds - we want to be able to load the wrapper first and all other dependencies should be pluggable. But loading wrapper first failed, because it depended on the kernels. Loading kernels first would also fail, since OCCT kernel is using using some symbols from core (`ifcopenshell::exception`) and in wasm they have to be resolved all during `dlopen`.
rocks_db_file_storage already exposes a `g|`-prefixed guid -> instance
name map, but RocksDbSerializer never populated it, so by_guid() on a
converted file always threw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
entity_instance.file is a property backed by a fresh SWIG wrapper on every
access, and ifcopenshell::file had no __eq__, so `self.file != other.file`
in entity_instance.__eq__ compared two throwaway wrappers and was always
true - even for an instance against itself. Every entity comparison
therefore took the deep get_info() branch, making distinct but structurally
identical instances compare equal and leaving the final `return False`
unreachable. Bonsai's TestAddRepresentationItemToShapeAspect showed this as
two separate IfcShapeAspects being treated as one, so the stale aspect was
never removed.
Restore the file_pointer() pair that was commented out on both
ifcopenshell::file and express::Base - IfcParseWrapper.i already described
it as the way to "trace file ownership of instances on the python side" -
and give file the __eq__/__hash__ it was missing. The express::Base one
needs $self->file() now that file_ lives on instance_data. This also
repairs rocksdb_lazy_instance.__eq__, which already called file_pointer().
EXPRESS `=` is value comparison and `:=:` is instance comparison, but
rule_compiler emits `==` for both (see the @todo on process_rel_op), and
derived attributes build their operands in the shared global file, so rules
compare same-file instances and need value semantics. Restore those for the
duration of rule execution with settings.compare_instances_by_value,
alongside the existing unpack_non_aggregate_inverses.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
As we're not currently bundling dlls for all other external dependencies.
It seems `--shared`in CI previously worked sort of by accident - since it was relying on the cached build outputs that were previously built statically.
Caused errors like so:
```
Traceback (most recent call last):
File "/__w/IfcOpenShell/IfcOpenShell/build/Linux/x86_64/install/python-3.13.6/lib/python3.13/site-packages/ifcopenshell/__init__.py", line 87, in <module>
from . import ifcopenshell_wrapper
File "/__w/IfcOpenShell/IfcOpenShell/build/Linux/x86_64/install/python-3.13.6/lib/python3.13/site-packages/ifcopenshell/ifcopenshell_wrapper.py", line 10, in <module>
from . import _ifcopenshell_wrapper
ImportError: libifcopenshell.geometry.writer.so: cannot open shared object file: No such file or directory
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<string>", line 1, in <module>
import inspect, ifcopenshell; print(inspect.getfile(ifcopenshell))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/__w/IfcOpenShell/IfcOpenShell/build/Linux/x86_64/install/python-3.13.6/lib/python3.13/site-packages/ifcopenshell/__init__.py", line 89, in <module>
raise ImportError("IfcOpenShell not built for '%s' (%s)" % (python_distribution, e)) from e
ImportError: IfcOpenShell not built for 'linux/64bit/python3.13' (libifcopenshell.geometry.writer.so: cannot open shared object file: No such file or directory)
```
Level of Effort activities were skipped outright. They are now imported as
IfcTask with PredefinedType ATTENDANCE, the nearest thing IFC has to support
work that spans what it hangs off. Their dates stay derivable: the SS/FS and FF
predecessors P6 computes the span from are ordinary relationships and are
written out like any other. Skipping them also dropped 970 relationships that
happened to touch one.
User defined fields and activity codes now land as P6_UDF and
P6_ActivityCodes property sets. Separate sets because they are separate
concepts in P6, and not IfcClassificationReference for the codes because they
are orthogonal facets rather than a hierarchy. A code's description goes on
IfcProperty.Description so the short value and the readable one both survive.
UDF types come from the root declarations, since that is the only place the
data type is known, and are written sparsely.
Task times are now transcribed rather than recalculated. edit_task_time exists
to keep a schedule self-consistent while somebody edits it, so it snaps dates
off non-working days and derives durations across the calendar: reasonable for
an editor, wrong for a transcription where P6 has already run the critical path
and its answer is authoritative. On one 4,181 activity programme it moved 3,534
start dates and disagreed with P6's own duration on 3,206 activities. Actual
dates, early and late dates, float and completion are now carried too, none of
which were written before.
WBS children are created in P6's SequenceNumber order rather than document
order. IfcRelNests keeps an ordered list, so this is all it takes for a reader
to recover the breakdown as the planner arranged it, and sorting any other way
shows a programme nobody recognises.
Also: the project name was read without the namespace map, so every schedule
came out called "Unnamed".
I previously incorrectly believed that sequence types are mutually exclusive. E.g. you can have max 1 relationship between two tasks. Now after looking at more schedules I realise it's logically allowed to have more than one sequence relationship. For example simultaneous SS + FF.
The recipe loaded the model into Blender purely to reach its geometry
engine, so it could only run inside Bonsai and needed a filepath instead
of a file. It is now a plain BasePatcher.
The three fixes Revit needs are unchanged. To lower each space onto its
storey we take the storey elevation from util.placement and the space
placement from util.shape, instead of from Blender object matrices. To
convert to an extruded area solid we triangulate the space with
ifcopenshell.geom, union its downwards facing triangles with shapely to
get the footprint and its voids, and rebuild the body with
util.shape_builder.
Unioning every downwards facing face, rather than only the vertices
sitting at z=0, means stepped and clipped spaces keep their full
footprint, columns poking through a room become profile voids, and
disjoint footprints extrude as one item each. Spaces that cannot be
patched are logged and skipped rather than aborting the run, and a
storey above the top of a space falls back to the space's own height
instead of asking for a negative extrusion depth.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Thomas Krijnen