buildingsmart / ifc4-cv Goto Github PK

To spark a discussion, I thought i'd share Anton Gerdelan's (@capnramses) recent presentation on some of the inefficiencies he sees in the IFC format.

http://antongerdelan.net/blog/slides/ifc_anton.pdf

An excerpt from the presentation, the following outlines some suggested alternate approaches.

Would like to keep discussion focused on what could be done within reason.

• For plain-text: Khronos Group (OpenGL) is building a JSON replacement for COLLADA called gITF https://github.com/KhronosGroup/glTF/
• This is an interchange format meaning good support, and easy to read
• i.e. does all the things that IFC/STEP is trying to re-invent separately
• For actual end-use online, why not use a binary encoding?
• Plain text encoding means a 4-byte float uses minimum 9-10bytes (probably more) plus precision issues
• Binary encoding means a 4-byte float uses 4 bytes
• Easy to read in C, as well as direct-to-structure in JSON

It appears via the FM Basic Handover MVD that the following '2D plan elements' are supported.

IfcAnnotationFillArea (generically called, a 'filled region', or 'hatch)
IfcTextLiteralWithExtent (generically called, a 'text annotation')

Would it be possible to get support for these in IFC4-CV, as well?

IfcRoot.OwnerHistory provides several capabilities:

1. Merge partial models by indicating particular objects to be added, changed, or deleted. This allows checking in IFC/IFCXML files (either full or partial updates) to servers using simple HTTP POST without any special API, and retrieval of "DIFF"s between versions using the IFC format itself.
2. Restrict editing of particular objects by marking as read/write/read-only/hidden, and locked by a particular user and application
3. Informational attributes describing who/when created or last modified an object, and the application they used.

All of these seem critical in any editing workflow that makes use of coordinating changes from multiple users, though in practice many [most?] applications don't support this, and often provide placeholder values to conform to the schema but don't add anything useful, taking up 10+ superfluous entities in a file (IfcApplication, IfcPersonAndOrganization, etc.). General file-level information such as the user and application last modifying the file are provided in the header (either SPF or XML).

Here's a potential approach:

For Reference View, no owner history is provided at all, for any object (the relevant entities are not in the schema). The rationale here is that since the Reference View is not intended to be editable (containing mostly generated info but not the original parameters), then there would be no scenario of merging or locking objects, and the header would provide sufficient information to see who created the file using what application and when.

For Design Handover View, owner history may be indicated on any object or not at all, supporting all attributes for merging/locking/tracking. However, if it is provided, then the information should be meaningful and not just a placeholder. The rationale here is that since the Design Handover View is used for editing, then such capability may be needed, however supporting the notion that "no data is better than wrong data", the information should only be provided if it is real.

Comments?

For IFC Design Transfer View, is it possible to support one-to-many (non-type) Groups?

i use the word 'Groups', as a stand-in for the concept described below. A better term might be designated

example...

• A BIM file, from Vendor X, contains 10 instances of #Group Z. (Group Z is composed of a wall, a column, and a piece of furniture, for example) →
• This BIM file is exported, via IFC, and in turn imported into Vendor Y's BIM file. →
• Within vendor Y's program, a user changes/modifies the definition of #group Z. This change is, in turn, propagated throughout the 10 instances of #Group Z , within vendor Y's file.

Based on the work being proposed for IFC product libraries, do we need to have an explicit "Library View" documented?

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.

Created a new folder "scope" to upload and share the scope definition documents.
https://github.com/BuildingSMART/IFC4-CV/tree/master/Scope

Please use this issue to comment on it.

In order to close the first round of specification work of the new IFC4 reference View, the following items should be discussed and concluded on:

• using local placement: are we using local placement as an object placement (without the need for cascading placement systems as in IFC2x3 CV)? It would then be similar to the X3D position, but would still involve matrix operations on the vertices
• adding IfcGrid: a grid is an important items for coordination, also for linked reference models, when added, we also add 2D curve geometry (lines and arcs)
• adding IfcOpeningElement as semantic information (not as subtraction shapes): should we keep the opening information (e.g. to keep the sizes and attributes) and use shape aspects to represent it?

Can anyone share the reasoning why the following entities where depreciated in IFC4? Tried to search the old Jira site, but could not find a discussion around this topic.

• IfcAngularDimension
• IfcRadiusDimension
• IfcAnnotationCurveOccurrence
• IfcAnnotationFillAreaOccurrence
• IfcAnnotationOccurrence
• IfcAnnotationSurface
• IfcAnnotationSurfaceOccurrence
• IfcAnnotationSymbolOccurrence
• IfcAnnotationTextOccurrence
• IfcDefinedSymbol
• IfcDiameterDimension
• IfcDimensionCalloutRelationship
• IfcDimensionCurve
• IfcDimensionCurveDirectedCallout
• IfcDimensionCurveTerminator
• IfcDimensionPair
• IfcDraughtingCallout
• IfcDraughtingCalloutRelationship
• IfcDraughtingPreDefinedTextFont
• IfcPreDefinedDimensionSymbol
• IfcPreDefinedPointMarkerSymbol
• IfcStructuredDimensionCallout
• IfcTextStyleWithBoxCharacteristics

related discussion: https://www.linkedin.com/groups/Is-there-IFC-entity-schema-3690870.S.5855386596991328256

For IFC5, would it be possible for an IFCMaterial to have a GUID associated with it?

Didn't know where to place this question, since there was an IFC5 repo out there.

Please let me know if there's a better location for this request.

Thanks Much, Ryan

We agreed for the scope of the Reference View to exclude direct and implied use of Boolean operations. Therefore the current use of IfcRelVoidsElement has to be:

• changed in the scope of the IFC4 RV
• excluded from the IFC4 RV

Since the main path element -> opening -> door/window should be maintained (to remain similar to the IFC4 design transfer view), it cannot be excluded. Hence we need to use IfcRelVoidsElement also in IFC4 RV, but have to define an alternative way of using it without implying a Boolean difference operation.

Currently we see two possibilities:

• use the Name attribute of IfcRelVoidsElement to differentiate between the two way of allying it (1) implying a Boolean difference, and (2) not implying it
• use a different shape representation identifier for the voided element (e.g. the IfcWall), instead of using "Body", use "NetBody" indicating, that it is the net geometry with all voiding already included. Add to the semantic definition of IfcRelVoidsElement that it only applied to "Body" geometry.

we need your opinion.

When defining the exact scope of the IFC4 Reference View - how to handle types, and what kind of information

• geometry
• properties
• material

shall be handled by the type and could be overridden at the occurrence level.

There have been multiple requests for capturing calendars on spaces or elements to indicate recurring calendars of occupancy or equipment usage. IFC4 introduced the entity IfcWorkCalendar which can capture recurring time intervals and supports all calendar scheduling capabilities found in Outlook and Microsoft Project. The main intention of the data type is for scheduling tasks, however it is generic to support any other recurring calendar scenario such as occupancy.

We initially assumed this was out of scope, as none of the major design platforms would appear to collect this information, and the intent is to coordinate the results of a design, not the design intent or any comprehensive set of parameters for achieving the resulting design. Though as this issue keeps coming up, perhaps it makes sense to get wider input from the group. While we're at the 11th hour before uploading the release candidate, if we get sufficient feedback that is representative of implementers, we could act on it.

So some questions for software vendors who will be exporting Design Transfer View:

1. Do you collect calendar information about spaces or other objects?
2. Would you be able to export it according to the IfcWorkCalendar data type?

Perhaps more appropriate for Design Handover View, but is it possible to support the exchange of walls that are 'constrained' or 'linked' to building level elevations?

Currently the two names are:

• IFC4 Reference View
• IFC4 Design Handover View

for explanation see the powerpoint explanation

Whereas the IFC4 Reference View is a well understood name, the "Design Handover" seems to have an ambiguous meaning - where most understand "Handover" to client, and in particular for operation.

At a recent bSI meeting in Munich the recommendation was made to call it:

• IFC4 Design Transfer View

Any thoughts on that?

Texturing in IFC provides many capabilities; for the Coordination Views, we need to decide what should be in scope - perhaps all or perhaps a small subset. Following are some initial recommendations:

1. Entities -- IfcImageTexture supporting relative or absolute URL to image file, IfcBlobTexture supporting embedded file in original format (e.g. png, jpg), and IfcPixelTexture supporting embedded uncompressed bitmap.
   --> Recommend only IfcImageTexture such that initial file retrieval is fast and textures can be loaded in background as needed (or if needed at all for particular app). If using zip file, relative URL may be used to indicate a file within the zip.
2. Single or multiple textures -- Should there only be a single texture indicating diffuse coloring, or should multiple textures be supported for defining additional shader operations for supporting translucency, reflection, light emission, etc., making use of IfcSurfaceTexture Mode and Parameter?
   --> Recommend only single diffuse texture, no translucency (implementations may ignore alpha channel if present)
3. Vertex mapping -- IfcIndexedTextureMap provides efficient mapping to triangulated models; IfcTextureMap provides general mapping to each IfcFace of IfcFacetedBrep; IfcTextureCoordinateGenerator provides procedure-defined ways of calculating texture mapping (e.g. mirrored surfaces, applying mappings to defined faces of parametric geometry)
   --> Recommend only IfcIndexedTextureMap and optional; in absence of texture map, use standard mappings for shapes as documented in IFC4 spec.
4. Texture transforms -- stretch, translate, or rotate textures (particularly useful when there's no vertex map). This allows indication of how many pixels represent a physical length (e.g. 256 pixels = 1 meter).
   --> Recommend in scope
5. Texture stretching or repeating in either direction. IfcSurfaceTexture RepeatS and RepeatT allow indication of whether texture should use the transformed length (e.g. 256 pixels per meter) or stretched to fill each face or triangle.
   --> Recommend in scope
6. Formats -- PNG, JPG, GIF, BMP, ICO, TIF, ...
   --> Recommend limiting to PNG, JPG -- these seem to be the most common on product manufacturer websites

Other aspects? Please comment.