IFC4x3 support?

[Moult]

Just curious what the process is to start supporting the IFC4x3 entities? There's a lot of good infrastructure additions.

[aothms]

Is there a public version? I have some, but not sure if I can publish them. Only downside is that compilation time is more or less linear with amount of schemas. 0.7.0 addresses that. And alignment geometry from 4x1 is not even implemented yet :( Sent from a mobile device. Excuse my brevity. Kind regards, Thomas Op di 5 mei 2020 00:09 schreef Dion Moult <notifications@github.com>:

…

Just curious what the process is to start supporting the IFC4x3 entities? There's a lot of good infrastructure additions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#842>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILWV3HTHXL25KLAYIAVWDRP44LJANCNFSM4MZD46WQ> .

[Moult]

It was released a week or so ago :)

https://standards.buildingsmart.org//IFC/DEV/IFC4_3/RC1/HTML

Alignment geometry is one of the fun ones :) When you say alignment geometry isn't implemented, do you mean it isn't parsed to be faceted? If so, that's OK - because they are highly parametric, and should actually not be converted into a faceted curve if possible.

[aothms]

Alignment geometry is one of the fun ones :) When you say alignment geometry isn't implemented, do you mean it isn't parsed to be faceted? If so, that's OK - because they are highly parametric, and should actually not be converted into a faceted curve if possible.

Can you elaborate on that? Ideally we'd convert them into some sort of OCCT BRep / Wire / Curve / Adaptor. Some of the components are not implemented in OCCT though such as clothoid and the other transitioning curves. What other approaches exist besides faceting? I looked around and couldn't find a quick and easy conversion from clothoid to nurbs for example. If you know someone who would like to take a stab at this for example would be great https://www.sciencedirect.com/science/article/pii/S0377042704000135

[Moult]

@aothms oh sorry, I didn't phrase that quite right - I meant that even if IfcOpenShell could facet it - as I am building the BlenderBIM Add-on to be an authoring package too, I will likely have to parse each alignment segment separately, so that I can re-export it out of Blender with specific parameters changed and retain its full description. The faceted curve is good for visualisation, but not sufficient for full authoring, which is what I'm doing :)

[aothms]

Ok, but for visualization you still need something faceted. And the higher upstream it is implemented the better I guess (i.e. IfcOpenShell C++). But feel free to begin implementing things and we can later move things to C++ also if needed.

I added the 4x3. Keep in mind the schema identifier is IFC4X3_RC1, in case you want to create a new file.

[civilx64]

I'd be willing to help with this as IFC for infrastructure has enormous potential in the transportation industry. I read the abstract of the paper regarding clothoid approximation with NURBS. While interesting academically, I don't see it as a necessity. Faceted alignment geometry has worked well in practice for many years, and NURBS are typically not supported by construction equipment machine guidance hardware or GIS asset management systems.

If I were to take a go at this, where would I start? I would assume this would involve collecting some sample alignment data, parsing the file in python, and developing code to generate the corresponding OCC data structures. Conversion of say a clothoid to a wire would happen behind the scenes in order to get displayable edges and vertices in Blender but would not actually be written to IFC as cartesian points and polylines... correct?

[aothms]

Wow, thanks for your interest in helping. So, the end goal is to have this in C++ next to the other conversion functions, e.g polyline is here https://github.com/IfcOpenBot/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomWires.cpp#L616 But if Python is quicker to develop in for you, I don't mind to port things to C++. They don't have to be converted to IFC entities, although it would be interesting to have that as general functionality for viewers that do not support viewing alignments (we have functionality to write OCCT shapes to IFC)

I agree continuous alignment geometry is not a necessity, but it might match Open Cascade's data model better. A student of mine worked on an implementation in Python (https://research.tue.nl/files/46934966/846842-1.pdf) and created a curve from the horizontal alignment, surface of linear extrusion through the horizontal alignment curve and then the 2d vertical curve and extruded surface are the input of a OCCT Edge. It worked pretty seemlessly, but he only used I think linear curves. I don't know if this approach can be extended to the other curves and transitioning curves. This is also not tested when sweeping road profiles, nor tested with cant. So maybe a tesselated approach is best as we have guarantees it will work.

[civilx64]

Yes, I would be much more proficient in Python. I'll review the cpp link you provided and try to match the approach generally so as to make it easier to port to C++.

[civilx64]

I have started implementing alignment transition geometry on a feature branch. I am focusing solely on the 2D horizontal domain to start. My current approach is to calculate points along the curves in local coordinates, then apply matrix transforms to properly locate the geometry relative to start point and direction. We'll see how well that plays out in reality. A few notes:

• I am planning to include the start and end points of the transition curve in the wire. My assumption is that the code parsing the alignment as a whole will recognize and eliminate duplicate points when building the geometry for the entire alignment. This would cover situations where an alignment starts or ends with a transition, versus the typical expected arrangement of a transition between two other segments.

• Similarly, I am not planning to implement any checking for continuity of curvature at the begin or end of the transition segment, but rather leaving that as potential implementation within the context of the alignment as a whole.

Feedback is appreciated, as well as any sample data you or the rest of the community might have for transition types other than clothoids.

[aothms]

@civilx64 very cool!

I am planning to include the start and end points of the transition curve in the wire

That's also what I do in my CGAL (polygonal) implementation for normal ifc2x3 composite curves. So that's great. In C++ OCCT we also have a function for removing duplicate points in general https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomFunctions.cpp#L1625

Similarly, I am not planning to implement any checking for continuity of curvature at the begin or end of the transition segment, but rather leaving that as potential implementation within the context of the alignment as a whole.

That sounds reasonable.

I'll ask around for some sample files.

[aothms]

@civilx64 can you contact me on info@ifcopenshell.org regarding the sample files?

[civilx64]

@aothms per our offline discussion I am spinning back up on this. It looks like the schema has changed for 4x3 RC2 in that the abstract IfcTransitionCurve has been deprecated in favor of new entities e.g IfcClothoid. I will adjust accordingly and hold off on other types (e.g Bloss curve) until 4x3 is finalized. (It appears that there are more changes coming in RC3.)

[aothms]

Wonderful!

There is a RC3 but it appears it hasn't been given the same weight as RC2 https://github.com/buildingSMART/IFC4.3.x-development/blob/master/reference_schemas/IFC4x3_RC3.exp

These kind of changes are somewhat annoying, but ultimately also wouldn't impact the math at least I hope, so perhaps we need to separate this out into two different layers (a) a set of conceptual mathematical types with implementation functions and (b) mappings from the various IFC schemas to these types. This is actually something I have been working on on the C++ side as well [0].

It would be immensely valuable to have something for some version of the schema that gives some results (not necessarily complete or correct) so that @Moult or I can have a look at seeing how the python-based geometry functions can be referenced from BlenderBIM.

[0] https://github.com/tudelft3d/IfcOpenShell/blob/cgal/src/ifcgeom/taxonomy.h

[civilx64]

Good point. I revised the code to utilize a "TransitionCurve" class to implement the geometry algorithms and provide flexibility to map to various schemas. There will be at least two major permutations of entity mapping, assuming that we will want to support both 4.1 and 4x3 (when finalized). At any rate the code as it stands in #1470 should support initial 2D exploration of clothoids in BlenderBIM.

[mach0]

here is my ping ;)
keen to help testing at least - and if possible bring the support for 4x3 a bit forward

[Martin15135215]

In the newest BlenderBIM version, there is support for IFC4X3 semantics :)

[MattiaBressanelli]

Hello everyone,
I'm wondering what's the state of implementation of IFC 4.3.2, now that it has been officialy adopted by ISO (as of 4th Genuary 2024)?
I mean both at the IfcOpenShell level and at a BlenderBIM level.

I work in the highway administration sector, so the infrastructure related classes are of paramount importance for a proper digitalization of the managed assets.

Thanks in advance

[aothms]

@MattiaBressanelli

@RickBrice has been making really exciting progress on this in C++. To give an idea: #4117 #4097 #4091 #4088 #4083

We're implementing this in the v0.8 branch, which unfortunately results in a little bit less visibility, but does give us access to eigen as a more light weight linalg library as opposed to having to implement this on top of the rather heavy brep model in open cascade.

In theory you could already have alignment curves show up in blenderbim as well as linearly positioned elements, but blenderbim is still on the v0.7 branch and given how drastic the changes are in v0.8 it will take a while probably.

All help is welcome!

[MattiaBressanelli]

Thanks @aothms for the quick reply.

I'm certainly willing to help, but I need some guidance on how to get started, can you provide some?

[Moult]

On the BBIM side we've added support for pset / qto templates and docstrings.

BTW if you or you know someone has capacity to help financially that would also help a lot - maybe not immediately towards IFC4X3 development, but it'll definitely be put to good use and give us more resources to meet the rising demand. https://opencollective.com/opensourcebim

[RickBrice]

@Moult The US DOT, Federal Highway Administration (FHWA) has an Advanced Digitial Construction Management Systems (ADCMS) grant program. The scope is very broad focusing on

"accelerating the adoption of advanced technology that may be applied throughout the construction lifecycle (including through the design and engineering, construction, and operations phases) that maximize interoperability with other systems, products, tools, or applications; boost productivity; manages complexity; reduces project delays and cost overruns; and enhances safety and quality. States may apply alone or in partnership with Local Agencies, Tribes or Private Industry"

About $34M was granted in 2023. The application period for FY24 opens May 31, 2024.

I think bringing infra capabilities to BlenderBIM would be a really interesting project with broad applicability.

[Moult]

@RickBrice that's really exciting! Do you (or @theoryshaw or anybody else in the US) have any contacts with any of the state DOTs (I'm in Australia) that can get a conversation started?

[civilx64]

I'm certainly willing to help, but I need some guidance on how to get started, can you provide some?

A good place to start: what use cases are you most interested in / would most like to see in IFCOS / BlenderbIM? Authoring 4.3 models? Read-only viewing? Data validation? That would help in getting you pointed in the correct direction.

[civilx64]

@RickBrice is there interest in a 2024 ADCMS application from WSDOT? If so I'm happy to have some preliminary conversations with you and anyone else that might be relevant. I'm also putting out some feelers for opportunities here in the Midwest. My understanding is that FHWA is planning to focus the next round of awards on states that did not receive funding in the 2023 round.

[RickBrice]

@civilx64 simple question with a not-so-simple answer. The guy who sits at my desk has a lot of interest. Our Bridge Office is just now starting to explore the idea of 3D CAD with OBM for 2D plan production, so there probably isn't a lot of interest because our engineers and structural detailers have never heard of BlenderBIM and wouldn't know what to do with native IFC. Same would be true about our planners and asset managers. At an agency level, we were awarded $1.35M for FY23 to extract roadway features from LiDAR and imagery. Not sure if the higher ups would want to have a competing proposal. I will have some conversations with my colleagues to see if there is interest. With that, I am very interested and will lend as much support as I can.

[civilx64]

Sorry, I should have reviewed the list of year 1 awardees more closely. FWIW at minimum it would be nice to discuss how BBIM might provide value in the US transportation market. My thought- which aligns with what you are saying - is that it's not likely to become a primary authoring tool anytime soon. I see it more as an import tool for review, basic validation, and maybe querying or reporting. At least that's how I have used it thus far, although admittedly in pretty low volume.

[MattiaBressanelli]

I'm certainly willing to help, but I need some guidance on how to get started, can you provide some?

A good place to start: what use cases are you most interested in / would most like to see in IFCOS / BlenderbIM? Authoring 4.3 models? Read-only viewing? Data validation? That would help in getting you pointed in the correct direction.

Hi,
I'm mostly interested in authoring.

This is my thought: the highway administrator (I work in Italy but I think it's similar across the Globe) has GIS data to map the existing infrastructure. We expect new projects to be available in IFC, but probably at different levels of quality, and generated with different authoring tools.

I think having a tool that allows to natively author IFC would be useful to manage data from different sources and make it coherent. BBim could be that tool.

I think the process of digitalization of the current infrastructure, by leveraging the available GIS data + lidar measurements, can benefit from software automation.
Having an authoring tool that is capable of receiving programmatic inputs (like BBim thanks to the python API) and write IFC directly would be great!

It looks to me that commercial software mostly focuses on assisting manual input for new developments, rather than worrying about current infrastructure digitalization. Maybe BBim could fill this gap.

[Moult]

So a lot of the work we've done in authoring <IFC4X3 still applies to IFC4X3. The new stuff is basically building dedicated editing environments to these types of new geometry. Given that we haven't even built a dedicated editing environment for a lot of IFC2X3 geometry (e.g. CSGs or multiple extruded areas) we're a little behind :)

[aothms]

@MattiaBressanelli

If you're interested, the implementation of 3D geometries created from the alignment curves would be a somewhat isolated task and potentially a fun challenge :). An alignment curve (2d, 3d or with cant) gets represented as what we call a piecewise function, which has an evaluate() call to return position and orientation at a certain distance along the curve by means of the evaluate(double) method https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.8.0/src/ifcgeom/taxonomy.h#L170 This can be used to position cross section profiles or sweep the profile.

There is no way of embedding all necessary context in an issue paragraph here online. If you're interested let's find a way to discuss this more in depth.

These concepts actually have sample files in the specification:

https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcSectionedSolidHorizontal.htm

https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcFixedReferenceSweptAreaSolid.htm