Autodesk / Autodesk/revit-ifc

PR: 2nd Level Space Boundary ConnectionGeometry displaced from corresponding IfcSpace

Open
#961 1 comment 0 reactions 0 assignees View on GitHub
problem
Dominant language
C#
Stars
638
Forks
226
PR merge metrics
No merged PRs in 30d

Description

### Problem Description

[PR] 2nd Level Space Boundary ConnectionGeometry displaced from corresponding IfcSpace


Problem Description


When exporting IFC4 with 2nd level space boundaries (SpaceBoundaries = 2), the ConnectionGeometry of IfcRelSpaceBoundary2ndLevel entities is positioned incorrectly. The IfcCurveBoundedPlane surfaces are displaced several meters from their corresponding IfcSpace geometry, making them unusable for energy simulation (BEM) workflows.


The boundary surfaces should be coplanar with the inner faces of the bounding walls, but instead they appear shifted by ~4–6 meters in XY.


Environment



  • Revit version: Revit 2025 (FRA)

  • IFC exporter version: shipped with Revit 2025

  • IFC schema: IFC4

  • MVD: DesignTransferView_V1.0

  • Export settings: Space Boundaries = 2nd Level


Steps to Reproduce



  1. Create a simple Revit model with 2–3 rooms bounded by walls on a single storey.

  2. Export to IFC4 with SpaceBoundaries = 2 (2nd Level).

  3. Open the IFC file in an IFC viewer (tested with KIT IFC ModelViewer / IfcOpenShell).

  4. Inspect the IfcRelSpaceBoundary2ndLevel surfaces relative to their IfcSpace volumes.


Observed Behavior


The ConnectionGeometry (IfcCurveBoundedPlane) plane origins in the IfcRelSpaceBoundary2ndLevel entities are displaced from the actual wall inner face positions. The boundaries appear as a group of surfaces shifted to one side, completely detached from the space geometry.


Expected Behavior


The ConnectionGeometry surfaces should be coplanar with the inner faces of the bounding elements (walls, slabs, roof), correctly positioned relative to the IfcSpace they describe.


Detailed Analysis


Test model geometry


The model contains two adjacent rooms on storey "Niveau 0" (elevation 0.0), each 3m high:

Space | Name | Placement (storey coords) | Shape
-- | -- | -- | --
#80 | Pièce 2 | (-19.205, -1.459, 0) | L-shaped, ~6.1m × 5.6m
#237 | Pièce 3 | (-15.377, -1.459, 0) | Rectangle, 2.3m × 2.8m

This proves the boundary coordinates are neither in a consistent global coordinate system nor in the space-local coordinate system.


Consistent offset from wall center lines


The boundary plane origins are displaced from the wall center lines by a consistent per-space offset:



  • Space #80: approximately (+5.854, +0.445, 0) from wall centers

  • Space #237: approximately (+4.667, +0.345, 0) from wall centers


The ±0.1 variation around these values corresponds exactly to the half-thickness of the bounding walls (0.2m exterior walls → ±0.1m, 0.04m internal walls → ±0.02m).


Root Cause Analysis (from source code)


In SpatialElementExporter.cs, the function ExportSpatialElement2ndLevel retrieves boundary surfaces from the Revit EnergyAnalysisDetailModel API:


EnergyAnalysisDetailModelOptions options = new EnergyAnalysisDetailModelOptions();

options.Tier = EnergyAnalysisDetailModelTier.SecondLevelBoundaries;

The polyloop points from EnergyAnalysisSurface.GetPolyloops() are returned in Revit internal project coordinates. The code then transforms them using:


static IFCAnyHandle CreateConnectionSurfaceGeometry(

ExporterIFC exporterIFC, EnergyAnalysisSurface surface,
IList<EnergyAnalysisOpening> openings, XYZ offset)
{
// ...
foreach (XYZ point in outerLoopPoints)
{
newOuterLoopPoints.Add(UnitUtil.ScaleLength(point.Subtract(offset)));
}
// ...
}

The offset subtracted from the polyloop points should transform them from Revit internal coordinates to the IfcSpace's local coordinate system (as defined by its ObjectPlacement / PlacementSetter).


The bug is that the offset value does not correctly account for the full XY placement of the IfcSpace. It appears to only account for the Z-offset (level elevation + room lower offset), but not the XY translation established by the PlacementSetter. This causes the boundary surfaces to be displaced in X and Y by an amount related to the space's position.


Suggested Fix


In ExportSpatialElement2ndLevel, the offset passed to CreateConnectionSurfaceGeometry should include the full 3D translation from the PlacementSetter (or equivalently, the space's ObjectPlacement origin relative to the storey). This would correctly transform the EnergyAnalysis polyloop coordinates from Revit internal coordinates to the IfcSpace local coordinate system.


Something like:


// Current (incomplete - only Z offset):

XYZ offset = new XYZ(0, 0, levelElevation + bottomOffset);

// Should include the full space placement transform:
XYZ spacePlacement = setter.GetLocalPlacementOrigin(); // or equivalent
XYZ offset = spacePlacement; // full XYZ transform to space-local


Impact


This bug makes 2nd level space boundaries (IfcRelSpaceBoundary2ndLevel) unusable for:



  • Building Energy Modeling (BEM) workflows

  • Thermal simulation tools that rely on accurate boundary geometry

  • Any IFC-based analysis requiring correct space-to-element face relationships


Attached Files


A minimal IFC test file demonstrating the issue can be provided on request. The model contains 2 rooms, 6 walls (4 exterior + 2 internal), with 16 IfcRelSpaceBoundary2ndLevel entities all exhibiting the displacement.

### Revit Version

2025.4.x

### IFC for Revit Addon Version

25.4.4

### Windows Version

11 25H2

Contributor guide

Open the contributing guide

Research direction

Start in SpatialElementExporter.cs at ExportSpatialElement2ndLevel and trace the offset passed to CreateConnectionSurfaceGeometry, comparing it with the IfcSpace placement established by PlacementSetter. Reproduce the IFC4, second-level-boundary export described in the issue and inspect the IfcRelSpaceBoundary2ndLevel planes; done means they are coplanar with the corresponding IfcSpace bounding faces.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.