Geometric representation types for IFC4 Reference View

[TLiebich]

We need to discuss the scope for the applicable geometries to be included in the IFC4 Reference View.

• minimum scope: only geometry that is of type "Tessellation"
• maximum scope: all geometry that does not require Boolean operations and complex sweeping operations, like tapering, etc.

questions in detail:

• if we include tessellation IfcTriangulatedFaceSet do we also need surface model geometry?
• since it is widely supported today should brep geometry IfcFacetedBrep included?
• should we include NURBS already here at the reference view level IfcAdvancedBrep
• how about simple sweeps? They might help to reduce file size, and are still easy to create at the receiving end.

[JochenHanff]

HI, i suggest to keep it as simple and reliable as possible. that means that a tesselated brep is the adequate scope. from my point of view, the biggest problem we have with IFC is the complexity. if you look at several cad-systems/viewers you will find that most problems we have to today are wrong geometry/representation resulting from boolean operations between solids/objects. a tesselated brep fits the most use case we have (clash detection, quantity take-off, 4d-simulation, etc) and is easy and quick to implement for software developers (which we are, btw). it would make our lifes a lot easier if we have less complexity. in the end we need tesselated objects for visualisation anyway ... best regards, jochen

[timchipman]

I ran some numbers on files sizes and memory usage, and put together a PowerPoint with the findings:

https://github.com/BuildingSMART/IFC4-CV/blob/master/IFC4-Tessellated-Geometry.pptx

Two scenarios were ran which would seem to be more typical for impacting geometry at occurrences: Walls (File size for IfcMappedItem+IfcTriangulatedFaceSet is 51% smaller than IfcExtrudedAreaSolid+IfcArbitraryClosedProfileDef) Piping (File size for IfcMappedItem+IfcTriangulatedFaceSet is 34% smaller than IfcSweptDiskSolid)

These scenarios would strongly suggest usage of IfcMappedItem+IfcTriangulatedFaceSet without anything else.

The benefit of tessellation is clear for arbitrary mesh geometry (e.g. furniture, equipment) compared to BREP (an analysis was done during IFC4 development), and using IfcMappedItem at occurrences is the same for each. Now the benefit also seems clear where occurrences have varying geometry such as the scenarios tested. Though are these scenarios representative? Can anybody propose other typical scenarios?

[AngelVelezSosa]

Hi Tim,

Thank you for your excellent presentation. Overall, it is good, but I think there are a few issues with it.

1. I don't think it is a fair comparison to compare IfcMappedItem + IfcTriangulatedFaceSet vs. sweeps, since that is apples and oranges. IfcMappedItem should always be used if possible, so we should be comparing IfcMappedItem + IfcTriangulatedFaceSet vs. IfcMappedItem + IfcExtrudedAreaSolid (for example). Also, IfcMappedItem isn't always possible - any little thing can force an instance to need its own geometry.
2. One point of the reference view is to minimize work for importers and exporters in processing IFC files for reference only. However, taking the piping example, there is the assumption that we would create an optimal IfcTriangulatedFaceSet. In theory, that's fine, but in practice you'll get significantly less than optimal data. Taking the bend in a pipe, for example, you are likely to generate many facets using triangulation. There s also an assumption that a viewer will perform graphical tricks with the normals from the IfcTriangulatedFaceSet. That may or may not be the case for all CAD products and viewers, so you may or may not get pretty data.

I completely agree that IfcTriangulatedFaceSet is a clear advantage to IfcFacetedBRep, I am just not yet convinced on the swept solids in practice. One thing that might help is to look at, say, certification files, and do an analysis on those, to see what the file sizes would be with only IfcTriangulatedFaceSet + IfcMappedItem (when possible) or with IfcTriangulatedFaceSet + extrusions/sweeps + IfcMappedItem.

[LassiLiflander]

My proposal for reference view:

Easy to interpret: • No body CSG geometry (Requires Boolean operations) • No body clipping geometry • No element voiding • No B-splines (IfcAdvancedBrep) • No Parametrization

Compact file size: • Triangulated face sets (NEW in IFC4) • Mapping • Simple swept geometry: o Arbitrary swept profiles (No derived profiles) o Revolved area solid (tessellation of round shapes) o Swept disk solid (tessellation of round shapes) • Textures (allowed, but OPTIONAL) • IfcPropertySetDefinition (IfcPropertySetTemplate needed)

One other thing to consider: There is a separate workflows for handover and reference. However, many times the need is mixed. The sender do not know whether the model is used also for handover purposes. It would be advantageous to combine these two workflows to a single IFC model. In IFC4 this is now possible.

@timchipman: The tessellation causes incorrect clashes, because of the inaccuracy of the tessellation compared to the real round geometry. Data loss is not acceptable.

[owensharp]

As an end-user I strongly agree with Lassis' point regarding accuracy .. 'simplification' of geometry is not acceptable for any MV's intended for use in coordination due to the risk of false or missed issues (these are real, not theoretical problems in 2x3 implementations). Perhaps if it were a mandatory cert. requirement that the user can specify a tolerance for tessellation then this would be acceptable

[theoryshaw]

+1 for @AngelVelezSosa comment on certification files. +2 host those certification files here on github +3 allow end-user/superuser to submit (and/or modify existing) their own--would be a valuable conduit to bring them into these conversations.

[timchipman]

Great points here. For those scenarios tested, some underlying assumptions were made, which may not necessarily hold true across different building types and application software.

A) The idealized scenario assumes that there is only one geometric model of a given pipe cross section, and occurrences use IfcMappedItem with non-uniform scaling (along axis of pipe) -- similarly to how IfcExtrudedAreaSolid can refer to a shared IfcCircleHollowProfileDef and each IfcExtrudedAreaSolid has different length and positioning. Going further, if the thickness of the pipe doesn't matter, then pipes of all sizes could refer to the same cylinder (being able to scale the radius and the length for all mapped geometry). This single model could be an IfcExtrudedAreaSolid or could be IfcTriangulatedFaceSet with minimal intervals (e.g. every 45 degrees) or very detailed (e.g. every 5 degrees) -- if the model is only declared once in a file and rendered via transformation matrix thousands of times, then the level of tessellation has trivial impact on file size and GPU resources. The same assumption is made for pipe bends -- there would be a single representation for each pipe radius and bend angle (45, 90, etc.), then positioned differently for each instantiation-- not much different to how the particular fittings and segments would be differentiated in construction.

B) Another assumption made here is that pipes and pipe segments are represented by primitive geometry that can be scaled (without taking into account flanges, etc.) For smaller pipes, perhaps this is good enough; for larger ones, perhaps not. If ends of pipes need to be modelled specifically, then that would also need to be taken into account (either tessellation or in some cases NURBS to be modelled exactly).

C) Another assumption is that implementations make optimized conversions to mapped geometry, which they may already be doing internally -- rather than translating IfcSweptDiskSolid into IfcTriangulatedFaceSet, implementations would use the underlying reference curve and generate IfcMappedItem for each segment (i.e. for IfcCompositeCurve, each IfcTrimmedCurve+IfcCircle references a mapped torus, each IfcPolyline segment references a mapped cylinder.

D) Stepping back, use of tessellation for anything curved sort of implies that a tradeoff is made where accuracy is compromised. Perhaps we should define the required uses of the Reference View -- e.g. if clash detection is a required use, what accuracy is needed? Should the Reference View require a particular tolerance? Should such tolerance be declared in files such that apps or users can determine if adequate for the intended use? Perhaps some applications could give the user control over accuracy? I would assume most clash detection algorithms ultimately reduce down to intersection of triangles (after narrowing down efficiently based on space partitioning), rather than using exact mathematical formulas. Also, what other uses are foreseen of the Reference View? My initial assumption was to provide enough information so a human can reasonably identify items in a building (e.g. "fix this pipe that goes between these rooms here"), but not sufficient for doing detailed engineering analysis, for which the more detailed model view would handle.

Lassi's proposal above seems very reasonable. And as Angel has suggested, I'm also not currently convinced that tessellation will be generally more efficient in all cases for file size, until seeing it applied to representative buildings. Trying out different approaches on full models such as those used for certification seems like a great idea. Perhaps we can take some reference files and make some attempts at automated conversion? This may take more than a few days though, so perhaps we can leave the final decision for geometry until we have more complete data?

[timchipman]

One other thing to add, as Lassi suggested -- perhaps the Reference View and Handover View could be combined in the same file -- elements can have both "Body" solid representations and "Body-Fallback" tessellated representations at the same time as defined in IFC4, so it's not necessarily one or the other -- file size would certainly increase if combining both, but would achieve a "one-size-fits-all" scenario such that users wouldn't have to be aware of model views supported by various applications in that case. Not to get too far off-topic, but if file size becomes more of an issue (perhaps with mobile phones/tablets more common), it may be desirable to encourage an "IFC-HDF" binary format as documented in ISO 10303-26.

[TLiebich]

Between the minimum scope for IFC4 Reference View geometry "tessellation only", and the maximum view "all but Boolean operations", a middle approach seems to be a good fit:

tesssellated geometry (replacing faceted brep, shell and face based surface models)

• IfcTriangulatedFaceSet

sweep geometry (with profiles being of Type IfcArbitraryProfileDef(WithVoids))

• IfcExtrudedAreaSolid
• IfcRevolvedAreaSolid
• IfcSweptDiskSolid

mapped geometry

• IfcMappeditem

Please comment

[MarieHermanova]

As I understand the overall goal of Reference View should be displaying of geometry with various information. Then in my point of view it should contain tessellation geometry (IfctriangulatedFaceSet) and maybe BRep (IfcFacedBrep) only with combination of mapping geometry. We would also gladly accept a limitation of edge number for circular/pipe profiles exported with tessellation geometry. If the circle has too many edges and there are many of elements with this profile, e.g. reinforcing bars then the import will consume a lot of time. Maybe some other application can have the same problem.

[LassiLiflander]

The biggest problem with the IFC is not that something is missing, but the fact that there are too many representations and alternative ways to define things. By add a new one does not solve anything, it just makes it worse. I believe Thomas is proposing that the new triangulated face set will replace the B-rep and other face sets. Could we achieve that also in the handover view?

It's also not desirable to extend end-users tasks and force them to choose the right view according to the receiving system without knowing will the receiver get the data correctly or not. It would be much better to have only one view, where these different workflows are taken into account and supported. A format that just works.

@Marie For example a larger amount of reinforcing bar data cannot in practice be transferred by using tessellated presentation. Therefore IfcSweptDisksolid is a must for structural data.

[romanpolasek]

Lassi, I agree. IfcSweptDiskSolid is the only way, how to effectively represent reinforcing bars, because all Brep based representations will cause big file size.

For reference view using IfcTriangulatedFaceSet, IfcExtrudedAreaSolid and IfcSweptDiskSolid with mapping should be sufficient. It shouldn’t be difficult to display these geometry representations.

[TLiebich]

Lassi, Roman, all: this seems to lean towards an agreement - just want to add the IfcRevolvedAreSolid (as in many pipe/duct connections). Just another thought:

• one of the purposes of the reference view is efficient transport (file size) and display of IFC models e.g. over the web. This emphasizes the comparison with VRML/X3D. And here you also find indexedFaceSet = IfcTriangulatedFaceSet and extrusions = IfcSweptAreaSolid/IfcSweptDiskSolid.
• see http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion

so having all surface based representations unified as tessellations, and allow sweep operations for more compact/precise definitions of round and bended shapes, should be an optimal compromise.

[timchipman]

Some more data to add... determining the file size can be reduced to a math problem using the following equations (see the Powerpoint for how they were derived):

IfcTriangulatedFaceSet: 89+23(vertices)+11(10 faces) = 567 IfcSweptDiskSolid: 153+144(straight segments)+301(curved segment) IfcSweptAreaSolid: 58+439(straight segments)+533(curved segments) IfcMappedItem: 69+165(straight segments)+141*(curved segments)

*Using IfcExtrudedAreaSolid for straight segments, IfcRevolvedAreaSolid for arc segments, IfcArbitraryClosedProfileDef/IfcPolyline with 4 points

Assuming tessellation at 8 intervals per circle:

A) Rebar straight segment: 16 vertices, 10 faces, 1 straight segment, 0 curved segments IfcTriangulatedFaceSet: 567 IfcSweptDiskSolid: 297 IfcSweptAreaSolid: 497 IfcMappedItem: 234

B) Rebar with 90 degree bend: arc section is 272 vertices, 258 faces; straight sections same as straight rebar IfcTriangulatedFaceSet: 567+9183+567 = 10317 IfcSweptDiskSolid: 742 IfcSweptAreaSolid: 1469 IfcMappedItem: 540

C) Rebar stirrups (4 bends, 5 straight segments) IfcTriangulatedFaceSet: 4_9183+5_567 = 39567 IfcSweptDiskSolid: 2077 IfcSweptAreaSolid: 4385 IfcMappedItem: 1458

Clearly, even with the efficiencies over IfcFacetedBrep, using IfcTriangulatedFaceSet increases the file size compared to IfcSweptDiskSolid. Though this increase can be mitigated if dividing tessellated items into primitive segments of cylinders and arcs that are re-used. Using IfcMappedItem with non-uniform scaling is the most efficient of all approaches, provided that geometry is re-used. Using scaled transformations, a file can be defined with just a single cylinder that is positioned/rotated/scaled differently at each usage, and a single quarter-donut for each size and bend radius of rebar.

The ultimate question is how much geometry can be re-used. It would seem that most stirrups will have the same dimensions for a given element type within a building; same goes with column connections and straight rebar. For rebar, on an "average" $100M concrete building having some level of consistency (i.e. repetition of elements), would it be reasonable to have, say 100 unique rebar shapes? At 10KB per unique shape, that would be about 1MB in tessellated geometry definitions which doesn't seem that bad. But I suppose in combination with everything else, that can still add up.

[LassiLiflander]

We did have segmented b-rep profile for Rebar earlier. The customers were not happy. End of that story.

[TLiebich]

final conclusion: in scope of IFC4 reference view:

• IfcTriangulatedFaceSet
• IfcExtrudedAreaSolid (subtype IfcExtrudedAreaSolidTapering excluded)
• IfcRevolvedAreaSolid (subtype IfcRevolvedAreaSolidTapering excluded)
• IfcSweptDiskSolid
• IfcMappeditem

the IfcExtrudedAreaSolid and IfcRevolvedAreaSolid is restricted to profiles of type IfcArbitraryProfileDef(WithVoids)) with straight and circular arc segments only. All other geometry is out of scope of the IFC4 reference view.