I’m attempting to create beams which represent a cross section swept along a path. To do this, I’m using IfcSurfaceCurveSweptAreaSolid. The correct result should look like this:
The actual results can be seen below. On the left is ArchiCAD’s interpretation where both beams have their cross section rotated incorrectly. On the right is Solibri where the sweep along the polygon path has its cross section correctly rotated, while the linear beam’s cross section is incorrect.
In both cases, a reference surface is created which is a vertical extrude of the centerline of the beam. So according to the spec, the profiles should both be turned so that their local X axis is normal to that surface. Is this just a matter of incomplete/inconsistent vendor implementation of the spec, or is there more that I need to do to define the direction of the cross section profile?
UPDATE:
I’ve added a beam based on an arc using the same strategy, and Solibri gives a wonky result. I would expect the cross section profile to be either vertical (local X normal to the reference surface), or horizontal (local X perpendicular to the reference surface), but certainly not tilted. ArchiCAD doesn’t even show the curved beam and no errors are written to its log.
There’s an entire discussion to be had on how to validate an IFC file against an mvd, but I think first and foremost expectations on implementations for IfcSurfaceCurveSweptAreaSolid.
You’ve nominated in the header that the file complies with Coordination Model View 2.0, but this shape representation is prohibited in this mvd. As nearly all certifications and testing are in accordance with coordination model view, it’s much more likely there are bugs relating to the use of this shape.
There are improved sweeps in IFC4, I’d suggest the polygon beam should actually be multiple elements for improved reliability.
I chose “Coordination Model View 2.0” without really knowing what the limitations were. I suspect I should be using “Design Transfer View”. Which raises the question… How would I know? A developer has no insight into what’s allowed in an MVD. I suppose developers could read the MVD, but I suspect that nobody does that. It doesn’t help that the documentation site is broken as well as mentioned in: The IFC4 documentation website is broken
The fact that the vendors don’t then flag that a type is not allowed in the specified MVD drives home the fact that vendors aren’t properly supporting MVDs on import either. One would expect import errors logged with a message like “Entities of type IfcSurfaceCurveSweptAreaSolid are not supported in model view definition Coordination Model View 2.0.”
I would also expect that if an entity did load, supported in the MVD or not, that at least it would show up according to the spec.
If developing for IFC2x3, then the CV2.0 MVD is the one to base others interpretations on. Many, if not most of the major vendors have certified against that.
For IFC4, then the RV1.2 is the best place to start. Design Transfer View is kinda dead in the water until we get better end user exchange requirements.
However, I do agree that regardless of the requirements of one MVD, that many, if not all, of cases like this should be properly handled. This is one of the things that Implementation Agreements (IAs) used to cover, but we’ve moved away from, looking to just clarify the documentation and narrow the scope, in some cases, instead.
This and similar issues would be good to bring up at the next ISG meeting.
That shows the IfcSurfaceCurveSweptAreaSolid as part of CV 2.0, unless I’m mistaken.
But the ChangeLog downloaded from the same place says that IfcSurfaceCurveSweptAreaSolid was removed in version 1.5.
Another case of the docs not lining up.
So it looks like IfcSurfaceCurveSweptAreaSolid isn’t in IFC4 Reference View either. Why did this type get added to IFC at all if it’s not in any of the MVDs?
I’ve made the arced beam work after diving into the spec for circles and realizing that they are parameterized in degrees, not in radians as the documents suggest.
The problem remains with profile rotations. According to the spec, the swept area’s +X axis should be aligned with the normal of the reference surface, which in all cases is an IfcSurfaceOfLinearExtrusion using the directrix as the curve to extrude. ArchiCAD does not calculate the normal correctly and, for some unknown reason rotates the profile 90d, and Solibri just arbitrarily rotates the profile by ~45d.
This is all after upgrading the whole thing to IFC4, on the recommendation of @jonm, and switching to Design Transfer View (which had no affect).
Sorry Jon, I wasn’t as clear as I could be. I’m using IfcTrimmedCurve with an IfcCircle as its basis curve, and it wasn’t clear that the start and end parameters needed to be expressed in angles, in the case of a circle. The spec makes one believe that paramterization is circles is from 0-2PI.
The super-frustrating part about that is the spec doesn’t say anywhere that a circle’s parameterization should be different depending on the context. You just see this:
So you think, “I’ll use a parameter space from 0 to 2Pi!”.
Maybe they could clarify this with some more documentation, but why? The units layer in IFC is all sorts of weird. Units should be SI across the board, and the applications should then show the user whatever units she wants to see. Because why on god’s green planet would we invite a situation where a developer defines multiple contexts in their IFC and gives them different units settings? Is that even possible?
bSI and also the majority of software vendors have chosen the easiest path, you chose units mainly based on “Metric” or “Imperial” at the first and you have “somewhat” freedom to change them too
I think in the near future IFC has to improve units, especially after cooperation with GS1
I think Jon is correct, unit is something that you choose at first and I don’t think it’s needed bSI everywhere on spec mentions that which units you have to use
But I think in the near future it would be good if do that and include some logic on IFC that can “recognize appropriate units” and “conversion of units”
This is not exactly true as the documentation is quite clear on this. It says " The IfcCircle ia parameterized using numeric values in correspondence to the plane angle unit provided within the IfcUnitAssignment. If the plane angle unit is ‘Degree’ the parametric range of a circle is 0 ≤ u ≤ 360, if the plane angle unit is radians, the parametric range is 0 ≤ u ≤ 2π."
The snippet explaining parameterization is also properly formatted to make it clear that it is quoted from another (ISO) standard. The specification for the IFC schema is explained in the pasted quote above.
@jonm@jwouellette I’m revisiting this issue. I have a couple of follow-on questions based on your responses regarding MVDs.
As a developer, how do I know what MVD an application is certified against?
Once I know what MVD is assumed, how do I easily find what types are supported in that MVD?
My frustration is that, it doesn’t seem that either of these questions has a quick or straight-forward answer, which leads to me banging my head against a wall until I find something that works.
CV2.0 is unfortunately not yet in the HTML form. You can find a PDF with a list of supported entities in the zip file from this link (on the webpage from my link above CV2.0):
Many of the listed applications show “Architectural Reference Exchange” as their supported MVD. Is that the same thing as “RV2.1” and if so, how would a developer know that?
