buildingSMART Forums

Why are CSG representations mandated for DTV?

At the risk of going slightly off-topic here, I’d like to debate the applicability of MVDs. As @jwouellette states, tessellation of walls are not in scope for a DTV. However, in Blender, where BReps are the native format, tessellated walls are exactly what Blender wants to do a design transfer. In fact, if we received walls in CSGs, I would find it much less convenient.

Especially in complex environments (old tunnels, in my experience, and scan to BIM), I would explicitely tell consultants to not deliver CSG, and instead deliver tessellated geometry - the ability to process and visualise them would also be much faster. This is a symptom that MVDs are not universally applicable and is why in contracts we no longer depend on MVDs and instead break it down to unit tests.

@Moult I guess therein lies the rub. For the most part, the assumption has been that DTV requires advanced geometry support (Sweeps, Extrudes, CSGs, etc.), especially as the pounding on the door for parametric value support on elements is growing. Thus, it would seem that platforms that can’t import/export/handle/convert/process such geometry are not able to support DTV-based workflows.

I think I may have to split this one off into another Topic…

@jwouellette
Yes, this is an important topic.

For simple common geometries (eg. cubicles) it should be possible to change geometric representation paradigm and to come back to the origin paradigm without loss of information.

Loss of (geometrical) data or loss of information.
What is information??? The dillema of bim

@Hans_Lammerts
For a building model with simple geometries (e.g. standard family house with cuboid walls, slabs,…) I wish to get back an IFC file equal to the original IFC file after a roundtrip with transformation to different geometric representation paradigms. The transformation typically happens due to import to a different authoring-software that uses a diffferent geometric representation paradigm.

e.g.:
start: cuboid wall as swept rectangle (e.g. created and exported from authoring software A)
transformation to B-rep
transformation to primitives (e.g. cuboid)

transformation to CSG
end: transformation to sweep volume

I wish to have an IFC at the end equal to the IFC at the start

@Herb, in my opinion, that geometry roundtrip is not feasible or even not possible. You definitely loose some information (how the geometry was constructed aka modelling intention) when you convert from Primitives, CSG, Extrusions to Boundary representation.

It takes computational effort to restore that information or it is not possible at all. For instance, there are three different directions in which a cuboid may have been extruded. There is no way of knowing which was intended. You may be tempted to take the product type into account and assume something from there, but you can not really know if the type was specified in accordance with the intention.

Also, where do you imagine the conversion carried out? If software A supports only paradigm A and software B only paradigm B, you need an independent piece of software to do the computations. I think it would be a waste of resources to require every software to implement every geometric modelling paradigm.

2 Likes

Today we need to find which paradigms are the best and the majority use/implement? and nominate them. Which I think today (IFC4) IFC has had a lot of improvement in geometry/topology (LoD)

What’s BIM? There’re a lot of definitions, but for me from the first day “BIM is virtual representation of reality” which today some call it “Digital Twin” which is a general term

BIM is data/information mounted on geometry/topology and has some requirements for instance should be “interactive” which still today BIM is not “realtime and interactive” yet

MVD idea is/was to be a subset of IFC that supports all software/devices whiteout dependency to them and their paradigms

@tauscher
Thank you for your comments.
Yes, it seems to be really difficult up to impossible to support full conservative geometry roundtrip.

On the other hand, the current situation is incomprehensible:
Why are there several different “best ways” to model an ordinary wall?
Does this diversity really make sense?
If this diversity is really useful to the users why does the software-vendor decide the geometric representation paradigm in advance instead of letting the user decide separately for each use-case?

I propose a modelling standard based on building-science and building-practice instead of software-vendors preference. At least for very basic geometries (which cover 99% of building element models) this should be achievable.

1 Like

It is a technical fact that it is not possible to convert from any geometry representation to another geometry representation without loss of data. The concept of “geometric roundtrip” refers to the ability to move between software that support exactly the same geometric representation. Even if one software supports slightly less information, information is lost. This is very hard, as even between the BRep world, different 3D modeling packages can do different tricks with BReps, such as their implementation of a Catmull-clark vs other types of subdivision. A round trip, or DTV, is not to do with converting between representations.

However, and this is the point of the thread: it is a technical opinion, not a fact, that one form of geometric representation is always better than the others. For example, CSG is objectively better for representing the majority of steel members, as inherently the STEP natively represents the manufacturing technique. Equally objectively, if the steel member is a rectangular plate, then a mesh representation does not have any loss of geometric information (there is loss of the semantics of the plate orientation, based on the extrusion direction, though).

On the flip side, meshes, and particularly mesh subdivision surfaces are objectively better at rapid geometry creation during concept phase and design development, sculptural landscape forms, heritage designs, 3D printable designs, scan to BIM, furniture representation. In fact, one may argue that tesselation can be far more advanced than CSG modeling, which is relatively basic parametrically, as tesselations support a far greater number of interesting mesh algorithms (Catmull-clark, un-subdivision, solidification, wave deformations, wireframing, skinning, different triangulation tesselations, …) which artists use to create designs, particles, weights, and vertex information, all of which affect the shape.

The proof of this difference is shown when you see certain fabricators prefer CSG, and certain architects prefer mesh modeling. I have experienced many times when a fabricator needs to remodel a mesh in CSG format because a mesh is not appropriate for their fabrication. Equally, I have experienced many times when a CSG representation is outdated in a BIM model and only used as a placeholder because the real design is done in meshes (furniture is a big example of this).

In short, if you didn’t feel like reading the explanations:

  • Design transfer view, or round tripping can only be achieved if each software supports exactly the same representation. It is technically impossible to prevent loss of data if there is a representation conversion
  • CSG is better for some things, and meshes are better for other things.
  • CSG is not more “advanced” than meshes. Both have a lot of tricks they can do in their own domain. The worldview that meshes are more basic and unworkable is by those inexperienced with the CG industry.
  • A DTV MVD that mandates CSG for all things is therefore wrong. Users should be allowed to specify which they expect for which items.
  • A practical solution to the round-trip problem is that if a vendor imports a representation they do not support, they should still represent it visually, but if it is not edited, upon export, the original representation must be maintained. Equally, if the user chooses to modify it, the vendor must notify that it is a lossy edit, and provide a function to launch another program that is capable of handling the representation natively.

I have renamed the topic to my original intention for this thread.

1 Like

“Yes, it seems to be really difficult up to impossible to support full conservative geometry roundtrip.”

This is exactly my point about the geometry dilemma. What’s information to one, is wortless for the next person. As i see it multiple shapes and appearances should be included in one model. Which is totally unpractical for storage of data.

Today i caught another acronym that made me think about the way we sore and share our (bim) data. CDE would actually be a Common Data Repository (CDR) it came from a Autodesk promo.

As i see it a model of a building could be a simplified scheme of walls (accurately 5 cm) or a full blown scan (accurately 1mm) and any formed mesh- or CSG model in between. Combine that thought to every seperate object in the (building / infra) !system! That would be effective.

But what us needed is to detach the data from geometry. Than we can start talking about LOD with hard values for accuracy. Link it with some smarter linking et. With a repository accessible via internet directly from your CAD / GIS / modelling software.

Ps. writing it now. Reading moults comment later…

Good read!

https://translate.googleusercontent.com/translate_c?depth=1&hl=nl&nv=1&rurl=translate.google.com&sl=nl&sp=nmt4&tl=en&u=https://bignieuws.nl/integratie-bim-en-gis-data/&xid=17259,15700022,15700186,15700190,15700256,15700259,15700262,15700265,15700271&usg=ALkJrhhQehQunyJANASraBpmKfsuk0qXfw

1 Like

I think some months ago I suggested this but … :laughing:

Ok. Get on with the cow then! :slight_smile:

I’m in no hurry! :slightly_smiling_face:

At its right time all my 5-6 ideas will come to the industry and will change everything, everything!

@Moult, I absolutely agree with the fact that different geometry representations are useful for different purposes and there is no superiority or inferiority per se. @Herb,this is not a random choice of software developers or vendors, but driven by what that specific software is meant to do - authoring, visualization, animation, simulation, clash detection, quantity takeoff, etc.

CSG and parametric representations are the classic way to represent geometry in CAD applications, because they capture how the geometry is constructed. This is not necessarily about how the artifacts are constructed later during manufacturing, but how engineers construct models during the technical design of a product. CAD applications use CSG because this allows efficient editing of the model during this phase. For instance, you want to move a window’s location in a wall, change the width of the wall or of a slot for electrical installation. Same goes for curved surfaces - typical engineering applications work with parametric or even implicit surface definitions, instead of explicit meshes.

Because the CSG and analytic surface data models are not efficient for some computations such as volume calculation, not to talk about visualization, CAD applications typically maintain multiple representations for these purpose and derive BREP and meshes from constructive or analytical geometry. If inevitable, conversion is easier this way than the other way round. That is why Design Transfer View is meant to ensure that these design representations remain across a data exchange and the model is as easily editable in an authoring CAD application as before. If the restrictions were removed, the DTV MVD would not serve this purpose anymore. On the other hand, if you do not need these restrictions, why would you require DTV? Why not use a different MVD? What is Reference View lacking that you need? How would an MVD (or requirements specified in other form) look like for your exchange scenario? What parts of DTV and RV respectively would you need if one alone is not sufficient?

Granted, there is not much choice and flexibility at present, but I believe this is our current challenge, to find a good balance between restrictions to ensure interoperability and flexibility to support the various cases. The clear discrimination of geometry paradigms that DTV and RV make is undoubtedly necessary to roughly name the capabilities of software. But probably we will need a little more modular and fine-grained requirement specifications, especially to support scenarios that don’t fall in the traditional domain of product modelling, where it is all about the technical design of industrial or artificial things for production. Looking at your cases, @Moult, I see for example surveying/scanning, natural objects, early phase design - all part of a holistic design process. Good to see you looking at these cases and working from the other end of granularity.

2 Likes

@Hans_Lammerts
Thx for referencing that very good article that provides good insight!

https://translate.googleusercontent.com/translate_c?depth=1&hl=nl&nv=1&rurl=translate.google.com&sl=nl&sp=nmt4&tl=en&u=https://bignieuws.nl/integratie-bim-en-gis-data/&xid=17259,15700022,15700186,15700190,15700256,15700259,15700262,15700265,15700271&usg=ALkJrhhQehQunyJANASraBpmKfsuk0qXfw

I would like to cite some important parts out of this article:

“A final guideline that we propose from this project is to make formal agreements on how specific situations should be modeled with IFC. Even within the same file we encountered differences for similar situations.”
“… we have shown that a clear and specific modeling of IFC (with the associated validation tools) is required …”
“Making agreements for this, recording these in open standards and strictly following these standards is an important next step.”

This is similar to what I had in mind as I stated “I propose a modelling standard based on building-science and building-practice instead of software-vendors preference.”

1 Like

The industry needs new methods, something like these kinds of movements:

@Moult
I agree to most you stated but I would like to claim slightly more from IFC import via partial model editing to IFC export:

all applications shall support VIEW of any representation

FOR EACH element
____IF element NOT edited
________application must keep corresponding IFC entities unchanged
____ELSE (if element edited)
________IF representation supported
____________applications must keep representation unchanged
________ELSE (if representation NOT supported)
________application must provide user choice:
____________- lossy conversion for edit in different representation within this application
____________- launch another program that is capable of handling the representation
________ENDIF
____ENDIF
NEXT element

I again call this concept “conservative IFC processing”.
Keep original IFC file structure as unchanged as possible instead of scrambling the whole model.

This is a long-term concept (around 10 years) because software vendors need time to adopt and successively advance their large codebasis.

1 Like

@tauscher
Thx for your valuable explainations.

Based on a very simple example file:
IFC model with 1 project > 1 site > 1 building > 4 storeys > 16 walls > 64 windows of same type

Round-tripping on three important authoring software tools resulted in similar disillusioning outcomes:

:+1:t2: The round-tripped model looks almost identical to the original model (in Xbim Xplorer)

:confounded: The round-tripped model is differently structured based on different representation paradigms

:confounded: The round-tripped model is de-normalized (64 windowtypes instead of 1) resulting in bloated IFC files.

Based on your statements “… different geometry representations are useful for different purposes …” and “driven by what that specific software is meant to do - authoring, visualization, animation, simulation, clash detection, quantity takeoff, etc.”

Why does common AUTHORING-software (specific purpose) use for the same situation (ordinary wall) export different IFC geometry representations (extruded area versus B-rep)?
Currently it seems to be a “random choice of software developers or vendors”, isn’t it?

Sorry for falling into the roundtrip trap. We are talking about DTV and even that is not meant to guarantee lossless roundtrips. I have corrected the wording in my previous post. However, DTV should ensure that CAD software can exchange data for authoring and editing purposes. Therefor it restricts geometric representations. Bear in mind that the restrictions and standards are not for the internal model or behaviour of software. Instead, IFC is a standard for the data that software can produce and consume.

Software developers and vendors do indeed choose their internal models freely, but not randomly. They use what is most efficient for the features that they provide and ideally they export what is closest to their internal model - because that would reduce information loss on re-import. However, this will not be ideal for exchange, because other software may have a different internal model. Even the purpose of CAD authoring is a broader field and various software has different feature sets. If you would introduce restrictions here, you would effectively limit the creative freedom of architects, designers and engineers.

That is the reason why the negotiation around DTV is so lengthy and interminable. I can not say much about your example, because to my knowledge there is no software with certified DTV export and import yet. But even if it would be - a lossless roundtrip would be unlikely to be achieved.

Your thoughts on “conservative IFC processing” are certainly interesting and reasonable.

1 Like