Ifcopenshell: [BlenderBIM] Quick Project Setup

[globalcitizen]

Clicking Quick Project Setup in Building Information Modeling yields a new collection hierarchy.

However, to this new user it was unclear:

• how this relates to existing objects in the scene
• what the impact is of specifying or not specifying an IFC file
• what the impact is of specifying or not specifying a cache
• what any of the IFC class and type buttons do.

In fact I don't even know if I need to click it, since I don't actually want to use IFC features.

After playing around it seems like the IFC class and type buttons assign identities to Blender objects from these IFC defined category heirarchies using a combination of:

• Renaming the objects in question (specifically adding a prefix like IfcActuator/ to the existing object name (ie. Cube becomes IfcActuator/Cube)
• Custom object properties.

Not sure if I got this right, it's assumption. From a programmer perspective this makes sense where a user wants IFC features, but to a user it is pretty unclear.

Still totally unclear:

• What the impact is of not having clicked this setup button
• What the impact is of clicking it twice
• What the impact is of having objects within or outside of the collection that it generates, whether multiple such collections are allowed within one file, how these may interface/interfere with any exports, etc.

As a quickish fix may I suggest considering something similar to the following?

• Consider changing this from something called 'Quick Project Setup' to some sort of clearly delineated setup procedure which is linked to BIM/IFC, eg. 'Quick IFC BIM setup'. Also, perhaps avoid the term 'project' as dangerously likely to cause confusion since it is typically used at numerous levels of abstraction throughout any real world project.
• When the user opens a file with the BlenderBIM plugin enabled that has not had a Quick Project Setup run done, then all BlenderBIM IFC related options are disabled and replaced with an appropriate message indicating the reason (project IFC has not been set up)
• The user is then directed to click the renamed setup button
• When the user clicks the renamed setup button, a popup explains the model for integrating IFC objects/classes/categories/whatever and Blender objects to the user in some way, and basic new user audience documentation around how the BlenderBIM puts together its view of the world, even if it's just "go view this URL to understand the general integration model".

In a future version of the plugin, less directly linked to IFC (ie. facilitating use by those who have no interest in IFC), perhaps this whole feature set could be hidden behind a settings toggle "[X] enable IFC". That way you vastly simplify the amount of interface complexity encountered by new users, who may not care about all the IFC stuff and just want the other cool features.

[Moult]

Some notes to things you mention are unclear:

• If a user attempts to exports an object without setting up a project first, in the latest version, a project will be set up at export time.
• If you click it twice, you will get two projects. Nothing wrong with that.
• IFC is a special schema, unlike regular 3D schemas, where it doesn't just store 3D geometry. In fact, 3D geometry is optional - the data structure, and hierarchy, is not optional. As such, it is not possible to export an IFC _without_ a project structure being set up. Therefore, the collection structure represents the IFC structure, almost with a 1<->1 mapping.

Some notes related to quick fixes:

• IfcProject is a particular jargon which I wish to maintain. This distinguishes from IfcProjectLibrary, for instance. It is possible to completely build a BIM project using all of the IFC features without having set up an IfcProject, then set it up all at the very end, which is sometimes done as a workflow.
• As mentioned, you do not need to set up a project to use all the features. In fact, if you do open an IFC file, a project is already imported from the opened IFC file, and there is no need to setup a project.

It seems the button is misleading - it is simply a quick way of generating a preset structure to minimise clicks for an isolated, but common task.

Hope it helps. Thoughts?

[globalcitizen]

Very clear, thanks for your patience while I grapple with ignorance and lack of sleep.

If a user attempts to exports an object without setting up a project first, in the latest version, a project will be set up at export time.

Random thought. Does this get saved or not? Transparent export without modifying the source file would be a great feature, I guess for compatibility this would require a deterministic object GlobalId generation algorithm though, in case subsequent exports to a third party platform required consistency (I guess you deal with this a lot professionally).

two projects. Nothing wrong with that

Nothing wrong with it but what are the implications? This is the sort of thing people (ie. me) need explained. What is an IFC project and how should I treat it? No mental model right now. What is its purpose?

IFC is a special schema...

I believe IFC specific concerns might be best embargoed within UI elements that are possible to disable in project setup with an "[ ] Enable IFC" style checkbox. This would disable the relevant UI panes right throughout the interface, both at object and scene level.

What do you think about this idea?

[Moult]

Random thought. Does this get saved or not?

It will modify the source file. I try to minimise magic :)

Nothing wrong with it but what are the implications?

A project correlates to a legal contractual project being undertaken in the built environment - this could be, for example, represented by a single council application of a design. It is quite common for a user to want to see multiple projects at once. There is an implication right now that it is _not_ possible to export multiple projects into a single IFC file, which is a limitation of the IFC schema, which may be removed in future versions of IFC. As a result, during export time, if you do happen to want to export multiple projects, it'll get merged under the first project it finds. There are no other implications that I'm aware of.

I believe IFC specific concerns might be best embargoed ...

The primary purpose of the BlenderBIM Add-on is to bring BIM capabilities into Blender. BIM and IFC, in my opinion, are inseparable. At the moment, I can only think of the section planes feature that is agnostic of IFC. Therefore, I disagree with having an "Enable IFC" checkbox, as it is synonymous with disabling almost the entire add-on.

I would be more interested in pursuing UX solutions that make non-applicable IFC settings less intrusive into a pure modeling workflow (much like hiding panels prior to assigning IFC classes).

[globalcitizen]

"a legal contractual project being undertaken in the built environment"

Hrrm OK. I can see a whole range of realistic situations where that set of assumptions falls down ...

• As-yet-unapproved project
• Historical project
• Potential project
• Project being used to spatially model a particular state of building (eg. after X before Y during construction)
• Virtual project
• Cross-jurisdictional project
• Landscaping project
• ...

Anyway, it seems basically hand-wavey and generally an artifact of the standards push that is externally defined and not of primary interest, I was just seeking general clarification.

The primary purpose of the BlenderBIM Add-on is to bring BIM capabilities into Blender. having an "Enable IFC" checkbox is synonymous with disabling almost the entire add-on.

It feels like the reality right now is that there is basic functionality missing from Blender that is needed right across the architectural or construction domain (like dimensioning, and decent construction detail drawing export) and this functionality is implemented n different ways in n different add-ons with n different sets of limitations, none of which are documented. That is a classic open source problem, and why few people can get involved. It's just too hard for new users.

I don't think a "disable IFC" button disables almost the entire add-on. The other great features like awesome SVG export, dimensioning, hatching, drawing/camera management, are still there. Why not embrace allowing others to leverage and improve on those to move forward? Then you get the benefits of their work for free. For example @kevancress has persistent object dimensions in MeasureIt-ARCH and a camera-specific output resolution solution whereas currently BlenderBIM has only one-time calculations and no resolution setup. However, BlenderBIM supports partially SVG output whereas MeasureIt-ARCH has only bitmap. Archipack (@s-leger) has awesome on screen dimensioning (according to their demo video) which everyone could probably benefit from.

It would be great to work towards a common solution to these common issues which is flexible enough to leverage all of the great work being done while facilitating more users and exposure for everyone. Obviously from a certain perspective this throws up thorny questions about project direction, roadmap, skillsets, priorities and interests, but ultimately code committed means code available to users and long term it also ensures that the project survives and thrives with a broader user base, enhanced community and additional documentation to truly rival closed source competitors.

Or maybe I am dreaming.

[Moult]

I am aware of the ambiguity of the project definition, particularly when projects are smaller. This is to be expected: ISO standards do not target smaller ambiguous projects. A project has nothing to do with time - a single building may have multiple projects, if multiple stakeholders have been engaged over time, managed by different clients. It applies to potential, landscaping, and virtual projects too. One way of thinking about it is: if there is a problem, what set of documentation is grouped together and presented at court when you resolve a dispute?

Perhaps a better solution regarding the more general BIM features is to work together more: I have nothing against removing all of the documentation features from the BlenderBIM Add-on, and merging it into @kevancress 's work, for example. Perhaps only the IFC specific portions can be retained in the BlenderBIM Add-on. Then perhaps there can be a distribution which bundles the various add-ons together.

[kevancress]

@Moult & @globalcitizen
A couple loosely organized thoughts on documentation features and long term goals

I'm open to porting over the documentation features of BlenderBIM to MeasureIt-ARCH if we agree that that seems to be a good division of features?

I agree that it could be useful to have MeasureIt-ARCH as a more generic documentation tool that isn't dependent on the IFC schema, as long as we structure it in a way that keeps cross platform compatibility possible (being able to round trip an annotated model between FreeCAD and Blender would be amazing as an ultimate goal, not sure how feasible this is though)? I suppose this all depends on how IFC handles Views, Sheets, Annotations etc. which I have to admit I'm not too familiar with, so @Moult your experience with the standard would be essential to developing this.

Quite interested also in the possibility you discuss here of making use of .svg as a 'paper space' standard and keeping IFC as a 'model space' representation. This might have some interesting connections with how I'm structuring MeasureIt-ARCH. Currently the data structures for annotation & dimension elements in MeasureIt-ARCH store their anchor points in model space, and the 'paper space' (view space might be a more accurate term in this case) representations are generated on the fly depending on the current views position (and eventually other view dependent settings like scale).

This might lend itself well to the dual .svg / .ifc representations, with .svg export being a vector snapshot of a particular view condition lending itself to traditional forms of documentation, whereas the IFC could store the model space representation of the dimension and annotation elements. I might be thinking a little too far ahead here but I think model space annotations may become increasingly relevant if the industry continues to adopt VR/AR technology more in the future (and since Blender 2.83 now supports VR scene inspection its worth considering).

That said though I do think the immediate focus should be on creating a system that achieves the basics @globalcitizen mentions first, and in that case the .svg output would be first priority?

[Moult]

100% agree. Let's discuss more in the OSArch monthly meetup.

I am going to close this bugreport, as it is not actually a specific, actionable, bug. Can I suggest, @globalcitizen that you create a new thread on https://community.osarch.org/ and for us to continue the discussion there? That would allow others in OSArch, especially @theoryshaw and @yorikvanhavre to join in too - these decisions impact them.

[globalcitizen]

OK but I have to head out now and can't guarantee to make the thread before the meeting which I understand is 6AM Sunday morning Sydney time?

[Moult]

@globalcitizen no rush.

[globalcitizen]

Done.