The main purpose of the Design transfer view is to transfer data as clever way as possible (usually using parameters). The advanced brep provides means to transfer more smooth geometry. These goals are contradicting.
My opinion is that advanced breps (and b-splines) do not belong to the Design transfer view, but rather
to “visualization view”, which should be an add-on view to reference view.
I have an example:
In design transfer view the workflow is to convert the IFC data into native data format. The parametric profiles make it much easier to do the conversion than the advanced breps. At least there needs to be a alternative representation as parametric profile extrusion in use in this case.
My personal opinion, there is merit to your proposal but advanced breps must be included in design transfer (noting they should be used as a last resort). IFC certainly won’t provide parametric modellings steps such as a fillet for example, so if you want a high quality geometric definition then nurbs are a great way of nominating this. I’ve been developing the use of IFC4 advanced breps for an infrastructure project with success for using AECOSIM super structure in Revit, you can find some insights on this here: https://www.linkedin.com/pulse/ifc4-aecosim-revit-jon-mirtschin/
Your proposal of an advanced visualization view is actually appropriate here as the AECOSIM could export the objects more intelligently for design transfer (ie extrusion with profile with constructive solid geometry boolean difference operations).
Well, my point is that advanced breps should be used where it brings some benefit. In case of normal steel beam, it doesn’t have even a visual benefit (because the roundings are so small), but it has a major negative impact to the smart data transfer. In IFC4 there is a possibility to have several representations, which could provide all the benefits.
From what I understand, IFC4 supports multiple representations. Is there any reason why implementers can’t choose what type of representation they are going for? If it is a tunnel which can be represented by CSG, then it would be good if the user could pick that. If it is a bespoke shape which is better represented by a BREP, then so be it
I do not think the MVDs should favour one type of geometric representation over another. For instance, a BREP is a “native data format” when an IFC is opened in a mesh modeling software like Blender, and it will perform very well. Instead, the implementers should allow users to extract the representation that they think is most useful for their usecase.
The Design transfer view is the most demanding model view, because the received geometry should be editable “as well as” in the sending application. I’m not sure can this be achieved with advanced breps?
