mirror of
https://github.com/IfcOpenShell/IfcOpenShell.git
synced 2026-08-17 10:59:17 +00:00
Rename source dir
This commit is contained in:
Dion Moult
@@ -0,0 +1,20 @@
|
||||
# Minimal makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line, and also
|
||||
# from the environment for the first two.
|
||||
SPHINXOPTS ?=
|
||||
SPHINXBUILD ?= sphinx-build
|
||||
SOURCEDIR = .
|
||||
BUILDDIR = _build
|
||||
|
||||
# Put it first so that "make" without argument is like "make help".
|
||||
help:
|
||||
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
||||
.PHONY: help Makefile
|
||||
|
||||
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||
%: Makefile
|
||||
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
Vendored
+91
@@ -0,0 +1,91 @@
|
||||
@import url("https://fonts.googleapis.com/css2?family=Nunito:wght@200;300;400;500;600;700;800&display=swap");
|
||||
@import url('https://fonts.googleapis.com/css2?family=Inconsolata:wght@200;300;400;500;600;700&display=swap');
|
||||
h1, h2, h3, h4 {
|
||||
font-weight: normal;
|
||||
color: #7cbf33;
|
||||
background: -webkit-linear-gradient(0deg, #7cbf33, #049344);
|
||||
background-clip: border-box;
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
}
|
||||
a {
|
||||
text-decoration: none;
|
||||
}
|
||||
.toc-tree .reference:hover {
|
||||
color: #d98014;
|
||||
}
|
||||
.sidebar-brand-text {
|
||||
font-size: 1rem;
|
||||
text-align: center;
|
||||
}
|
||||
.blockbutton {
|
||||
max-width: 500px;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
text-align: center;
|
||||
}
|
||||
.blockbutton a {
|
||||
display: block;
|
||||
padding-top: 15px;
|
||||
padding-bottom: 15px;
|
||||
border-radius: 5px;
|
||||
background: #40b74c;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
color: #fff;
|
||||
text-decoration: none;
|
||||
}
|
||||
.blockbutton a:hover {
|
||||
background: #70ba35;
|
||||
}
|
||||
.highlight .hll {
|
||||
background-color: #ffc2;
|
||||
}
|
||||
section img {
|
||||
display: block;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
box-shadow: rgba(0, 0, 0, 0.24) 0px 3px 8px;
|
||||
border-radius: 5px;
|
||||
}
|
||||
.location-scene img {
|
||||
display: inline;
|
||||
border-radius: 0px;
|
||||
box-shadow: none;
|
||||
vertical-align: middle;
|
||||
margin-top: -3px;
|
||||
}
|
||||
.location-scene p {
|
||||
margin: 0.75rem;
|
||||
}
|
||||
.location-scene {
|
||||
border: 1px solid var(--color-admonition-title);
|
||||
background-color: var(--color-admonition-title-background);
|
||||
border-radius: 5px;
|
||||
font-style: italic;
|
||||
color: var(--color-admonition-text);
|
||||
}
|
||||
img.icon {
|
||||
width: auto;
|
||||
height: auto;
|
||||
border-radius: 0px;
|
||||
box-shadow: none;
|
||||
vertical-align: middle;
|
||||
vertical-align: middle;
|
||||
}
|
||||
.content figure figcaption>p {
|
||||
font-style: italic;
|
||||
font-size: small;
|
||||
color: #808080;
|
||||
}
|
||||
|
||||
|
||||
|
||||
/* Start section cards. */
|
||||
.toc-cards {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(350px, 1fr));
|
||||
grid-gap: 20px;
|
||||
list-style-type: none;
|
||||
margin-bottom: 24px;
|
||||
}
|
||||
@@ -0,0 +1,178 @@
|
||||
Scene Properties
|
||||
================
|
||||
|
||||
The scene properties panels allow you to manage data that applies to your entire
|
||||
IFC project as a whole, or to multiple elements.
|
||||
|
||||
Building Information Modeling Panel
|
||||
-----------------------------------
|
||||
|
||||
System Setup
|
||||
^^^^^^^^^^^^
|
||||
|
||||
* **Quick Project Setup** - this will create a basic spatial tree. It will
|
||||
create a tree of collections with the structure ``IfcProject > IfcSite >
|
||||
IfcBuilding > IfcStorey`` This is merely for convenience instead of having to
|
||||
create it all by yourself, since all IFC exports require a valid spatial
|
||||
tree. You can see the tree of collections in the outliner when this is done.
|
||||
* **Schema Directory** - this folder stores the current IFC schema. You can
|
||||
download different schemas from the buildingSMART website. Unless you are an
|
||||
IFC guru, you probably shouldn't touch this. BlenderBIM recognises different
|
||||
IFC data based on what is provided in this schema folder. It defaults to the
|
||||
``{{BLENDER_ADDONS_DIR}}/blenderbim/schema/`` folder, which is prepackaged
|
||||
with the IFC4 schema. This is known as the ``{SCHEMA_DIR}``.
|
||||
* **Data Directory** - the data directory holds the auxiliary data related to
|
||||
your IFC model. Examples include related property definitions, documents, and
|
||||
classification systems. Each project should have its own data directory. It
|
||||
defaults to the data directory in the
|
||||
``{{BLENDER_ADDONS_DIR}}/blenderbim/data/`` folder, which comes with some
|
||||
example preset data. You are encouraged to copy this template and set your
|
||||
own. This is known as the ``{DATA_DIR}``.
|
||||
|
||||
Software Identity
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
* **GlobalId** - this field let's you enter an IFC element's ``GlobalId``. It
|
||||
must be in the 22-character encoded form.
|
||||
* **Select GlobalId** - this will select an element that has the same
|
||||
``GlobalId`` attribute as what you have specified, based on what is currently
|
||||
visible in the scene.
|
||||
|
||||
IFC Categorisation
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* **IFC Class** - this dropdown lets you pick from a list of all non-abstract
|
||||
children of ``IfcElement`` and ``IfcSpatialStructureElement``
|
||||
* **IFC Predefined Type** - this dropdown lets you pick from an enumeration of
|
||||
valid ``PredefinedType`` values for the currently selected *IFC Class*. It
|
||||
changes dynamically with the currently selected *IFC Class*.
|
||||
* **IFC Userdefined Type** - this field lets you enter a value for a user
|
||||
defined type. It is stored as the ``ObjectType`` attribute of an
|
||||
``IfcProduct``. It is only set when the **IFC Predefined Type** is set to
|
||||
``USERDEFINED``, otherwise it is ignored. It is recommended to make this
|
||||
value uppercase and alphabetic, to match the conventions for the
|
||||
``PredefinedType`` enumeration.
|
||||
* **Assign Class** - this applies the active *IFC Class*, *IFC Predefined Type*
|
||||
and *IFC Userdefined Type* to any selected objects.
|
||||
* **Select Class** - this will select any objects that are currently visible
|
||||
that also have the same IFC class as the currently active *IFC Class* dropdown.
|
||||
* **Select Type** - same as *Select Class*, but it also filters by the
|
||||
currently active *IFC Predefined Type* dropdown, as well as the *IFC
|
||||
Userdefined Type* field.
|
||||
|
||||
Property Sets
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
- **Pset Name** - this lets you select from a list of available property set
|
||||
types. The list is derived from the folders in
|
||||
``{DATA_DIR}/pset``. Each folder name corresponds to a property set name. If
|
||||
you want to assign properties to an object based on an IFC standard pset,
|
||||
just create a new folder with the same name as the pset. You can also create
|
||||
your own custom property sets, so long as the folder name does not start with
|
||||
``Pset_``, as these are reserved for official IFC property sets.
|
||||
- **Pset File** - this lets you select from a list of available property set
|
||||
data. The available property sets depends on the currently selected *PSet
|
||||
Name* dropdown. Each property set is represented by a ``.csv`` file inside
|
||||
``{DATA_DIR}/pset/{PSET_NAME}/``. You can create your own ``.csv`` files
|
||||
with any software, where each line contains a property name and property
|
||||
value pair. Data types are automatically converted based on the property set
|
||||
templates defined in ``{SCHEMA_DIR}``. If the pset is part of an official IFC
|
||||
standard, you can only use property names that are part of the IFC standard.
|
||||
If you want to add your own custom properties, you will need to create your
|
||||
own *PSet Name* folder first, and then you can put in your own ``.csv`` file
|
||||
which contains any property names and values that you want.
|
||||
- **Assign Pset** - this assigns the currently selected *Pset file* to any
|
||||
selected objects. The assigned data will then be visible in the *Object
|
||||
Properties*. This only assigns a link to the ``.csv`` containing the data, so
|
||||
you can change the data in the ``.csv`` file and that will automatically
|
||||
propagate to all assigned elements when an IFC is exported, without needing
|
||||
to reassign the data.
|
||||
- **Unassign Pset** - this removes the link to the property set ``.csv``
|
||||
file for all currently selected objects.
|
||||
|
||||
Aggregates
|
||||
^^^^^^^^^^
|
||||
|
||||
- **Aggregate Class** - this lets you select what type of class you want an
|
||||
aggregate of parts to be.
|
||||
- **Aggregate name** - this lets you set the name of an aggregate that you can
|
||||
can create.
|
||||
- **Create Aggregate** - this will create a new aggregate from one or more
|
||||
currently selected objects. The selected objects will be moved out of the
|
||||
spatial tree into an ``IfcRelAggregates/*`` collection. Then, a collection
|
||||
instance will be created to represent the aggregation, and will be placed in
|
||||
the current location of the spatial tree, and the The parts will then be
|
||||
hidden so only the whole composition (i.e. the aggregate object) will be shown.
|
||||
- **Explode Aggregate** - this does the opposite of *Create Aggregate*, and
|
||||
will remove the aggregation.
|
||||
- **Edit Aggregate** - this will hide the collection instance that represents
|
||||
the aggregate object, and show all of the individual parts. This allows you
|
||||
to select and modify the aggregate parts.
|
||||
- **Save Aggregate** - this does the opposite of *Edit Aggregate*.
|
||||
|
||||
IFC Classifications Panel
|
||||
-------------------------
|
||||
|
||||
- **Classification** - this lets you select which classification system you'd
|
||||
like to use. The list of possible classification systems is derived from the
|
||||
``{DATA_DIR}/class/classifications.csv`` file. By default, BlenderBIM comes
|
||||
with Uniclass 2015 and Omniclass. If you need another classification system,
|
||||
you can add it to this ``.csv`` file.
|
||||
- **Reference** - this lets you select a single classification reference item,
|
||||
filtered depending on the currently active *Classification*. The list is
|
||||
derived from the ``{DATA_DIR}/class/references.csv`` file. Out of the box,
|
||||
BlenderBIM only lists a single Uniclass reference as an example. It is
|
||||
advised to make a list of all the references you require for a project and
|
||||
add it to this ``.csv`` file.
|
||||
- **Assign Classification** - this assigns the currently active *Reference* to
|
||||
all of the selected objects. You can see the results in the *Object
|
||||
Properties* pane.
|
||||
- **Unassign Classification** - this removes the currently active *Reference*
|
||||
in all of the selected objects.
|
||||
|
||||
IFC Owner History Panel
|
||||
-----------------------
|
||||
|
||||
- **Person** - this lets you select who you are. The values are derived from
|
||||
the ``{DATA_DIR}/owner/person.json`` file, particularly the
|
||||
``Identification`` attribute, which is mandatory and a requirement in COBie
|
||||
data. You are encouraged to edit this file to add your own details. This
|
||||
information will be stored in the IFC file as part of the owner history to
|
||||
keep track of any objects which you edit. You will also be recorded as the
|
||||
author of the IFC file.
|
||||
- **Organisation** - this lets you select which organisation you are part of.
|
||||
The values are derived from the ``{DATA_DIR}/owner/organisation.json`` file,
|
||||
in particular the ``Name`` attribute, which is mandatory and a requirement in
|
||||
COBie data. You are encouraged to edit this file to add your own organisation
|
||||
details. This information will be stored in the IFC file as part of the
|
||||
owner history to keep track of any objects which you edit. The organisation
|
||||
will also be recorded as the author of the IFC file.
|
||||
|
||||
|
||||
IFC Geometric Representation Contexts Panel
|
||||
-------------------------------------------
|
||||
|
||||
- **Has Model Context** - enabling this will allow you to export geometric data
|
||||
related to the model view of your BIM data. This is generally 3D
|
||||
representations. It may also contain wireframe representations such as an
|
||||
Axis model for structural members. This defaults to being enabled, as most
|
||||
people want to export model geometry.
|
||||
|
||||
- **Available Subcontexts** - this lets you select a possible subcontext to
|
||||
be used underneath the Model context.
|
||||
- **Available Target Views** - subcontexts may have a particular target view,
|
||||
which you can set here.
|
||||
- **Add Subcontext** - This will add a new subcontext based on the currently
|
||||
selected *Available Subcontext* and *Available Target View*.
|
||||
|
||||
- **Subcontext Name** - for each subcontext you have added, it will show
|
||||
you the subcontext name. By default, the ``Body`` subcontext is added,
|
||||
as most people want to export the body geometry of products in their BIM data.
|
||||
- **Subcontext Target View** - same as *Subcontext Name*, but shows the
|
||||
target view. By default, the ``MODEL_VIEW`` target view is added, as most
|
||||
people will be viewing the model geometry of your BIM data.
|
||||
- **Remove Subcontext** - this will remove the subcontext.
|
||||
|
||||
- **Has Plan Context** - the same as *Has Model Context*, but it lets you add
|
||||
subcontexts and target views related to the ``PLAN`` context of your BIM
|
||||
data. This is usually plans, sections, RCPs, and other documentation views.
|
||||
@@ -0,0 +1,144 @@
|
||||
# BlenderBIM Add-on - OpenBIM Blender Add-on
|
||||
# Copyright (C) 2020, 2021 Dion Moult <dion@thinkmoult.com>
|
||||
#
|
||||
# This file is part of BlenderBIM Add-on.
|
||||
#
|
||||
# BlenderBIM Add-on is free software: you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation, either version 3 of the License, or
|
||||
# (at your option) any later version.
|
||||
#
|
||||
# BlenderBIM Add-on is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with BlenderBIM Add-on. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
# Configuration file for the Sphinx documentation builder.
|
||||
#
|
||||
# This file only contains a selection of the most common options. For a full
|
||||
# list see the documentation:
|
||||
# https://www.sphinx-doc.org/en/master/usage/configuration.html
|
||||
|
||||
# -- Path setup --------------------------------------------------------------
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
import os
|
||||
|
||||
# import sys
|
||||
# sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
project = "BlenderBIM Add-on"
|
||||
copyright = "2020-2024 IfcOpenShell Contributors"
|
||||
author = "IfcOpenShell Contributors"
|
||||
|
||||
# The full version, including alpha/beta/rc tags
|
||||
cwd = os.path.dirname(os.path.realpath(__file__))
|
||||
with open(os.path.join(cwd, "..", "..", "..", "VERSION"), "r") as f:
|
||||
release = f.read().strip()
|
||||
|
||||
|
||||
# -- General configuration ---------------------------------------------------
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = ["sphinx.ext.autodoc", "sphinx.ext.autosectionlabel", "sphinx_copybutton"]
|
||||
|
||||
# Auto add document prefixes to help guarantee uniqueness of automatic section references.
|
||||
autosectionlabel_prefix_document = True
|
||||
autosectionlabel_maxdepth = 2
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ["_templates"]
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This pattern also affects html_static_path and html_extra_path.
|
||||
exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"]
|
||||
|
||||
|
||||
# -- Options for HTML output -------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
html_theme = "furo"
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ["_static"]
|
||||
|
||||
html_css_files = ["custom.css"]
|
||||
|
||||
# Code block styles. Dark styling helps important code examples "pop" on the
|
||||
# page even on light themes.
|
||||
pygments_style = "one-dark"
|
||||
pygments_dark_style = "one-dark"
|
||||
|
||||
html_logo = "https://blenderbim.org/assets/images/blender/blender-logo.png"
|
||||
html_theme_options = {
|
||||
"source_repository": "https://github.com/IfcOpenShell/IfcOpenShell/",
|
||||
"source_branch": "v0.8.0",
|
||||
"source_directory": "src/blenderbim/docs/",
|
||||
"light_css_variables": {
|
||||
"color-brand-primary": "#39b54a",
|
||||
"color-brand-content": "#39b54a",
|
||||
"color-brand-visited": "#d9e021",
|
||||
"color-background-primary": "#f7f7f6",
|
||||
"color-background-secondary": "#eeeeec",
|
||||
"color-background-border": "#cfd0cb",
|
||||
"color-foreground-primary": "#2e3436",
|
||||
"color-sidebar-item-background--hover": "#f7f7f6",
|
||||
"color-link": "#39b54a",
|
||||
"color-link--visited": "#39b54a",
|
||||
"color-link--hover": "#d98014",
|
||||
"color-link--visited--hover": "#d98014",
|
||||
"color-admonition-text": "#651fff",
|
||||
"font-stack": "Nunito, -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji",
|
||||
},
|
||||
"dark_css_variables": {
|
||||
"color-brand-primary": "#39b54a",
|
||||
"color-brand-content": "#39b54a",
|
||||
"color-brand-visited": "#d9e021",
|
||||
"color-background-primary": "#2e3436",
|
||||
"color-background-border": "#2e3436",
|
||||
"color-foreground-primary": "#eeeeec",
|
||||
"color-sidebar-item-background--hover": "#2e3436",
|
||||
"color-link": "#39b54a",
|
||||
"color-link--visited": "#39b54a",
|
||||
"color-link--hover": "#d98014",
|
||||
"color-link--visited--hover": "#d98014",
|
||||
"color-admonition-text": "#EEEEEC",
|
||||
"font-stack": "Nunito, -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji",
|
||||
},
|
||||
"footer_icons": [
|
||||
{
|
||||
"name": "IfcOpenShell",
|
||||
"url": "https://ifcopenshell.org",
|
||||
"html": """
|
||||
<img src="https://ifcopenshell.org/assets/images/logo.png" style="width: auto;" />
|
||||
""",
|
||||
"class": "",
|
||||
},
|
||||
{
|
||||
"name": "GitHub",
|
||||
"url": "https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/blenderbim/docs",
|
||||
"html": """
|
||||
<svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 16 16">
|
||||
<path fill-rule="evenodd" d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.013 8.013 0 0 0 16 8c0-4.42-3.58-8-8-8z"></path>
|
||||
</svg>
|
||||
""",
|
||||
"class": "",
|
||||
},
|
||||
],
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
@@ -0,0 +1,76 @@
|
||||
Translations
|
||||
============
|
||||
|
||||
The BlenderBIM Add-on supports translations to all languages that Blender
|
||||
supports. We'll describe how you can help translate the add-on as a translator,
|
||||
or how you can ensure your strings are translatable as a developer.
|
||||
Translations are managed using a separate add-on built for this purpose.
|
||||
|
||||
1. Clone the `blenderbim-translations
|
||||
<https://github.com/IfcOpenShell/blenderbim-translations>`_ repository. This
|
||||
repository holds all the core translation strings in ``.po`` format.
|
||||
2. Download the `blenderbim-translations add-on
|
||||
<https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.8.0/src/blenderbim/scripts/bbim_translations.py>`_
|
||||
and install it as a Blender add-on. This add-on lets you convert translation
|
||||
data to and from the ``.po`` files to the BlenderBIM Add-on.
|
||||
3. In the **Render Properties** tab, find the **BlenderBIM Translations**
|
||||
panel, and browse to where you have closed the ``blenderbim-translations``
|
||||
repository, and click on **Setup Translation UI**.
|
||||
|
||||
You should now see a new interface with two buttons.
|
||||
|
||||
.. image:: images/translation-panel.png
|
||||
|
||||
How to translate the add-on
|
||||
---------------------------
|
||||
|
||||
Before beginning, look inside the ``blenderbim-translations`` repository for a
|
||||
``.po`` file for the language you want to translate to (e.g. ``de_DE.po`` for
|
||||
German). If this file does not yet exist, congratulations! You are the first
|
||||
person to translate to this language! Create a folder in
|
||||
``blenderbim-translations`` with your language code and copy the
|
||||
``blenderbim.pot`` language template file to that folder and rename it
|
||||
according to your language (e.g. for German you would copy ``blenderbim.pot`` to
|
||||
``de_DE/de_DE.po``).
|
||||
|
||||
Supported language codes are:
|
||||
|
||||
.. code-block::
|
||||
|
||||
'ca_AD', 'en_US', 'es', 'fr_FR', 'ja_JP', 'sk_SK', 'cs_CZ', 'de_DE',
|
||||
'it_IT', 'ka', 'ko_KR', 'pt_BR', 'pt_PT', 'ru_RU', 'uk_UA', 'vi_VN',
|
||||
'zh_HANS', 'zh_HANT', 'ab', 'ar_EG', 'bg_BG', 'el_GR', 'eo', 'eu_EU',
|
||||
'fa_IR', 'fi_FI', 'ha', 'he_IL', 'hi_IN', 'hr_HR', 'hu_HU', 'id_ID',
|
||||
'ky_KG', 'ne_NP', 'nl_NL', 'pl_PL', 'sr_RS', 'sr_RS@latin', 'sv_SE', 'sw',
|
||||
'ta', 'th_TH', 'tr_TR'.
|
||||
|
||||
As a translator, it is recommended to translate text in bulk by modifying the
|
||||
``.po`` files directly. We recommend installing software such as `Poedit
|
||||
<https://poedit.net/>`_. These translation software offer features such as auto
|
||||
translation, suggestions, and tracking. Alternatively, you may edit the ``.po``
|
||||
file as a text file.
|
||||
|
||||
Once you have edited the relevant language's ``.po`` file, click on the
|
||||
**Update Translations From .po** button in the **BlenderBIM Translations**
|
||||
panel.
|
||||
|
||||
How to add new translation strings
|
||||
----------------------------------
|
||||
|
||||
When you have new strings to translate, press the **Parse BlenderBIM strings to
|
||||
.pot** button. This detects strings in the source code using regex patterns and
|
||||
writes out to the ``blenderbim.pot`` language template file. You may then diff
|
||||
this file and propagate changes manually to all translated ``.po`` files.
|
||||
|
||||
The ``.pot`` file is only used as a blank template for users to create or
|
||||
compare ``.po`` files. The ``.po`` files are the source of truth for
|
||||
translation strings. Blender does not read from the ``.pot`` or ``.po`` files.
|
||||
Instead, Blender reads from ``blenderbim/translations.py`` which contains a
|
||||
dictionary of strings formatted specifically for Blender. The
|
||||
``translations.py`` file is generated from the ``.po`` files. This is generated
|
||||
when we distribute installable packages, or when translators manually press the
|
||||
**Update Translations From .po** button.
|
||||
|
||||
.. warning::
|
||||
|
||||
Do not commit the ``translations.py`` file as it is auto-generated.
|
||||
@@ -0,0 +1,167 @@
|
||||
Contribute to this Manual
|
||||
=========================
|
||||
|
||||
A great way to contribute without writing code is to help writing
|
||||
documentation. Please reach out before contributing as the software is still in
|
||||
an alpha state and portions may not be worth documenting as it changes too
|
||||
frequently.
|
||||
|
||||
Writing technical documentation
|
||||
-------------------------------
|
||||
|
||||
All documentation is written in ReStructured Text and is available in the
|
||||
`BlenderBIM Add-on docs directory
|
||||
<https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/blenderbim/docs>`_.
|
||||
You can press the edit button on the top right on any documentation page to
|
||||
quickly edit their content.
|
||||
|
||||
Links
|
||||
^^^^^
|
||||
|
||||
You can link to
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
`external websites
|
||||
<https://docs.readthedocs.io/en/stable/guides/cross-referencing-with-sphinx.html>`_
|
||||
|
||||
(note the space between the url and the link text). You can also link to
|
||||
sections on the same page, like
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
:ref:`contribute/writing_docs:Writing technical documentation`
|
||||
|
||||
or with
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
:ref:`custom text<contribute/writing_docs:writing technical documentation>`.
|
||||
|
||||
Traditional references like
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
`Writing technical documentation`_
|
||||
|
||||
work too but are discouraged. You can link to other pages, like this:
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
:doc:`Hello World<hello_world>`
|
||||
|
||||
or sections within other pages, like this:
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
:ref:`devs/installation:unstable installation`
|
||||
|
||||
We have ``autosectionlabel`` enabled so it is not necessary to manually create labels. The depth of sections
|
||||
with automatic labels is set to 2, so the third level of titles
|
||||
will not get automatic labels to avoid duplication.
|
||||
|
||||
You can still create labels manually. This way you would ensure links still works when documentation is refactored.
|
||||
|
||||
.. code-block:: restructuredtext
|
||||
|
||||
.. _My label:
|
||||
|
||||
My Section
|
||||
==========
|
||||
|
||||
:ref:`Link to My Section <My label>`
|
||||
|
||||
This link will work across the documentation. Make sure the label is globally unique.
|
||||
|
||||
Images
|
||||
^^^^^^
|
||||
|
||||
The following colours and annotation styles should be used for annotating
|
||||
images. All stroke widths are 3px with a corner radius of 3px. Horizontal
|
||||
underlines are 5px with a corner radius of 2px. The dark green is ``39b54a`` and
|
||||
the light green is ``d9e021``.
|
||||
|
||||
.. image:: images/documentation-style.png
|
||||
|
||||
Special keywords such as **Technical Terminology** that the user should be
|
||||
aware of should be bolded, titlecased, and used consistently. You *may*
|
||||
use italics to emphasize words or phrases. Inline code must be ``quoted`` and
|
||||
longer code snippets may use code blocks.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd /path/to/blenderbim
|
||||
ls
|
||||
|
||||
Be sure to specify the language to enable syntax highlighting.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
print("Hello, world!")
|
||||
|
||||
A button may be used to point users to a critical sample file or
|
||||
download.
|
||||
|
||||
.. container:: blockbutton
|
||||
|
||||
`Visit critical link <https://blenderbim.org>`__
|
||||
|
||||
You can use bulleted lists:
|
||||
|
||||
- Like.
|
||||
- This.
|
||||
|
||||
Or ordered lists:
|
||||
|
||||
1. Like.
|
||||
2. This.
|
||||
|
||||
.. note::
|
||||
|
||||
Instead of writing "Note that XYZ ..." you should use notes sparingly to
|
||||
highlight "gotchas".
|
||||
|
||||
.. tip::
|
||||
|
||||
Tips may be used to add a useful but optional suggestion.
|
||||
|
||||
.. warning::
|
||||
|
||||
Warnings may be used to highlight common mistakes.
|
||||
|
||||
.. seealso::
|
||||
|
||||
See also blocks should be used to reference `further reading
|
||||
<https://blenderbim.org>`__ links.
|
||||
|
||||
Tables can be very annoying to format. You can use a CSV table instead.
|
||||
|
||||
.. csv-table::
|
||||
:header: "Foo", "Bar", "Baz"
|
||||
|
||||
"ABC", "01", "02"
|
||||
"DEF", "03", "04"
|
||||
|
||||
Building documentation
|
||||
----------------------
|
||||
|
||||
If you want to build the documentation locally, the documentation system uses
|
||||
`Sphinx <https://www.sphinx-doc.org/en/master/>`_. First, install the theme and
|
||||
theme dependencies:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install furo
|
||||
pip install sphinx-autoapi
|
||||
pip install sphinx-copybutton
|
||||
|
||||
Now you can generate the documentation:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd /path/to/ifcopenshell/src/blenderbim/docs/
|
||||
make html
|
||||
cd _build/html
|
||||
python -m http.server
|
||||
|
||||
You will now have a local webserver running hosting the documentation.
|
||||
@@ -0,0 +1,20 @@
|
||||
Code style
|
||||
============
|
||||
|
||||
|
||||
Black code formatter
|
||||
-------------------------------
|
||||
For Python code formatting, we use `Black code formatter <https://pypi.org/project/black/>`__ with ``--line-length 120``.
|
||||
|
||||
``black`` can be installed using ``pip install black`` and files can be formatted with the following example command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
black --line-length 120 src/blenderbim/blenderbim/bim/module/qto/operator.py
|
||||
|
||||
Using PowerShell, you can run the Black formatter on the last commit in the repository.
|
||||
You can change ``~1`` to ``~n`` to affect ``n`` commits.
|
||||
|
||||
.. code-block:: powershell
|
||||
|
||||
git diff HEAD HEAD~1 --name-only | where {$_ -like "*.py"} | foreach-object { start $_ && black --line-length 120 $_ }
|
||||
@@ -0,0 +1,29 @@
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
BlenderBIM is an open-source project, and its development is driven by the contributions of a dedicated community of developers,
|
||||
architects, engineers, and enthusiasts. If you're interested in contributing to the project, whether by submitting bug reports,
|
||||
suggesting new features, or contributing code, your involvement is highly encouraged and appreciated.
|
||||
|
||||
This part of the documentation covers various aspects of the BlenderBIM development process, including:
|
||||
|
||||
- :doc:`Writing User Documentation </contribute/writing_docs>`
|
||||
- :doc:`Translations and Internationalisation </contribute/translations>`
|
||||
- Contributing Code
|
||||
- :doc:`Installation and Setting up a Development Environment </devs/installation>`
|
||||
- Understanding the Project Structure and Codebase
|
||||
- :doc:`Hello, World! </devs/hello_world>`
|
||||
- :doc:`Undo System </devs/undo_system>`
|
||||
- :doc:`Code Style Guidelines and Best Practices </devs/code_style>`
|
||||
|
||||
..
|
||||
- :doc:`Submitting Pull Requests and Contributing Code </devs/contributing_code>`
|
||||
|
||||
- :doc:`Testing and Quality Assurance </devs/running_tests>`
|
||||
- :doc:`Running Tests </devs/running_tests>`
|
||||
- :doc:`System Support and Multiplatform Compatibility </devs/system_support>`
|
||||
- :doc:`User Experience and User Interface Guidelines </devs/ux_guidelines>`
|
||||
|
||||
The BlenderBIM Developer Documentation is a living resource maintained by the core development team and the open-source community. It serves as a central hub for developers who want to get involved in the project, ensuring a consistent and efficient development process.
|
||||
|
||||
By contributing to BlenderBIM, you'll not only be helping to improve and expand the capabilities of this powerful open-source BIM authoring platform but also be part of a vibrant community driving innovation in the AEC industry.
|
||||
@@ -0,0 +1,326 @@
|
||||
Hello, world!
|
||||
=============
|
||||
|
||||
The BlenderBIM Add-on takes a unique approach to authoring BIM data. Traditional
|
||||
BIM authoring apps create features that are tailored for a single discipline's
|
||||
paradigm, such as a 3D environment, or a spreadsheet view, and store their data
|
||||
structure in a schema that is unique to their application. In order to
|
||||
interoperate with others, there is an export or import process that translates
|
||||
between their bespoke schema to and from open data standards. The most famous
|
||||
ISO standard for BIM is IFC. After this translation, they then serialise it
|
||||
typically into a format, which may be saved to disk.
|
||||
|
||||
The BlenderBIM Add-on does things differently.
|
||||
|
||||
The BlenderBIM Add-on does not have its own bespoke data structure and does not
|
||||
import or export. The BlenderBIM Add-on uses ISO open data standards directly in
|
||||
memory. Most commonly, this is IFC data. We will place a focus on IFC on this
|
||||
guide, but the reader should be aware that the BlenderBIM Add-on also takes the
|
||||
same approach to dealing with other open data standards, like Brickschema or
|
||||
BCF. The same concepts will apply. We can call this Native OpenBIM authoring,
|
||||
which is a paradigm shift from traditional BIM which relies on translated IFC
|
||||
data.
|
||||
|
||||
.. image:: images/native-openbim.png
|
||||
|
||||
Every user operation reads or writes this data structure in memory, and the IFC
|
||||
data becomes the source of truth for all data. There is no such thing as an
|
||||
import or export. The data is always represented in IFC. When a BIM model is
|
||||
opened or saved, it is simply a serialisation or deserialisation operation. This
|
||||
also means that you are using Blender simply as an interface to interact with
|
||||
IFC, and the ``.blend`` container is largely unnecessary, as nothing of
|
||||
significance is stored in the Blender system, it is simply a snapshot of your
|
||||
working session.
|
||||
|
||||
Due to this significant difference, hacking on the BlenderBIM Add-on requires
|
||||
knowledge not just about how Blender works, but also how open data standards
|
||||
like IFC works.
|
||||
|
||||
Just show me the code!
|
||||
----------------------
|
||||
|
||||
Sometimes, the best way to learn how to hack on a project is to just start
|
||||
hacking away. First, download the code. To keep things simple, you can download
|
||||
the source as a zip file for now, but keep in mind that sooner or later you'll
|
||||
need to :ref:`use Git to collaborate <submitting-code-to-git>`.
|
||||
|
||||
.. container:: blockbutton
|
||||
|
||||
`Download Source
|
||||
<https://github.com/IfcOpenShell/IfcOpenShell/archive/refs/heads/v0.8.0.zip>`__
|
||||
|
||||
BIM authoring is a really big topic. As a result, the BlenderBIM Add-on code is
|
||||
separated into modules. Each module focuses on a particular topic of BIM. Most
|
||||
modules are self-contained, but sometimes they connect to one another, just like
|
||||
how BIM works.
|
||||
|
||||
.. image:: images/module-architecture.png
|
||||
|
||||
Modules are not arbitrary divisions. They tend to reflect how portions of BIM
|
||||
data are segregated in the IFC international standard. This allows us to
|
||||
minimise the overlap between modules, so that developers can work on a single
|
||||
portion of the code with relative certainty that their actions will not affects
|
||||
other developers.
|
||||
|
||||
- `BlenderBIM Add-on modules <https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/blenderbim/blenderbim/bim/module>`__
|
||||
- `IFC modules <https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/ifcopenshell-python/ifcopenshell/api>`__
|
||||
|
||||
The BlenderBIM Add-on comes with a secret **demo module** which is basically a
|
||||
hello world coding tutorial which teaches you about all the moving parts. It's
|
||||
far more interesting to read this code rather than 15 pages of abstract software
|
||||
architecture flow charts and diagrams. The code and its comments will guide you
|
||||
through the process.
|
||||
|
||||
Before playing with the demo module, you may want to switch to using a source
|
||||
installation. See `blenderbim/installation <./installation.html>`_ for details.
|
||||
|
||||
To see the demo module in action, you'll need to enable it. In
|
||||
``src/blenderbim/blenderbim/bim/__init__.py``, uncomment the line for the demo
|
||||
module. When you restart Blender, you will see a new demo panel in your scene
|
||||
properties interface tab. Have fun!
|
||||
|
||||
.. image:: images/demo-module.png
|
||||
|
||||
Now you're ready to learn how to code! Here are all the files associated with
|
||||
the demo module. Feel free to read them in any order. Each file is heavily
|
||||
commented with explanations about what each line of code does. Change some of
|
||||
the code, reload Blender, and see what happens!
|
||||
|
||||
::
|
||||
|
||||
src/blenderbim/blenderbim/bim/module/demo/__init__.py
|
||||
src/blenderbim/blenderbim/bim/module/demo/operator.py
|
||||
src/blenderbim/blenderbim/bim/module/demo/prop.py
|
||||
src/blenderbim/blenderbim/bim/module/demo/ui.py
|
||||
src/blenderbim/blenderbim/bim/module/demo/data.py
|
||||
src/blenderbim/blenderbim/core/demo.py
|
||||
src/blenderbim/blenderbim/tool/demo.py
|
||||
|
||||
|
||||
Wow! That's a lot of files needed for a hello world! Don't worry, it's mostly
|
||||
tutorial comments and it's there to teach you the basics from how Blender's
|
||||
add-on system works, how interfaces work, to how the BlenderBIM Add-on works,
|
||||
and how to test and structure it so that you can build incredibly complex
|
||||
features in a maintainable way.
|
||||
|
||||
Tests for quality checking also exist. The system is designed so that you can
|
||||
do "Test Driven Development". For reference on how to run these tests, see `blenderbim/running_tests <./running_tests.html>`_
|
||||
for details. You can find the tests here:
|
||||
|
||||
::
|
||||
|
||||
src/blenderbim/test/bim/feature/demo.feature
|
||||
src/blenderbim/test/core/test_demo.py
|
||||
src/blenderbim/test/tool/test_demo.py
|
||||
|
||||
Not all developers, especially those learning how to code, are familiar with
|
||||
testing and how to write tests. That's OK! Feel free to ignore the tests at
|
||||
first until you get a bit more comfortable with coding, and others can help
|
||||
guide you when you're ready to make the leap. Don't let this stop you from
|
||||
building things, others can also help write tests for you and clean your code.
|
||||
It's a great way to learn!
|
||||
|
||||
Once you're through, you should be able to understand how most of the BlenderBIM
|
||||
Add-on is built and where to find things.
|
||||
|
||||
There are many Blender Python tutorials out there. A good place to start is the
|
||||
`Start coding for Blender
|
||||
<https://wiki.osarch.org/index.php?title=Start_coding_for_Blender>`__ from the
|
||||
OSArch Wiki. In addition, the Blender text editor comes with a menu called
|
||||
``Templates > Python`` which gives you a whole list of example code of how to
|
||||
create an add-on which creates objects, creates gizmos, new buttons, interfaces,
|
||||
and so on. This is a great way to try out how to build different extensions.
|
||||
|
||||
Naturally, if you just want to tweak the BlenderBIM Add-on or build a small
|
||||
feature just for yourself, you're free to ignore this advice, skip all the
|
||||
tests, and just write half the code in a single file and it'll get the job done.
|
||||
|
||||
Software architecture
|
||||
---------------------
|
||||
|
||||
If code isn't good enough for you and you want to learn more about why the code
|
||||
is structured the way it is, here is a list of design principles we follow:
|
||||
|
||||
1. Big systems are hard to maintain. Break big systems into small systems.
|
||||
2. Separate abstract code from concrete code. Start with abstract code, and
|
||||
deal with the details later.
|
||||
3. Good code reads like poetry. Every usecase should have a poem.
|
||||
4. Separate UI code from domain logic. UI code should be as dumb as possible.
|
||||
5. Follow the Unix philosophy. We're dealing with a big industry problem here.
|
||||
Building a shared ecosystem of tools is better than one behemoth.
|
||||
6. Everything should be testable. You should be able to test first.
|
||||
7. Have different types of tests. Inversely correlate test speed and scope.
|
||||
8. Community first. Allow beginner programmers to join in the fun! Code should
|
||||
feel easy, not like a course in design pattern jargon.
|
||||
9. Incremental change, not waterfall. Don't trash and rebuild. Refactor and
|
||||
redesign one commit at a time. With each commit, ask if you're making the
|
||||
code nicer.
|
||||
10. Perfect is the enemy of the good. Half broken is better than completely
|
||||
broken.
|
||||
|
||||
The rest of this contains nasty software architecture jargon. If that's not your
|
||||
thing, stop reading now.
|
||||
|
||||
The BlenderBIM Add-on code may be understood in three separate layers: **Delivery**,
|
||||
**Domain**, and **Data**. The BlenderBIM Add-on architecture separates these
|
||||
three layers from one another. Because they are separate, they can be tested and
|
||||
built separately.
|
||||
|
||||
.. image:: images/architecture.png
|
||||
|
||||
The **Delivery** mechanism is how the application is delivered to
|
||||
the user and handles user interactions. It covers the interface and triggering
|
||||
events as inputs into the application, and rendering responses.
|
||||
|
||||
As advertised in the name, the **Delivery** mechanism is based on **Blender**.
|
||||
**Blender** is a well established 3D platform. Out of the box, it provides an
|
||||
incredibly advanced interface to allow users to interact with geometry. The
|
||||
delivery mechanism code extends Blender extensively, including new *Operations*
|
||||
that users can perform, new *Properties* to store custom data, and new *UI*
|
||||
layouts to display information.
|
||||
|
||||
When an event such as an *Operation* is triggered, the **Delivery** mechanism
|
||||
executes the **Domain** layer through dependency injection. The **Domain** layer
|
||||
will then decide how to process this input.
|
||||
|
||||
The **Domain** layer is divided into two halves: an abstract *Core* and concrete
|
||||
*Tools*. The *Core* describes abstract, high-level application logic flow for
|
||||
every single possible usecase in application. The *Tools* actually implement
|
||||
this abstract logic, and figure out how things actually work, whether it is
|
||||
manipulating the Blender scene, writing and reading files, building new IFC
|
||||
graph relationships, and so on. The **Domain** layer also has interface classes
|
||||
to describe what it needs.
|
||||
|
||||
Whenever the application needs to remember or store information, it does so
|
||||
using a **Data** repository. The data ensures that stored information confirms
|
||||
to a defined schema and is valid, and can be retrieved later. Some data is
|
||||
stored in Blender, such as information about your working session and active
|
||||
scene. Other data is stored in IFC, such as all the relationships in your BIM
|
||||
model. We mention **Data** specifically because OpenBIM data authoring is such a
|
||||
big aspect of the BlenderBIM Add-on. In fact, it's so big that most of it is
|
||||
completely separated from the BlenderBIM Add-on code and lives elsewhere.
|
||||
|
||||
For example, all the code that handles IFC data, which you can think of as a
|
||||
graph database, is in a completely separate codebase, even under a different
|
||||
software license. You can find it in the IfcOpenShell-python API module. Many of
|
||||
the various data processing functions are built as separate Unix-like utilities,
|
||||
even with their own CLI. This **Data** layer isn't a single folder of code we
|
||||
can point to, it's an ecosystem of libraries and utilities that we want to share
|
||||
with the entire industry.
|
||||
|
||||
IfcOpenShell Architecture
|
||||
-------------------------
|
||||
|
||||
A large part of the BlenderBIM Add-on is understanding how IFC data is modified.
|
||||
This code is not technically part of the the BlenderBIM Add-on codebase, but it
|
||||
is vital to understand. You will need to be familiar with the IfcOpenShell
|
||||
Python module.
|
||||
|
||||
Manipulating IFC data is not simple. IFC may be serialised into multiple
|
||||
formats, multiple schema versions must be supported, and geometry may be defined
|
||||
in a highly parametric or implicit manner, which geometry kernels do not
|
||||
natively support. All this heavy lifting is performed by the IfcOpenShell
|
||||
library.
|
||||
|
||||
The IfcOpenShell library consists of a C++ based core. Its geometry processing
|
||||
is done using OpenCascade, and optionally CGAL as an experimental option. By the
|
||||
time the BlenderBIM Add-on interacts with IFC, it uses the IfcOpenShell Python
|
||||
bindings, so all IFC data is already deserialised into Python objects. The inner
|
||||
workings of the C++ base is out of scope.
|
||||
|
||||
.. image:: images/ifcopenshell-architecture.png
|
||||
|
||||
IfcOpenShell offers a core set of low-level functionality to read and write this
|
||||
data. An example of the core functionality would be:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import ifcopenshell
|
||||
model = ifcopenshell.open("foo.ifc")
|
||||
wall = model.create_entity("IfcWall")
|
||||
wall.Name = "Foobar"
|
||||
|
||||
Core functions are simple read and write operations with no post processing.
|
||||
Core functions also include geometry processing, which converts IFC geometry
|
||||
into OpenCascade objects.
|
||||
|
||||
Sometimes, there are repetitive actions that need to be performed. These
|
||||
functions are grouped into a ``util`` module. These include utility functions
|
||||
for coordinate calculations, date conversions, filtering elements, unit
|
||||
conversions, and more. Utility functions make no assumption about the context in
|
||||
which they are used, and so perform highly specific tasks and nothing else.
|
||||
Here's an example of utility functionality:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import ifcopenshell
|
||||
import ifcopenshell.util.date
|
||||
import ifcopenshell.util.geolocation
|
||||
start = ifcopenshell.util.date.ifc2datetime(task_time.ScheduleStart)
|
||||
coordinates = ifcopenshell.util.geolocation.local2global(matrix, eastings, ...)
|
||||
|
||||
When authoring, core and utility functions are usually too low-level. To cater
|
||||
for this, a high level API is provided. The API is divided into mostly isolated
|
||||
modules, each module representing a distinct set of concepts in the IFC schema.
|
||||
Unlike the util module, these API modules are highly context-sensitive, and
|
||||
assume that you intend to be authoring native IFC.
|
||||
|
||||
This context-sensitive assumption means that the functions within the modules
|
||||
are designed around typical usecases in an authoring environment. It performs
|
||||
all the necessary manipulations to achieve a domain-specific usecase. Authoring
|
||||
is complex and requires a deep knowledge of IFC to perform correctly and ensure
|
||||
that the IFC graph state is well maintained. Typically, any authoring operation
|
||||
that does not use the API is likely to contain mistakes.
|
||||
|
||||
Here's an example of it in action:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import ifcopenshell.api
|
||||
ifcopenshell.api.run("grid.create_grid_axis", model, ...)
|
||||
ifcopenshell.api.run("structural.add_structural_load", model, ...)
|
||||
|
||||
Because the API performs all the IFC manipulations to achieve a usecase, no
|
||||
further interaction is required in a typical native IFC authoring environment.
|
||||
For this reason, the BlenderBIM Add-on only interacts with the API for its
|
||||
authoring capabilities.
|
||||
|
||||
The code for IfcOpenShell's various systems can be found here:
|
||||
|
||||
- `ifcopenshell (core) <https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/ifcopenshell-python/ifcopenshell>`__
|
||||
- `ifcopenshell.util <https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/ifcopenshell-python/ifcopenshell/util>`__
|
||||
- `ifcopenshell.api <https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/ifcopenshell-python/ifcopenshell/api>`__
|
||||
|
||||
.. _submitting-code-to-git:
|
||||
|
||||
Submitting code to Git
|
||||
----------------------
|
||||
|
||||
So, you've written some code, fixed a bug, made an improvement, and would like
|
||||
to get your code added to the Git repository? If your change is relatively
|
||||
small, you can submit your changes just using the Github website. Browse to the
|
||||
`IfcOpenShell repository <https://github.com/ifcopenshell/ifcopenshell>`__ and
|
||||
navigate to the file you want to edit the code of. Then just press the edit icon
|
||||
to begin editing. When you're done, you'll be prompted to submit your changes.
|
||||
|
||||
.. image:: images/github-editing.png
|
||||
|
||||
If you're making a large change, you'll need to create a **Pull Request**.
|
||||
Github has an excellent comprehensive guide on `how to contribute to projects
|
||||
<https://docs.github.com/en/get-started/quickstart/contributing-to-projects>`__
|
||||
which you can follow.
|
||||
|
||||
If you make regular contributions, you are also welcome to officially join the
|
||||
IfcOpenShell developer team, where you'll be able to make changes without
|
||||
waiting for code reviews and approvals.
|
||||
|
||||
Asking for help
|
||||
---------------
|
||||
|
||||
It's no fun to code alone! It's encouraged to reach out if there are any issues,
|
||||
if you'd like to code together with another developer, need a code review, or
|
||||
need further testing. Here are some places to reach out:
|
||||
|
||||
- `Github issues <https://github.com/IfcOpenShell/IfcOpenShell/issues>`__
|
||||
- `OSArch live chat <https://osarch.org/chat>`__
|
||||
- `OSArch community forum <https://community.osarch.org>`__
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
File diff suppressed because it is too large
Load Diff
|
After Width: | Height: | Size: 85 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 9.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
@@ -0,0 +1,179 @@
|
||||
Installation
|
||||
============
|
||||
|
||||
There are different methods of installation, depending on your situation.
|
||||
|
||||
1. **Unstable installation** is recommended for power users helping with testing.
|
||||
2. **Bundling for Blender** is recommended for distributing the add-on.
|
||||
3. **Live development environment** is recommended for developers who are actively coding.
|
||||
4. **Packaged installation** is recommended for those who use a package manager.
|
||||
|
||||
Unstable installation
|
||||
---------------------
|
||||
|
||||
**Unstable installation** is almost the same as **Stable installation**, except
|
||||
that they are typically updated every day. Simply download a daily build from
|
||||
the `GitHub releases page
|
||||
<https://github.com/IfcOpenShell/IfcOpenShell/releases?q=blenderbim&expanded=true>`__,
|
||||
then follow the usual :doc:`installation
|
||||
instructions</users/quickstart/installation>`.
|
||||
|
||||
The BlenderBIM Add-on officially supports all major 64-bit platforms, as well as
|
||||
the Python version shipped by the Blender Foundation for the most recent three
|
||||
major Blender versions:
|
||||
|
||||
- 64-bit Linux (``linux-x64``)
|
||||
- 64-bit MacOS Intel (``macos-x64``)
|
||||
- 64-bit MacOS Silicon (``macos-arm64``)
|
||||
- 64-bit Windows (``windows-x64``)
|
||||
- Blender 4.2 with Python 3.11
|
||||
|
||||
Due to significant changes in the Blender extensions system, Blender versions
|
||||
<4.2 are not supported.
|
||||
|
||||
Developer builds may exist for different versions of Python but there will be
|
||||
no guarantee of the uptime or stability of these builds.
|
||||
|
||||
Other system specifications match the `Blender Requirements
|
||||
<https://www.blender.org/download/requirements/>`_ and the `VFX Platform
|
||||
<https://vfxplatform.com/>`_ standard.
|
||||
|
||||
Sometimes, a build may be delayed, or contain broken code. We try to avoid this,
|
||||
but it happens.
|
||||
|
||||
Bundling for Blender
|
||||
--------------------
|
||||
|
||||
Instead of waiting for an official release on the BlenderBIM Add-on website, it
|
||||
is possible to make your own Blender add-on from the bleeding edge source code
|
||||
of BlenderBIM. BlenderBIM is coded in Python and doesn't require any
|
||||
compilation, so this is a relatively easy process.
|
||||
|
||||
Note that the BlenderBIM Add-on does depend on IfcOpenShell, and IfcOpenShell
|
||||
does require compilation. The following instructions will use a pre-built
|
||||
IfcOpenShell (using an IfcOpenBot build) for convenience. Instructions on how to
|
||||
compile IfcOpenShell is out of scope of this document.
|
||||
|
||||
You can create your own package by using the Makefile as shown below. You can
|
||||
choose between a ``PLATFORM`` of ``linux``, ``macos``, ``macosm1``, and ``win``.
|
||||
You can choose between a ``PYVERSION`` of ``py312``, ``py311``, ``py310``, or
|
||||
``py39``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd src/blenderbim
|
||||
make dist PLATFORM=linux PYVERSION=py311
|
||||
ls dist/
|
||||
|
||||
This will give you a fully packaged Blender add-on zip that you can distribute
|
||||
and install.
|
||||
|
||||
Live development environment
|
||||
----------------------------
|
||||
|
||||
One option for developers who want to actively develop from source is to follow
|
||||
the instructions from :ref:`devs/installation:Bundling for Blender`. However,
|
||||
creating a build, uninstalling the old add-on, and installing a new build is a
|
||||
slow process. Although it works, it is very slow, so we do not recommend it.
|
||||
|
||||
A more rapid approach is to follow the :ref:`devs/installation:Unstable
|
||||
installation` method, as this provides all dependencies for you out of the box.
|
||||
|
||||
Once you've done this, you can replace certain Python files that tend to be
|
||||
updated frequently with those from the Git repository. We're going to use
|
||||
symbolic links, so we can code in our Git repository, and see the changes in
|
||||
our Blender installation (you will need to restart Blender to see changes).
|
||||
|
||||
For Linux or Mac:
|
||||
|
||||
.. literalinclude:: ../../scripts/installation/dev_environment.sh
|
||||
:language: bash
|
||||
:caption: dev_environment.sh
|
||||
|
||||
Or, if you're on Windows, you can use the batch script below. You need to run
|
||||
it as an administrator. Before running it follow the instructions descibed
|
||||
in the `rem` tags.
|
||||
|
||||
.. literalinclude:: ../../scripts/installation/dev_environment.bat
|
||||
:language: bat
|
||||
:caption: dev_environment.bat
|
||||
|
||||
After you modify your code in the Git repository, you will need to restart
|
||||
Blender for the changes to take effect.
|
||||
|
||||
The downside with this approach is that if a new dependency is added, or a
|
||||
compiled dependency version requirement has changed, or the build system
|
||||
changes, you'll need to fix your setup manually. But this is relatively rare.
|
||||
Reviewing the Makefile history, `here <https://github.com/IfcOpenShell/IfcOpenShell/commits/v0.8.0/src/blenderbim/Makefile>`__, is one quick way to see if a dependency has changed.
|
||||
|
||||
.. seealso::
|
||||
|
||||
There is a `useful Blender Addon
|
||||
<https://blenderartists.org/uploads/short-url/yto1sjw7pqDRVNQzpVLmn51PEDN.zip>`__
|
||||
(see `forum thread
|
||||
<https://blenderartists.org/t/reboot-blender-addon/640465/13>`__) that adds
|
||||
a Reboot button in File menu. In this way, it's possible to directly
|
||||
restart Blender and test the modified source code. There is also a VS Code
|
||||
add-on called `Blender Development
|
||||
<https://marketplace.visualstudio.com/items?itemName=JacquesLucke.blender-development>`__
|
||||
that has a similar functionality.
|
||||
|
||||
|
||||
Packaged installation
|
||||
---------------------
|
||||
|
||||
- **Arch Linux**: `Direct from Git <https://aur.archlinux.org/packages/ifcopenshell-git/>`__.
|
||||
- **Chocolatey on Windows**: `Unstable <https://community.chocolatey.org/packages/blenderbim-nightly/>`__.
|
||||
|
||||
Tips for package managers
|
||||
-------------------------
|
||||
|
||||
The BlenderBIM Add-on is fully contained in the ``blenderbim/`` subfolder of the
|
||||
Blender add-ons directory. This is typically distributed as a zipfile as per
|
||||
Blender add-on conventions. Within this folder, you'll find the following file
|
||||
structure:
|
||||
::
|
||||
|
||||
core/ (Blender agnostic core logic)
|
||||
tool/ (Blender specific shared functionality)
|
||||
bim/ (Blender specific UI)
|
||||
libs/ (other assets)
|
||||
wheels/ (dependencies)
|
||||
__init__.py
|
||||
|
||||
This corresponds to the structure found in the source code `here
|
||||
<https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/blenderbim/blenderbim>`__.
|
||||
|
||||
The BlenderBIM Add-on is complex, and requires many dependencies, including
|
||||
Python modules, binaries, and static assets. When packaged for users, these
|
||||
dependencies are bundled with the add-on for convenience.
|
||||
|
||||
If you choose to install the BlenderBIM Add-on and use your own system
|
||||
dependencies, the source of truth for how dependencies are bundled are found in
|
||||
the `Makefile
|
||||
<https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.8.0/src/blenderbim/Makefile>`__
|
||||
in the ``dist`` target.
|
||||
|
||||
Add-on compatibility
|
||||
--------------------
|
||||
|
||||
The BlenderBIM Add-on is a non-trivial add-on. By turning Blender into a
|
||||
graphical front-end to a native IFC authoring platform, some fundamental Blender
|
||||
features (such as hotkeys for basic functionality like object deletion or
|
||||
duplication) have been patched and many dependencies have been introduced.
|
||||
|
||||
Other add-ons may no longer work as intended when the BlenderBIM Add-on is
|
||||
enabled, or vice versa, the BlenderBIM Add-on may no longer work as intended
|
||||
when other add-ons are enabled.
|
||||
|
||||
Known scenarios which will lead to add-on incompatibility include:
|
||||
|
||||
- The add-on also overrides the same hotkeys. For example, if an add-on
|
||||
overrides the "X" key to delete an object, you will need to manually trigger
|
||||
(either via menu or custom hotkey) the BlenderBIM Add-on equivalent operator
|
||||
(e.g. IFC Delete).
|
||||
- The add-on uses object deletion or duplication macros with dictionary
|
||||
override. Note that this is also deprecated in Blender, so the other add-on
|
||||
should be updated to fix this.
|
||||
- The add-on requires a conflicting dependency, or a conflicting version of the
|
||||
same dependency. Neither add-on may work simultaneously.
|
||||
@@ -0,0 +1,136 @@
|
||||
.. _blenderbim/running_tests:
|
||||
|
||||
Running tests
|
||||
=============
|
||||
|
||||
The BlenderBIM Add-on has three layers of tests for each of its three technology
|
||||
layers:
|
||||
|
||||
1. **Core tests**: abstract domain logic unit tests agnostic of Blender
|
||||
2. **Tool tests**: low-level concrete unit tests dependent on Blender
|
||||
3. **BIM tests**: high-level integration UI and smoke tests dependent on Blender
|
||||
|
||||
These tests use ``pytest`` as the test framework and runner, so install it:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install pytest
|
||||
|
||||
All development is expected to use test driven development, and so we expect
|
||||
test coverage to be 100% where it is technically possible to test.
|
||||
|
||||
When running tests, Makefile targets are provided for convenience so you can
|
||||
type in a simple command without knowing the internals. This means you can run
|
||||
tests by using the ``make`` command.
|
||||
|
||||
Because the BlenderBIM Add-on depends on IfcOpenShell, it is advised to also run
|
||||
tests for IfcOpenShell and its Python bindings, which is not covered in this
|
||||
document.
|
||||
|
||||
Core tests
|
||||
----------
|
||||
|
||||
The core layer tests are pure Python unit tests with no dependencies on Blender
|
||||
or other modules. They are designed to be fast and easy to run as they test
|
||||
purely abstract domain logic.
|
||||
|
||||
Although they are vanilla Python tests, they do not use the Python Mock module.
|
||||
Instead, a lightweight ``Prophecy`` mocker class is used, which allows tests to
|
||||
be written in a highly concise, expressive manner. For those coming from a
|
||||
BDD background in Ruby's RSpec, PHP's PHPSpec, and PHP's Prophecy, this is very
|
||||
similar.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd src/blenderbim/
|
||||
make test-core
|
||||
# If you're on Windows, and don't want to use make, use:
|
||||
pytest -p no:pytest-blender test/core
|
||||
|
||||
Tool tests
|
||||
----------
|
||||
|
||||
The tool layer tests actual concrete functions. You will need to install the
|
||||
following dependencies:
|
||||
|
||||
* pytest-blender, accessible to your system's Python
|
||||
* Blender executable, accessible to pytest-blender on your system's Python
|
||||
(e.g. through the ``blender`` command in your path)
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install pytest-blender
|
||||
# Check that "Blender" is in your system's path
|
||||
blender
|
||||
|
||||
On Windows, you can add Blender to the system path by doing:
|
||||
|
||||
1. Open the start menu and launch **Control Panel** > **System** > **Edit the
|
||||
system environment variables**
|
||||
2. In the **System Properties** window, under the **Advanced** tab press
|
||||
**Environment Variables**. This will open a dialog showing a list of all your
|
||||
variables.
|
||||
3. In the **System Variables** section select the entry named **Path**, and
|
||||
press **Edit...**. This will open a new dialog showing all the directories
|
||||
stored in the **Path** variable.
|
||||
4. Press **New** and browse to the directory where your **blender.exe** is
|
||||
located, such as in ``C:\Program Files\Blender Foundation\Blender 3.2``.
|
||||
|
||||
In addition, you will need to install these dependencies for Blender:
|
||||
|
||||
* pytest, accessible to your Blender Python
|
||||
* pytest-bdd, accessible to your Blender Python
|
||||
|
||||
You can install the dependencies by running the ``setup_pytest.py`` script in
|
||||
Blender:
|
||||
|
||||
1. Launch Blender
|
||||
2. Load ``src/blenderbim/scripts/setup_pytest.py`` in the Blender text editor
|
||||
3. Run the script by pressing ``Text > Run Script``.
|
||||
4. Check the Blender console for any errors or success messages.
|
||||
|
||||
.. warning::
|
||||
|
||||
The ``scripts/setup_pytest.py`` may not work for all operating systems and
|
||||
installation environments. In this case, you may be required to install the
|
||||
dependencies manually.
|
||||
|
||||
Please be aware that some Blender may come packaged with its own Python,
|
||||
which may be separate to the Python installation on your system. Be sure to
|
||||
install the dependencies to the correct Python environment.
|
||||
|
||||
Then, run the tests. This will launch Blender headlessly and check the behaviour
|
||||
of all concrete functions.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd src/blenderbim/
|
||||
make test-tool # Test everything
|
||||
make test-tool MODULE=foo # Only test a single module
|
||||
# If you're on Windows, and don't want to use make, use:
|
||||
pytest test/tool # Test everything
|
||||
pytest test/tool/test_foo.py # Only test a single module
|
||||
|
||||
BlenderBIM Add-on tests
|
||||
-----------------------
|
||||
|
||||
The BIM layer acts as a full integration test. It is not possible to fully test
|
||||
the UI, as we cannot reliably emit interface signals, nor read the interface as
|
||||
a DOM of sorts. The best we can do is to call Blender operators as a smoke test,
|
||||
and also check simple property and scene changes.
|
||||
|
||||
Before running these tests, follow the instructions for running tool tests
|
||||
above.
|
||||
|
||||
You will also need to enable the **Sun Position** add-on, as it is required to
|
||||
test georeferencing features: ``Edit > Preferences > Add-ons`` and enable
|
||||
**Lighting: Sun Position**.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd src/blenderbim/
|
||||
make test-bim # Test everything
|
||||
make test-bim MODULE=foo # Only test a single module
|
||||
# If you're on Windows, and don't want to use make, use:
|
||||
pytest test/bim # Test everything
|
||||
pytest test/bim -m "foo" ./ --maxfail=1 # Only test a single module
|
||||
@@ -0,0 +1,117 @@
|
||||
Undo system
|
||||
===========
|
||||
|
||||
Supporting undo and redo is quite a complex problem because the Blender undo
|
||||
system only keeps track of changes occurring in the Blender system. However,
|
||||
changes actually occur in two other locations that Blender doesn't know about:
|
||||
the IFC dataset, and the BlenderBIM Add-on system that synchronises Blender and
|
||||
the IFC dataset.
|
||||
|
||||
Let's see how undo works in a basic Blender add-on without IFC or the BlenderBIM
|
||||
Add-on getting involved.
|
||||
|
||||
.. code-block:: python
|
||||
:emphasize-lines: 4
|
||||
|
||||
class Foobar(bpy.types.Operator):
|
||||
bl_idname = "foobar"
|
||||
bl_label = "Foobar"
|
||||
bl_options = {"REGISTER", "UNDO"}
|
||||
|
||||
def execute(self, context):
|
||||
context.scene.name = "Foobar"
|
||||
return {"FINISHED"}
|
||||
|
||||
This operation changes Blender data. The important line is ``bl_options =
|
||||
{"REGISTER", "UNDO"}``, which tells Blender to keep track of it as a single
|
||||
transaction in its undo history. When you press undo or redo, Blender figures
|
||||
out all the changes automatically and you don't need to do anything.
|
||||
|
||||
If you have an operator that only manipulates (creates, removes, or edits)
|
||||
Blender data, this solution is sufficient.
|
||||
|
||||
Now let's look at pure IfcOpenShell.
|
||||
|
||||
.. code-block:: python
|
||||
:emphasize-lines: 3,5
|
||||
|
||||
import ifcopenshell
|
||||
model = ifcopenshell.open("foo.ifc")
|
||||
model.begin_transaction()
|
||||
model.create_entity("IfcWall")
|
||||
model.end_transaction()
|
||||
model.undo()
|
||||
model.redo()
|
||||
|
||||
Pure IfcOpenShell let's you start and stop recording transactions whenever you
|
||||
want. Since IfcOpenShell has no interface, you manually run code like
|
||||
``model.undo()`` and ``model.redo()`` to undo and redo.
|
||||
|
||||
This scenario where there is pure IfcOpenShell never occurs with the BlenderBIM
|
||||
Add-on. Instead, stuff happens in Blender operators.
|
||||
|
||||
.. code-block:: python
|
||||
:emphasize-lines: 6,7
|
||||
|
||||
class Foobar(bpy.types.Operator):
|
||||
bl_idname = "foobar"
|
||||
bl_label = "Foobar"
|
||||
bl_options = {"REGISTER", "UNDO"}
|
||||
|
||||
def execute(self, context):
|
||||
return IfcStore.execute_ifc_operator(self, context)
|
||||
|
||||
def _execute(self, context):
|
||||
ifcopenshell.api.run("foo.bar", IfcStore.get_file())
|
||||
return {"FINISHED"}
|
||||
|
||||
When your operator manipulates (creates, removes, or edits) IFC data directly or
|
||||
indirectly (i.e. through calling another operator), your operator must be
|
||||
wrapped in an ``IfcStore.execute_ifc_operator`` call. This wrapper will:
|
||||
|
||||
1. Begin a BlenderBIM Add-on transaction
|
||||
2. Begin an IfcOpenShell transaction
|
||||
3. Runs your operator's ``_execute``.
|
||||
4. Ends the IfcOpenShell transaction
|
||||
5. Ends the BlenderBIM Add-on transaction
|
||||
|
||||
The IfcOpenShell transaction keeps track of IFC data changes, and the BlenderBIM
|
||||
Add-on transaction keeps track of all other custom data changes, like changes in
|
||||
the ``id_map`` and ``guid_map``. For the vast majority of operations, this
|
||||
wrapper provides everything that you need.
|
||||
|
||||
If, however, your operator manipulates data that is not tracked by Blender, is
|
||||
not tracked in the IFC data, and is not tracked in the element map, then you
|
||||
will have to write your own rollback (undo) and commit (redo) code for your
|
||||
operator. Here is an example.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class Foobar(bpy.types.Operator):
|
||||
bl_idname = "foobar"
|
||||
bl_label = "Foobar"
|
||||
bl_options = {"REGISTER", "UNDO"}
|
||||
|
||||
def execute(self, context):
|
||||
IfcStore.begin_transaction(operator)
|
||||
old_value = Foo.bar
|
||||
result = self._execute(context)
|
||||
new_value = Foo.bar
|
||||
self.transaction_data = {"old_value": old_value, "new_value": new_value}
|
||||
IfcStore.add_transaction_operation(self)
|
||||
IfcStore.end_transaction(operator)
|
||||
return result
|
||||
|
||||
def _execute(self, context):
|
||||
Foo.bar = "baz"
|
||||
return {"FINISHED"}
|
||||
|
||||
def rollback(self, data):
|
||||
Foo.baz = data["old_value"]
|
||||
|
||||
def commit(self, data):
|
||||
Foo.baz = data["new_value"]
|
||||
|
||||
Note that there is still a distinction between ``execute`` and ``_execute``.
|
||||
This recommended convention allows you to quickly discern undo state tracking
|
||||
code from regular operation code.
|
||||
@@ -0,0 +1,178 @@
|
||||
User Experience and User Interface guidelines
|
||||
=============================================
|
||||
|
||||
This is intended as a reference document for developers working on the BlenderBim addon.
|
||||
|
||||
Operators
|
||||
^^^^^^^^^
|
||||
|
||||
BIM will by definition contain a (big) number of submodules or subschemas. Granting access to the features of these submodules to the users needs to be considered with several things in minds :
|
||||
|
||||
1. Ease of use : How do I achieve my goal with the minimal number of clicks ? How many different menu items do I have to go through to get to my goal ? How long do I have to scroll a menu to get to the specific thing I have in mind ?
|
||||
|
||||
2. Clarity : How long do I have to visually parse the interface to find the item or button I'm looking for ? Are the buttons correctly labeled and are the icons descriptive enough ? If something is forbidden, can I easily know why ? Can I know what a button does before clicking on it ?
|
||||
|
||||
3. Completeness : I need to have access to all the items that are related to the topic I'm interested in. If it is tied to another submodule, I need to have access to it.
|
||||
|
||||
* **Blender**
|
||||
|
||||
These considerations must be adapted to the Python API, to the general paradigm we have chosen to access, modify or create IFC data, and to the general philosophy of Blender. There are many ways and places where an add-on creator can choose to present information to the user. BlenderBim currently works that way :
|
||||
|
||||
- Information about the current context is displayed inside the properties editor. We leverage the fact that it is already built around displaying different types of information whether we are in the Scene, Material, Mesh, Object, Curve, Texture, etc. subpanels. It fits really well with the way things are already organized in the IFC classification.
|
||||
|
||||
- Tools to create, modify or delete items are in the dedicated Toolbar (The left one) in the 3D viewport
|
||||
|
||||
- Some Misc tools and information are displayed in the N panel of the 3D viewport . They're shortcuts to things that are already present elsewhere in the UI, but are handy to have when modifying objects or geometry in the Viewport.
|
||||
|
||||
- Adding specific Import / Export IFC operators (arguably a bit misleading since BlenderBim does more than import / export in these operations)
|
||||
|
||||
* **Interface panels**
|
||||
|
||||
- The good : Every submodule is visually separated from each other. The user can customize its interface to only show what's relevant to them at any one point by folding in or out panels. Development / Debugging is facilitated because each submodule's interface is separated from the others.
|
||||
|
||||
- The bad : Having many interface panels clutters the interface, leading to an overwhelming experience for newcomers especially.
|
||||
|
||||
- Proposal : The addon should in the long run provide the user with dynamic UI depending on what's their usecase. Preferably accessed in the Addon Preferences interface, with pre-made options that dynamically enable or disable specific parts of the UI. It should also provide the option to selectively add or remove specific parts of the UI on top of that. Additionally, when it does not make sense to display a specific panel, it should be hidden from the UI. (eg if an object has no IFC Class, it can't be spatially contained, so the IFC Spatial Container panel should be hidden until the user sets the IFC class)
|
||||
In the long term it could also be interesting to think about some kind of tutorial mode where more information is conveyed through the interface for new users.
|
||||
|
||||
* **Item Lists**
|
||||
|
||||
An item list should provide right off the bat a few features :
|
||||
|
||||
- Add a new item.
|
||||
|
||||
- Modify an item, whether by adding a button to each item in the list, or adding a button on the list header to modify the selected item.
|
||||
|
||||
- Delete an item, whether by adding a button to each item in the list, or adding a button on the list header to delete the selected item.
|
||||
|
||||
- Modify an item's name by double-clicking on the field if applicable
|
||||
|
||||
- The currently selected item should be highlighted
|
||||
|
||||
- There should be a search field to filter through specific items in the list, with buttons to invert selection, sort alphabetically and revert display. (Features that are provided by the `UIList` class)
|
||||
|
||||
* **Operators**
|
||||
|
||||
- Some buttons should be dynamically disabled (grayed out and impossible to click on) when the context to execute them does not make sense. It is important to note there should not be any heavy computation to determine this since this is executed several times per second for each button where it is implemented. It should only test for simple things and not rely on retrieving information from other modules too much. eg : `Is an item selected ?` `Is the z position of the selected object > 0 ?` or `Is the selected object an IfcOpeningElement ?` and **not** `Is there an IfcOpeningElement in the current file ?` or `How many different classes of IfcBeam are implemented in the file ?`
|
||||
In Blender this is done in two ways :
|
||||
|
||||
- Directly in the operator `poll` method which is executed when the button is displayed in the interface. The drawback is that some operators rely on custom attributes which are provided only when the user clicks on the button, and cannot be test in the `poll` method. Note in V3.0 we can implement custom messages when the `poll` method fails, depending on the step where the context was not right.
|
||||
|
||||
- In the UI drawing code, where specific layout parts can be disabled.
|
||||
|
||||
- Some buttons or entire interface layout rows or columns may be disabled or hidden at once. It may be desirable when it relies on specific things or combinations of things not being met in the project. In order to avoid UI flicker or the user wondering where the button went, dynamically hiding UI elements should have a minimal interference with the rest of the UI by :
|
||||
|
||||
(1) Hiding the last row(s) of a panel
|
||||
|
||||
(2) Dynamically resizing the rest of the UI when it's not possible to (1)
|
||||
|
||||
The user should be advised why they are prevented to do things via either :
|
||||
|
||||
- A custom message using Blender's report system
|
||||
|
||||
- A label in the UI replacing the missing UI elements
|
||||
|
||||
- A helpful tooltip on an operator
|
||||
|
||||
Generally the context itself should be used to the best of its ability to convey why it's possible to do some things or not. The separation of concerns in multiple different dynamically hidden-or-shown sub-panels should help limit confusion.
|
||||
|
||||
- The user should be forbidden to click on buttons when its execution returns early and does nothing. If a button is clickable and the user clicks on it, there should always be some kind of feedback.
|
||||
|
||||
Icons
|
||||
^^^^^
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137270452-bf6c03ea-2d3e-4ae3-8121-6799e8beb335.png
|
||||
|
||||
**Icon name** : `"CANCEL"`
|
||||
|
||||
**Use** : To disable the edition state of a particular item.
|
||||
|
||||
**Expected result** : A part of the interface showing the item attributes is either shrunk down or hidden. The button is usually replaced by a button to delete this item.
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137271575-dcae9e56-3c64-4d8b-89b0-6cf103b999f2.png
|
||||
|
||||
**Icon name** : `"X"`
|
||||
|
||||
**Use** : To delete a particular item, for instance an element of a list.
|
||||
|
||||
**Expected result** : The interface element referencing the deleted item is hidden from the interface. If the item was in a list, and the deleted element was selected, the next element becomes selected, or if there is no next element, no element is selected.
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137271601-e79012e5-fc61-402e-830c-b34b4ca757a0.png
|
||||
|
||||
**Icon name** : `"GREASEPENCIL"`
|
||||
|
||||
**Use** : To Enable the edition of a particular item.
|
||||
|
||||
**Behaviour** : Usually only one element of a particular context can be edited at a time.
|
||||
|
||||
**Expected result** : The interface should either expand or spawn new elements to display the chosen item's editable attributes. If the editem item is part of a list and its interface elements contained an operator to delete it, it is swapped for an operator to disable the edition of that item.
|
||||
|
||||
**Proposal** : Currently all the edition buttons are hidden from the interface when editing a particular item. This results on buttons jumping to the right slightly. My proposal is to instead show but disable the other buttons to prevent interface flicker.
|
||||
|
||||
**Current** : https://user-images.githubusercontent.com/25156105/137273603-f9ac39e5-7616-4fb9-89e2-4dae453e650a.gif
|
||||
|
||||
**Proposal** : https://user-images.githubusercontent.com/25156105/137273329-532d6d59-e39d-483e-980b-b8405062eaa8.gif
|
||||
|
||||
.. image:: https://user-images.githubusercontent.com/25156105/137273981-26fa664a-a29e-402e-9d7e-67b8b71c2d5d.png
|
||||
|
||||
* **Icon name** : `"ADD"`
|
||||
|
||||
**Use** : To add an item to a particular context, either initializing it (eg. adding a coordinate system) or adding an element to a list.
|
||||
|
||||
**Expected result** : The interface should either expand to display the new item or a new line should be shown if the item is added in a list.
|
||||
|
||||
**Proposal** : In some instances adding an element in a list automatically enables the edition of this item's attributes. (eg IFC Groups) but in other instances it does not (eg IFC strucural load cases). It is arguable but I do not think the user should expect a new item to be in editable state right off the bat when they add it to a list.
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137274869-0d0b876a-545c-4a58-a386-90f85764b7cc.png
|
||||
|
||||
**Icon name** : `"RESTRICT_SELECT_OFF"`
|
||||
|
||||
**Use** : To select all the instances related to a particular item.
|
||||
|
||||
**Expected result** : All the objects relating to a particular item should be selected in the 3D viewport and/or in the outline.
|
||||
|
||||
**Proposal** : Whether or not previously selected objects should be deselected beforehand is up for debate I think, because both behaviours can be desirable. It also raises the question of which object should be set to active. (Random ? First one ? Biggest one ?...)
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137275582-98c1dfcc-fc96-41d6-80dd-fdb82796e66e.png
|
||||
|
||||
**Icon name** : `"IMPORT"`
|
||||
|
||||
**Use** : to import a particular file from the user's computer's directory to the current context
|
||||
|
||||
**Expected result** : A new file browser window should open, with sufficient information provided to the user to know which file type should be loaded in (eg adding a file extension, adding information in the filebrowser UI). When the file is loaded, the interface should expand to show the attributes or information or new context-sensitive operations provided by the imported file.
|
||||
|
||||
**Proposal** : Currently there are some instances where I don't know if the elements are supposed to require an external file, eg
|
||||
|
||||
.. image:: https://user-images.githubusercontent.com/25156105/137275887-e0f0b694-842b-422f-bc09-cdcefef64107.png
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137276333-4d083f6a-36b9-494f-b0de-ec1d321cbd3d.png
|
||||
|
||||
**Icon name** : `"EXPORT"`
|
||||
|
||||
**Use** : To export a particular file to the user's computer's directory
|
||||
|
||||
**Expected result** : A new file browser window should open, with sufficient information provided to the user to know which file type is going to be saved (eg adding a file extension, adding information in the filebrowser UI).
|
||||
|
||||
**Proposal** : When there is no actual file to be saved in the user's directory or the filepath is already set in another place in the UI :
|
||||
|
||||
.. image:: https://user-images.githubusercontent.com/25156105/137276840-3ceda0cd-87bd-45f5-8488-bfce86bf3d84.png
|
||||
|
||||
It may be better to use a save icon of some sort instead, eg
|
||||
|
||||
.. image:: https://user-images.githubusercontent.com/25156105/137276758-5d60f0ca-5a93-4af3-9c4f-30c5794e0657.png
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137277047-bd45df5b-3b47-4b2c-aa29-a340b0710345.png
|
||||
|
||||
**Icon name** : `"FILEBROWSER"`
|
||||
|
||||
**Use** : To Provide the current context with the path to a particular file or folder
|
||||
|
||||
**Expected result** : A new file browser window should open, with sufficient information provided to the user to know which file type is required (eg adding a file extension, adding information in the filebrowser UI). Upon file or folder selection, this should populate a field in the current interface context with the path to the selected file or folder, or at least let the user know that the required information is now correctly filled in.
|
||||
|
||||
* .. image:: https://user-images.githubusercontent.com/25156105/137277374-fa7ff310-0b41-49a9-98bd-7c4686da05fd.png
|
||||
|
||||
**Icon name** : `"EYEDROPPER"`
|
||||
|
||||
**Use** : To select a particular object in the interface to fill the field it is attached to
|
||||
|
||||
**Expected result** : The cursor should change to an eyedropper until the user clicks on the required item. The user should be made aware after selection if it was successful (associated field being filled) or unsuccessful (message ? or field staying empty)
|
||||
@@ -0,0 +1,87 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/icon-FILE_TICK.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-108.00781,-50)">
|
||||
<g
|
||||
transform="translate(-189,-42)"
|
||||
style="display:inline;fill:#ffffff;enable-background:new"
|
||||
id="g17809-9"
|
||||
inkscape:label="C-6">
|
||||
<g
|
||||
id="g17552-8"
|
||||
transform="matrix(-1,0,0,1,508,-7e-5)"
|
||||
style="fill:#ffffff">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:new"
|
||||
d="m 201.49219,94.998047 a 0.50005,0.50005 0 0 0 -0.38867,0.195312 0.50005,0.50005 0 0 0 -0.006,0.0059 l -3.95118,3.953125 a 0.50005,0.50005 0 1 0 0.70704,0.707031 L 201,96.712891 v 8.792969 a 0.50005,0.50005 0 1 0 1,0 v -8.792969 l 3.14648,3.146484 a 0.50005,0.50005 0 1 0 0.70704,-0.707031 l -3.95508,-3.955078 a 0.50005,0.50005 0 0 0 -0.40625,-0.199219 z"
|
||||
id="path14327-2"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
|
||||
d="M 195.49219,104.99219 A 0.50005,0.50005 0 0 0 195,105.5 v 3 a 0.50005,0.50005 0 0 0 0.5,0.5 h 12 a 0.50005,0.50005 0 0 0 0.5,-0.5 v -3 a 0.50005,0.50005 0 1 0 -1,0 v 2.5 h -11 v -2.5 a 0.50005,0.50005 0 0 0 -0.50781,-0.50781 z"
|
||||
id="rect17542-1"
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 5.5 KiB |
@@ -0,0 +1,81 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/icon-FILE.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-381,-71)">
|
||||
<g
|
||||
id="g8734"
|
||||
transform="translate(232,-419)"
|
||||
style="display:inline;opacity:1;fill:#777777;fill-opacity:1;enable-background:new"
|
||||
inkscape:export-filename="blender_icons.png"
|
||||
inkscape:export-xdpi="96"
|
||||
inkscape:export-ydpi="96"
|
||||
inkscape:label="D-19">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:new"
|
||||
d="m 158.48048,492.99995 c -0.15153,0.004 -0.29304,0.0766 -0.38477,0.19727 l -4.94922,4.94921 c -0.31479,0.315 -0.0918,0.85335 0.35352,0.85352 h 5 c 0.27613,-3e-5 0.49997,-0.22387 0.5,-0.5 v -4.5 h 5 v 12 h -10 v -6 h -1 v 6.5 c 3e-5,0.27613 0.22387,0.49997 0.5,0.5 h 11 c 0.27613,-3e-5 0.49997,-0.22387 0.5,-0.5 v -13 c -3e-5,-0.27613 -0.22387,-0.49997 -0.5,-0.5 h -6 c -0.005,-6e-5 -0.009,-6e-5 -0.0137,0 -6.7e-4,2e-5 -0.001,-2e-5 -0.002,0 -0.001,4e-5 -0.003,-5e-5 -0.004,0 z"
|
||||
id="path8730"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccccccccccccccccccccccc" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.1 KiB |
@@ -0,0 +1,101 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/icon-FILE.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-423,-50)">
|
||||
<g
|
||||
style="display:inline;fill:#777777;fill-opacity:1;enable-background:new"
|
||||
id="g15543"
|
||||
transform="translate(42,-42)"
|
||||
inkscape:label="C-21">
|
||||
<g
|
||||
id="g15520"
|
||||
transform="translate(232,-398)"
|
||||
style="display:inline;opacity:1;fill:#777777;fill-opacity:1;enable-background:new"
|
||||
inkscape:export-filename="blender_icons.png"
|
||||
inkscape:export-xdpi="96"
|
||||
inkscape:export-ydpi="96">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:new"
|
||||
d="m 430.48047,53 c -0.15153,0.004 -0.29304,0.07659 -0.38477,0.197266 l -3.94922,3.949218 C 425.83169,57.461484 426.05468,57.99983 426.5,58 h 4 c 0.27613,-3e-5 0.49997,-0.22387 0.5,-0.5 V 54 h 6 v 3.5 c -0.01,0.676161 1.00956,0.676161 1,0 v -4 c -3e-5,-0.276131 -0.22387,-0.499972 -0.5,-0.5 h -7 c -0.005,-6.2e-5 -0.009,-6.2e-5 -0.0137,0 -6.7e-4,1.8e-5 -0.001,-2.1e-5 -0.002,0 -0.001,4.1e-5 -0.003,-5e-5 -0.004,0 z M 426,59.000004 V 66.5 c 3e-5,0.276131 0.22387,0.499972 0.5,0.5 h 4.25 c 0.67616,0.0096 0.67616,-1.009563 0,-1 H 427 v -6.999996 z"
|
||||
transform="translate(-274,440)"
|
||||
id="path15514"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccccccccccccccccccccccccc" />
|
||||
</g>
|
||||
<g
|
||||
inkscape:export-ydpi="96"
|
||||
inkscape:export-xdpi="96"
|
||||
inkscape:export-filename="blender_icons.png"
|
||||
style="display:inline;opacity:1;fill:#777777;fill-opacity:1;stroke-width:1.25111;enable-background:new"
|
||||
transform="matrix(-0.799288,0,0,0.799288,686.435,-75.7359)"
|
||||
id="g12909-3">
|
||||
<path
|
||||
style="display:inline;opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;enable-background:new"
|
||||
d="m 435.50195,58 a 0.50005,0.50005 0 0 0 -0.50586,0.507812 L 435,59.847656 c -0.37235,0.07227 -0.71903,0.219786 -1.02148,0.427735 l -1.12696,-1.123047 a 0.50005,0.50005 0 0 0 -0.34375,-0.150391 0.50005,0.50005 0 0 0 -0.36133,0.859375 l 1.12696,1.123047 c -0.20773,0.30118 -0.3566,0.644813 -0.42969,1.015625 l -1.3457,0.002 a 0.5009775,0.5009775 0 0 0 0.002,1.001953 L 432.83789,63 c 0.0676,0.378442 0.20857,0.7312 0.41602,1.039062 l -1.10743,1.109376 a 0.50005,0.50005 0 1 0 0.70508,0.705078 l 1.10352,-1.101563 c 0.30785,0.216541 0.661,0.370975 1.04297,0.445313 l -0.002,1.300781 a 0.50098382,0.50098382 0 1 0 1.00196,0.0039 L 436,65.199219 c 0.38598,-0.06997 0.74484,-0.216649 1.05664,-0.431641 l 1.08203,1.085938 a 0.5000572,0.5000572 0 1 0 0.70899,-0.705078 l -1.08399,-1.087891 C 437.97884,63.747505 438.12621,63.387471 438.19531,63 H 439.5 a 0.50033424,0.50033424 0 1 0 0,-1 h -1.31055 c -0.0748,-0.379778 -0.22985,-0.730801 -0.44531,-1.037109 l 1.10156,-1.103516 A 0.50005,0.50005 0 0 0 438.49805,59 a 0.50005,0.50005 0 0 0 -0.35743,0.154297 l -1.10742,1.105469 C 436.72738,60.053691 436.37559,59.913865 436,59.845703 l -0.004,-1.339844 A 0.50005,0.50005 0 0 0 435.50195,58 Z m -0.002,3.300781 c 0.66274,0 1.19921,0.536481 1.19922,1.199219 0,0.662738 -0.53648,1.199219 -1.19922,1.199219 -0.66274,-8e-6 -1.19922,-0.536481 -1.19922,-1.199219 0,-0.66273 0.53649,-1.199211 1.19922,-1.199219 z"
|
||||
transform="matrix(-1.25111,0,0,1.25111,911.356,147.301)"
|
||||
id="path12903-0"
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 6.5 KiB |
@@ -0,0 +1,85 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/icon-FILE_CACHE.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-486,-50.000004)">
|
||||
<g
|
||||
inkscape:export-ydpi="96"
|
||||
inkscape:export-xdpi="96"
|
||||
inkscape:export-filename="blender_icons.png"
|
||||
style="display:inline;stroke:#ffffff;enable-background:new"
|
||||
id="g28228"
|
||||
transform="translate(-1)"
|
||||
inkscape:label="C-24">
|
||||
<g
|
||||
style="display:inline;opacity:0.99;stroke:#ffffff;enable-background:new"
|
||||
transform="translate(339,-440)"
|
||||
id="g28217">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
|
||||
d="M 501.49219,52.992188 C 501.21604,52.996495 500.99568,53.223854 501,53.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z M 495.48438,53 c -0.12718,0.004 -0.248,0.0564 -0.3379,0.146484 l -5,5 c -0.10126,0.101337 -0.1304,0.223491 -0.13086,0.345704 L 490,58.507812 V 60.5 c -0.01,0.676161 1.00956,0.676161 1,0 V 59 h 4.5 c 0.27613,-3e-5 0.49997,-0.22387 0.5,-0.5 V 54 h 0.5 c 0.67616,0.0096 0.67616,-1.009563 0,-1 h -1 v 0.002 c -0.005,-5e-6 -0.0101,-0.0021 -0.0156,-0.002 z M 498.5,53 c -0.67616,-0.0096 -0.67616,1.009563 0,1 h 1 c 0.67616,0.0096 0.67616,-1.009563 0,-1 z m 2.99219,2.992188 C 501.21604,55.996495 500.99568,56.223854 501,56.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z m 0,3 C 501.21604,58.996495 500.99568,59.223854 501,59.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z m -11,3 C 490.21604,61.996495 489.99568,62.223854 490,62.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z m 11,0 C 501.21604,61.996495 500.99568,62.223854 501,62.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z m -11,3 C 490.21604,64.996494 489.99568,65.223854 490,65.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z m 11,0 C 501.21604,64.996494 500.99568,65.223854 501,65.5 v 1 c -0.01,0.676161 1.00956,0.676161 1,0 v -1 c 0.004,-0.282265 -0.22554,-0.512227 -0.50781,-0.507812 z M 492.5,66 c -0.67616,-0.0096 -0.67616,1.009563 0,1 h 1 c 0.67616,0.0096 0.67616,-1.009563 0,-1 z m 3,0 c -0.67616,-0.0096 -0.67616,1.009563 0,1 h 1 c 0.67616,0.0096 0.67616,-1.009563 0,-1 z m 3,0 c -0.67616,-0.0096 -0.67616,1.009563 0,1 h 1 c 0.67616,0.0096 0.67616,-1.009563 0,-1 z"
|
||||
transform="translate(-338,440)"
|
||||
id="path28215" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 5.6 KiB |
@@ -0,0 +1,77 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/icon-GREASEPENCIL.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-381,-575)">
|
||||
<g
|
||||
id="g21041"
|
||||
inkscape:label="BA-19"
|
||||
style="display:inline;enable-background:new">
|
||||
<path
|
||||
id="path18998-9"
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;paint-order:fill markers stroke;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
|
||||
d="m 398,581 h -1 v -2 l 0.8535,-0.8535 c 0.091,0.09 0.1465,0.2154 0.1465,0.3535 z m -1,-2 0.8535,-0.8535 C 397.7635,578.0555 397.6381,578 397.5,578 h -9 c -0.1326,0 -0.2598,0.053 -0.3535,0.1465 l -4,4.0078 c -0.094,0.094 -0.1465,0.2209 -0.1465,0.3535 V 591.5 c 0,0.2761 0.2239,0.5 0.5,0.5 h 13 c 0.2761,0 0.5,-0.2239 0.5,-0.5 V 589 c -10e-5,-1.0628 -0.406,-2.084 -1.1367,-2.8438 l -0.01,-0.01 L 394.707,584 h 2.793 c 0.6761,0.01 0.6761,-1.0096 0,-1 h -3.9395 c -0.3255,-0.042 -0.6029,0.235 -0.5605,0.5605 V 587.5 c -0.01,0.6761 1.0096,0.6761 1,0 v -2.793 l 2.1426,2.1426 c 0.5484,0.5702 0.8573,1.3426 0.8574,2.1504 v 2 h -12 v -8.2852 L 388.707,579 Z"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccccscccccccssssscccccccccccccccccc" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.2 KiB |
@@ -0,0 +1,81 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/icon-FILE_HIDDEN.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-318,-470)">
|
||||
<g
|
||||
style="display:inline;fill:#777777;fill-opacity:1;enable-background:new"
|
||||
inkscape:export-ydpi="96"
|
||||
inkscape:export-xdpi="96"
|
||||
inkscape:export-filename="blender_icons.png"
|
||||
transform="translate(-21)"
|
||||
id="g12839"
|
||||
inkscape:label="W-16">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#777777;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:new"
|
||||
d="m 353.13867,473.0332 c -0.49613,-0.0451 -1.03862,0.15972 -1.49219,0.61328 l -0.75,0.75 c -0.19519,0.19527 -0.19519,0.51177 0,0.70704 l 3,3 c 0.19527,0.19519 0.51177,0.19519 0.70704,0 l 0.75,-0.75 c 0.45356,-0.45357 0.65838,-0.99606 0.61328,-1.49219 -0.0451,-0.49613 -0.30436,-0.90592 -0.61328,-1.21485 l -1,-1 c -0.30893,-0.30892 -0.71872,-0.56817 -1.21485,-0.61328 z m -3.39644,2.7168 c -0.12989,0.002 -0.25387,0.0546 -0.34571,0.14648 l -6.25,6.25 c -0.0639,0.0642 -0.10909,0.14453 -0.13086,0.23243 l -1,4 c -0.0904,0.36537 0.2401,0.69582 0.60547,0.60547 l 4,-1 c 0.0879,-0.0218 0.16823,-0.067 0.23243,-0.13086 l 6.25,-6.25 c 0.19519,-0.19527 0.19519,-0.51177 0,-0.70704 l -3,-3 c -0.0957,-0.0957 -0.22605,-0.14856 -0.36137,-0.14648 z"
|
||||
id="path12837"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cccccccscccccccccccccccc" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.4 KiB |
@@ -0,0 +1,76 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/location-scene.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-44.996437,-596.00085)">
|
||||
<g
|
||||
id="g17695"
|
||||
inkscape:label="CA-3"
|
||||
style="display:inline;enable-background:new">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#651fff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:new"
|
||||
d="m 53.494141,601.99414 a 0.50005,0.50005 0 0 0 -0.347657,0.85938 l 3.646485,3.64648 -3.646485,3.64648 a 0.50005,0.50005 0 1 0 0.707032,0.70704 l 4,-4 a 0.50005,0.50005 0 0 0 0,-0.70704 l -4,-4 a 0.50005,0.50005 0 0 0 -0.359375,-0.15234 z"
|
||||
id="path9518-7-7"
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 3.7 KiB |
@@ -0,0 +1,78 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
inkscape:export-ydpi="153.60001"
|
||||
inkscape:export-xdpi="153.60001"
|
||||
inkscape:export-filename="../Projects/ifcopenshell/src/blenderbim/docs/images/location-breadcrumb.svg"
|
||||
style="display:inline;enable-background:new"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape"
|
||||
sodipodi:docname="blender_icons.svg"
|
||||
version="1.0"
|
||||
inkscape:version="1.2 (dc2aeda, 2022-05-15)"
|
||||
sodipodi:version="0.32"
|
||||
id="svg2"
|
||||
height="20"
|
||||
width="20"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||
<metadata
|
||||
id="metadata34337">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<sodipodi:namedview
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-rotation="0"
|
||||
pagecolor="#808080"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1728"
|
||||
inkscape:window-height="1051"
|
||||
id="namedview34335"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.2495612"
|
||||
inkscape:cx="196.46897"
|
||||
inkscape:cy="320.51252"
|
||||
inkscape:window-x="767"
|
||||
inkscape:window-y="120"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="layer8"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:deskcolor="#808080" />
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer8"
|
||||
inkscape:label="icons"
|
||||
style="display:inline"
|
||||
transform="translate(-2.9999969,-491)">
|
||||
<g
|
||||
style="display:inline;fill:#651fff;fill-opacity:1;enable-background:new"
|
||||
id="g23466"
|
||||
transform="translate(-1.85367e-6,-0.999995)"
|
||||
inkscape:label="X-1">
|
||||
<path
|
||||
style="color:#000000;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:medium;line-height:normal;font-family:sans-serif;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration:none;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;letter-spacing:normal;word-spacing:normal;text-transform:none;writing-mode:lr-tb;direction:ltr;text-orientation:mixed;dominant-baseline:auto;baseline-shift:baseline;text-anchor:start;white-space:normal;shape-padding:0;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#651fff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:new"
|
||||
d="m 10.482422,494 c -0.189602,0.007 -0.359053,0.12023 -0.4375,0.29297 l -3.7734376,8.25 c -0.00134,0.003 -0.00264,0.007 -0.00391,0.01 C 6.1587525,502.80633 6,503.10119 6,503.5 c 0,0.83813 0.5261723,1.53471 1.296875,1.92188 0.7707027,0.38715 1.7901254,0.55582 3.023437,0.57226 0.295371,0.003 0.52928,-0.24867 0.503907,-0.54297 9.47e-4,0.0108 -0.01109,-0.37852 -0.01563,-0.70898 -0.0045,-0.33047 -0.0078,-0.6698 -0.0078,-0.74219 0,-1.86768 1.015625,-3.51914 2.519531,-4.4375 0.228366,-0.13928 0.306682,-0.43361 0.177735,-0.66797 L 10.9375,494.25781 C 10.846425,494.09307 10.670549,493.99343 10.482422,494 Z M 18,494 c -1.098638,0 -1.999999,0.90136 -2,2 1e-6,1.09864 0.901362,2 2,2 1.098638,0 1.999999,-0.90136 2,-2 -1e-6,-1.09864 -0.901362,-2 -2,-2 z m -2,6 c -2.203217,0 -3.999999,1.79678 -4,4 10e-7,2.20322 1.796783,4 4,4 2.203217,0 3.999999,-1.79678 4,-4 -1e-6,-2.20322 -1.796783,-4 -4,-4 z m 0,1 c 1.662777,0 2.999999,1.33722 3,3 -1e-6,1.66278 -1.337223,3 -3,3 -1.662777,0 -2.999999,-1.33722 -3,-3 10e-7,-1.66278 1.337223,-3 3,-3 z m -0.541016,1.0332 C 14.658737,502.0332 14,502.69389 14,503.49414 a 0.50005,0.50005 0 1 0 1,0 c 0,-0.25981 0.199172,-0.46094 0.458984,-0.46094 a 0.50005,0.50005 0 1 0 0,-1 z"
|
||||
transform="translate(1.85367e-6,0.999995)"
|
||||
id="path10645"
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.7 KiB |
@@ -0,0 +1,214 @@
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
BlenderBIM Reference Manual
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
Welcome to the manual for `BlenderBIM <https://blenderbim.org>`__,
|
||||
the free and open source BIM add-on for Blender.
|
||||
|
||||
Quickstart
|
||||
==========
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/quickstart/introduction_to_bim` (2-minute read)
|
||||
Brief overview of BIM concepts and BlenderBIM's role.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/quickstart/installation` (5 to 10-minute process)
|
||||
Installation guide and system requirements.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/quickstart/explore_model` (15-minute guide)
|
||||
Load and navigate an IFC model.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/quickstart/create_model` (20-minute guide)
|
||||
Create a simple BIM project.
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Quickstart
|
||||
:maxdepth: 1
|
||||
|
||||
users/quickstart/introduction_to_bim
|
||||
users/quickstart/installation
|
||||
users/quickstart/explore_model
|
||||
users/quickstart/create_model
|
||||
users/quickstart/next_steps
|
||||
|
||||
Sections
|
||||
========
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/modeling/interface`
|
||||
Guide to the BlenderBIM interface.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/modeling/ifc_modeling`
|
||||
IFC modeling techniques and concepts.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/git_support`
|
||||
Collaborate on projects using Git
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/drawing/index`
|
||||
2D drawing generation and annotation.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/structural_analysis/index`
|
||||
Structural analysis capabilities in BlenderBIM.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/costing_and_scheduling/index`
|
||||
Cost estimation and project scheduling features.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/advanced/index`
|
||||
Advanced topics and large-scale modeling.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/tutorials/index`
|
||||
Real-world BIM project tutorials.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/user_interface`
|
||||
Detailed UI reference.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/other_addons`
|
||||
Other complementary add-ons
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/users/troubleshooting`
|
||||
Troubleshooting when things go wrong
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Sections
|
||||
:maxdepth: 2
|
||||
|
||||
users/modeling/interface
|
||||
users/modeling/ifc_modeling
|
||||
users/git_support
|
||||
users/drawing/index
|
||||
users/structural_analysis/index
|
||||
users/costing_and_scheduling/index
|
||||
users/advanced/index
|
||||
users/tutorials/index
|
||||
users/user_interface
|
||||
users/other_addons
|
||||
users/troubleshooting
|
||||
|
||||
Get Involved
|
||||
============
|
||||
|
||||
This manual is maintained largely by volunteers.
|
||||
|
||||
Please consider joining the effort and :doc:`/contribute/writing_docs`.
|
||||
|
||||
You can also can help with :doc:`Translations and Internationalisation </contribute/translations>`
|
||||
|
||||
For users who want to contribute to the BlenderBIM codebase,
|
||||
please refer to the :doc:`Documentation for Developers </devs/getting_started>`.
|
||||
This part of the documentation covers various aspects of the BlenderBIM development process.
|
||||
|
||||
You can get in touch by `joining the chat <https://osarch.org/chat/>`__.
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Get Involved
|
||||
:maxdepth: 1
|
||||
|
||||
contribute/writing_docs
|
||||
contribute/translations
|
||||
|
||||
|
||||
Developer Documentation
|
||||
=======================
|
||||
|
||||
BlenderBIM is an open-source project, and its development is driven by the contributions of a dedicated community of developers,
|
||||
architects, engineers, and enthusiasts. If you're interested in contributing to the project, whether by submitting bug reports,
|
||||
suggesting new features, or contributing code, your involvement is highly encouraged and appreciated.
|
||||
|
||||
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/getting_started`
|
||||
Introduction to contributing to BlenderBIM.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/installation`
|
||||
Setting up a development environment.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/hello_world`
|
||||
Understanding the project structure.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/undo_system`
|
||||
Working with BlenderBIM's undo system.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/code_style`
|
||||
Code style guidelines and best practices.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/running_tests`
|
||||
Testing and quality assurance.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`/devs/ux_guidelines`
|
||||
User experience and interface guidelines.
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Developer Documentation
|
||||
:maxdepth: 1
|
||||
|
||||
devs/getting_started
|
||||
devs/installation
|
||||
devs/hello_world
|
||||
devs/undo_system
|
||||
devs/code_style
|
||||
devs/running_tests
|
||||
devs/ux_guidelines
|
||||
@@ -0,0 +1,35 @@
|
||||
@ECHO OFF
|
||||
|
||||
pushd %~dp0
|
||||
|
||||
REM Command file for Sphinx documentation
|
||||
|
||||
if "%SPHINXBUILD%" == "" (
|
||||
set SPHINXBUILD=sphinx-build
|
||||
)
|
||||
set SOURCEDIR=.
|
||||
set BUILDDIR=_build
|
||||
|
||||
if "%1" == "" goto help
|
||||
|
||||
%SPHINXBUILD% >NUL 2>NUL
|
||||
if errorlevel 9009 (
|
||||
echo.
|
||||
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
|
||||
echo.installed, then set the SPHINXBUILD environment variable to point
|
||||
echo.to the full path of the 'sphinx-build' executable. Alternatively you
|
||||
echo.may add the Sphinx directory to PATH.
|
||||
echo.
|
||||
echo.If you don't have Sphinx installed, grab it from
|
||||
echo.http://sphinx-doc.org/
|
||||
exit /b 1
|
||||
)
|
||||
|
||||
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||
goto end
|
||||
|
||||
:help
|
||||
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||
|
||||
:end
|
||||
popd
|
||||
@@ -0,0 +1,191 @@
|
||||
Dealing with large models
|
||||
=========================
|
||||
|
||||
The BlenderBIM Add-on can handle large models, or federated collections of
|
||||
models where the combined total IFCs may be many gigabytes or object counts may
|
||||
be in the hundreds of thousands.
|
||||
|
||||
Models may be large in terms of different metrics, such as:
|
||||
|
||||
- Filesizes over 750MB, which may cause memory issues
|
||||
- Individual object polygon counts over 100k, which may cause unreasonable
|
||||
loading times
|
||||
- Objects having excessive or low quality booleans, which may cause
|
||||
unreasonable loading times
|
||||
- Number of elements exceeding 50,000 loaded in the scene, which may cause
|
||||
unreasonable loading times, selection glitches, and viewport lagging
|
||||
|
||||
There are always solutions to all of these, but an understanding of the type of
|
||||
size limitation you are up against will always help.
|
||||
|
||||
Large filesizes
|
||||
---------------
|
||||
|
||||
The first priority is to ensure you do not have a prohibitively large filesize.
|
||||
|
||||
- Use IFC4. It can handle geometry much more efficiently and expect your
|
||||
filesize to drop significantly.
|
||||
- When coming from other software, ensure you are exporting solids, not faceted
|
||||
BReps or tessellations where appropriate. Choosing the wrong export setting
|
||||
can easily double or triple your filesize and export times. Choose **Design
|
||||
Transfer View** instead of **Coordination View** or **Reference View**. Look
|
||||
for export settings that use the keywords like "surface", "solid", "brep",
|
||||
"tessellation", or "extrusion".
|
||||
- Improve your model breakdown strategy (see below)
|
||||
- Identify objects with large polygon counts and improve the modeling (see below)
|
||||
|
||||
Model breakdown strategies
|
||||
--------------------------
|
||||
|
||||
A good general strategy is to never have a large model to begin with. Breaking
|
||||
down models is critical for usability during design and coordination. Where full
|
||||
models are needed, such as during clash detection, review meetings, or client
|
||||
handover, many small models may be federated. Model breakdown strategies
|
||||
include:
|
||||
|
||||
- **By discipline**, you probably already do this, so let's move on
|
||||
- **By location**, such as by building, floor, zone, mid-rise, high-rise, core
|
||||
podium, underground, plant rooms, facade orientation, or similar.
|
||||
- **By object type**, such as by primary structural elements vs accessories
|
||||
(plates, bolts, etc), furniture vs general arrangement, facade vs interiors,
|
||||
distribution system elements (equipment, pipes, fittings) vs accessories (pipe
|
||||
clamps, hangers, etc) or similar.
|
||||
- **By coordination task**, many people get into the habit of exchanging the
|
||||
entire building when a task only requires a tiny portion of it. Think of the
|
||||
workflow of exchanging traditional drawings. A large project would have
|
||||
thousands of drawings with a few drawings exchanged for a single coordination
|
||||
task. This strategy can be used with models: exchange hundreds of tiny models
|
||||
(some maybe even only 1MB!), scoped to the task at hand. Keep exchanges small
|
||||
and frequent (like code commits, for the geeks reading this).
|
||||
|
||||
Filtered model loading
|
||||
----------------------
|
||||
|
||||
You may filter elements and only load a portion of the model. Click on
|
||||
:ref:`Enable Advanced Mode <Project Info Advanced Loading Mode>` checkbox when loading a model.
|
||||
|
||||
|
||||
.. image:: images/advanced-mode.png
|
||||
|
||||
This will preload the model and present you with model loading options in the
|
||||
:doc:`Project Info </users/user_interface/property_editor/scene_editor/project_overview/project_info>`
|
||||
panel.
|
||||
|
||||
.. image:: images/advanced-mode-settings.png
|
||||
|
||||
**Filter Modes** include:
|
||||
|
||||
- **Decomposition**, filter by location in the building, such as **Level 1** or
|
||||
**Building A**.
|
||||
- **IFC Class**, filter by IFC class, such as **Wall**, **Column**, or **Pipe
|
||||
Segments**
|
||||
- **IFC Type**, filter by IFC construction type, such as **Copper pipes** and
|
||||
**200mm thick concrete slabs**
|
||||
- **Whitelist** or **Blacklist**, filter by a custom query
|
||||
|
||||
When **Whitelist** or **Blacklist** is chosen, you may type a custom query to
|
||||
filter by attributes, properties, location, and so on.
|
||||
|
||||
Large polygon counts
|
||||
--------------------
|
||||
|
||||
If objects with large polygon counts are blocking you from importing, consider
|
||||
enabling **Native Meshes** in the :ref:`Advanced Loading Mode <Project Info Advanced Loading Mode>` when loading projects.
|
||||
|
||||
The **Debug Panel** allows you to **Select High Polygon Meshes** or **Select
|
||||
Highest Polygon Meshes** to isolate geometrically complex objects by a polygon
|
||||
number threshold or a percentage.
|
||||
|
||||
After selecting these elements, you can view them in edit mode to see a polygon
|
||||
count and where the offending polygons are. Often, fixing a single object may
|
||||
cut out 50MB.
|
||||
|
||||
Excessive or low quality booleans
|
||||
---------------------------------
|
||||
|
||||
In some cases, elements may be generated from external software with an
|
||||
excessive (over 50) number of boolean operations or with high polygon, complex
|
||||
booleans.
|
||||
|
||||
The **IFC Debug** panel has a **Test All Shapes** feature which generates
|
||||
geometry for every element one by one and outputs the processing time to the
|
||||
console. When you see it stuck on an element, make a note of the element ID. You
|
||||
may then use the **IFC Debug** panel's **Inspector** to determine the nature of
|
||||
the boolean, or create a **Blacklist Filter Mode** to exclude the element from
|
||||
import.
|
||||
|
||||
These types of errors are usually problems with external software (i.e. not
|
||||
intentionally by the end-user) and typically do not affect critical geometry
|
||||
and can be worked around.
|
||||
|
||||
Fully resolving boolean issues is a complex case by case topic and not covered
|
||||
here.
|
||||
|
||||
High number of elements
|
||||
-----------------------
|
||||
|
||||
Click on :ref:`Enable Advanced Mode <Project Info Advanced Loading Mode>` when loading a model and you will be presented
|
||||
with model loading options in the **Project Info** panel.
|
||||
|
||||
You may specify an **Element Range** to process. The **Element Offset** says the
|
||||
first element to start processing at, and the **Element Limit** says how many
|
||||
elements should be processed. For example, in a model with 100,000 objects, an
|
||||
**Element Start** of 30,000 and an **Element Limit** of 20,000 will process the
|
||||
elements starting at item number 30,000 and ending at item number 50,000. This
|
||||
allows you to arbitrarily break down large models into submodels. This can be
|
||||
combined with other filters.
|
||||
|
||||
Using Blender 3.3 and above will result in a faster load time (~50%) compared to
|
||||
older Blender versions.
|
||||
|
||||
Coordination only models
|
||||
------------------------
|
||||
|
||||
The BlenderBIM Add-on defaults to authoring IFCs. This allows full editing and
|
||||
inspection of all element properties and relationships. However, sometimes only
|
||||
geometry and basic attributes such as names are sufficient. Example usecases
|
||||
include CG visualisation, overall federated model coordination, or pure
|
||||
geometric checks.
|
||||
|
||||
Click on :ref:`Enable Advanced Mode <Project Info Advanced Loading Mode>` checkbox when loading a model and you will be presented
|
||||
with model loading options in the **Project Info** panel. Enable **For
|
||||
Coordination Only**, which will exclude non geometric elements, openings, and
|
||||
types from being imported. This leads to slightly faster imports, and a
|
||||
decreased object count.
|
||||
|
||||
Enabling **For Coordination Only** also allows you to specify a **Merge Mode**.
|
||||
This combines objects to keep object counts low. Blender is very good at
|
||||
handling less objects with more complexity, rather than the other way around.
|
||||
When a **Merge Mode** is activated, import times will increase (~50%) but object
|
||||
counts will be drastically reduced, which is critical for the federation of
|
||||
large models. **Merge Modes** include:
|
||||
|
||||
- **IFC Class**, where objects of the same IFC class are merged. This is useful
|
||||
if you have models where only the class is meaningful for other disciplines,
|
||||
such as structural models.
|
||||
- **IFC Type**, where objects of the same construction type are merged. This is
|
||||
useful where the main identification of interest is the element type, not the
|
||||
element instance.
|
||||
- **Material**, where objects of the same material are merged. This is useful if
|
||||
the model is used for purely visual exploration such as CG visualisation.
|
||||
|
||||
Once loaded, the model may be saved as a ``.blend`` file for subsequent loads.
|
||||
You can think of the ``.blend`` file as a geometry cache, which is very, very
|
||||
fast to load. If it no longer necessary to access IFC data, consider pressing
|
||||
the **Unload Project** icon so that future loads of the ``.blend`` file will be
|
||||
very fast.
|
||||
|
||||
With these strategies, a federated 1GB IFC model can easily load in 10 seconds
|
||||
from the saved Blender files.
|
||||
|
||||
Processing models headlessly
|
||||
----------------------------
|
||||
|
||||
You can automate model processing using this command (~5% speedup):
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
blender -b -P headless_import.py
|
||||
|
||||
The ``headless_import.py`` script contains instructions on how to configure
|
||||
model loading settings.
|
||||
@@ -0,0 +1,256 @@
|
||||
Georeferencing
|
||||
==============
|
||||
|
||||
There are two types of construction: vertical construction (such as buildings
|
||||
and sites) which deal with small distances typically under 1km, and horizontal
|
||||
construction (such as transport, transmission, and subterranean networks) where
|
||||
distances frequently exceed 1km. Blender and the BlenderBIM Add-on focuses on
|
||||
vertical construction, and will typically just work out of the box.
|
||||
|
||||
Coordinate reference systems
|
||||
----------------------------
|
||||
|
||||
The minimum requirement for a georeferenced model is to specify the coordinate
|
||||
reference system used. This is known as the **Projected CRS**, and is a feature
|
||||
available in IFC4 onwards.
|
||||
|
||||
.. warning::
|
||||
|
||||
IFC2X3 models cannot be georeferenced. There is a proposed convention to
|
||||
provide fallback support but this is not supported yet in any known vendor.
|
||||
Please consider upgrading to IFC4.
|
||||
|
||||
Most architects and engineers will know the name of the **Projected CRS**
|
||||
typically chosen by the surveyor. For example in Sydney, Australia, you might
|
||||
use GDA2020 / MGA Zone 56. In IFC a standardised code from the EPSG public
|
||||
registry is used to refer to the **Projected CRS**. For example, GDA 2020 / MGA
|
||||
Zone 56 will be named EPSG:7856.
|
||||
|
||||
You can check whether or not your model is georeferenced in the **IFC
|
||||
Georeferencing** panel in the **Scene Properties** tab. You should see a section
|
||||
for the **Projected CRS** with an EPSG code.
|
||||
|
||||
.. image:: images/projectedcrs.png
|
||||
|
||||
If you do not see this, your project is not georeferenced.
|
||||
|
||||
.. Note::
|
||||
|
||||
Even if a model has large "real world coordinates", this does not mean the
|
||||
project is georeferenced. Without a **Projected CRS**, these coordinates are
|
||||
meaningless.
|
||||
|
||||
Map conversions
|
||||
---------------
|
||||
|
||||
The coordinates for the nominated **Projected CRS** are known as **Map
|
||||
Coordinates**. These **Map Coordinates** are typically large numbers and read as
|
||||
Eastings and Northings.
|
||||
|
||||
In vertical construction, some disciplines (such as a civil engineer or
|
||||
surveyor) will directly use **Map Coordinates** in their designs. Most others,
|
||||
such as the architect, structural, and service engineers will instead use
|
||||
**Local engineering coordinates**. A **Map Conversion** stores the parameters
|
||||
for transforming **Local engineering coordinates** to **Map Coordinates**.
|
||||
|
||||
For example, a civil engineer will work directly in **Map Coordinates**. This
|
||||
means that the model's coordinates correlate directly to Eastings and
|
||||
Northings. Similarly, the model's +Y axis will point to **Grid North**. As
|
||||
there is no **Map Conversion** involved, you will see a 0 in the Eastings,
|
||||
Northings, and Orthogonal Height in the **IFC Georeferencing** panel.
|
||||
|
||||
.. image:: images/mapcoordinates.png
|
||||
|
||||
When **Local engineering coordinates** are used, typically the architect will
|
||||
nominate a local origin and model geometry will be drawn orthogonally (i.e.
|
||||
along the X and Y axis). This local origin often correlates with a site boundary,
|
||||
surveyed point, or grid intersection. This means that the model's coordinates
|
||||
are typically smaller numbers and correlate to surface distance measurements,
|
||||
not Eastings and Northings, and the model's +Y axis will point to **Project
|
||||
North**. The surveyor will then provide the necessary **Map Conversion**
|
||||
parameters to convert from **Local engineering coordinates** to Eastings,
|
||||
Northings, Orthogonal Height, and **Grid North**.
|
||||
|
||||
.. image:: images/mapconversion.png
|
||||
|
||||
.. warning::
|
||||
|
||||
Coordinate systems are a technical topic. A common error is that disciplines
|
||||
may choose to use **Map Coordinates** without realising that map distances
|
||||
do not correlate with surface distances measured on the ground. Unless you
|
||||
are trained to work in **Map Coordinates**, it is safer to work with local
|
||||
engineering coordinates and consult your surveyor for professional guidance.
|
||||
|
||||
**Map Conversions** contain six parameters.
|
||||
|
||||
**Eastings**, **Northings** and **Orthogonal Height** parameters define the
|
||||
translation from the model's XYZ coordinates to map **Eastings**, **Northings**,
|
||||
and **Heights**. Your model's local engineering origin at 0, 0, 0, will always
|
||||
convert exactly to the **Easting**, **Northing**, and **Orthogonal Height**
|
||||
displayed in this panel.
|
||||
|
||||
The **X Axis Abcissa** and **X Axis Ordinate** define the rotation vector from
|
||||
**Project North** to **Grid North**. These two numbers combine into a coordinate
|
||||
vector pointing along the X axis (i.e. **Project East**). The default is an
|
||||
abscissa of 1 and ordinate of 0. This default (1, 0) vector implies **Project
|
||||
East** and **Grid East** coalign, which means there is no rotation between
|
||||
**Project North** and **Grid North**.
|
||||
|
||||
.. image:: images/xaxisabscissaordinate.png
|
||||
|
||||
.. tip::
|
||||
|
||||
To save you the mental struggle of converting to degrees, a calculated
|
||||
rotation is always just below these values. Phew!
|
||||
|
||||
The distance measured on site, or the "surface distance" is actually not the
|
||||
same as the distance measured between Eastings and Northings. This difference is
|
||||
provided by the **Scale** parameter. The **Scale** defines the average combined
|
||||
scale factor across the small 1km site that converts from the model's surface
|
||||
distances to map grid distances. Note that the **Scale** is actually not a
|
||||
constant. However, for the small sites dealt with in vertical construction, it
|
||||
may be approximated to be a constant by your surveyor and will typically be a
|
||||
value close to, but not exactly 1.
|
||||
|
||||
.. note::
|
||||
|
||||
Always check that the surveyor provides a scale factor such that surface
|
||||
distance multiplied by **Scale** equals map grid distances (as opposed to
|
||||
the other way around).
|
||||
|
||||
Working with Map Coordinates
|
||||
----------------------------
|
||||
|
||||
The BlenderBIM Add-on is designed to work with small coordinates (under 1km),
|
||||
whereas map coordinates are typically large. When you load an IFC which uses map
|
||||
coordinates directly, or when you are working with IFC2X3 and you cannot use a
|
||||
map conversion, the BlenderBIM Add-on will autodetect a point on your model to
|
||||
use as a false origin.
|
||||
|
||||
The XYZ offset used for the false origin will be shown in the **IFC
|
||||
Georeferencing** panel under the **Blender Offset** header. It
|
||||
is very similar to a **Map Conversion**, but it will not have a scale and only
|
||||
temporarily affects your Blender session.
|
||||
|
||||
.. image:: images/blenderoffset.png
|
||||
|
||||
.. note::
|
||||
|
||||
A Blender offset is simply a shift in coordinates to reduce large model
|
||||
coordinates to smaller coordinates. It should not be used as an indicator of
|
||||
whether georeferencing is done correctly. Always check the **Projected
|
||||
CRS**, **Map Conversion** and confirm the parameters with your surveyor.
|
||||
|
||||
This distance limit of 1km and autodetected false origin may not be appropriate
|
||||
for your project. For example, your project may exceed the 1km limit, or you may
|
||||
want to federate multiple files together and manually specify a consistent and
|
||||
fixed false origin. You can customise these options by choosing
|
||||
:ref:`Enable Advanced Mode <Project Info Advanced Loading Mode>` when loading a project.
|
||||
Then, set the **Distance Limit** (in meters) and the **False Origin** coordinate
|
||||
before pressing **Load Project Elements**.
|
||||
|
||||
.. image:: images/manualorigin.png
|
||||
|
||||
When a false origin is used, there are two possible methods to offset objects by
|
||||
the false origin.
|
||||
|
||||
The first method is to offset the origin point of objects. We call this the
|
||||
**Object Placement** method. The second method is to offset the local
|
||||
coordinates of geometry within the objects themselves. We call this the
|
||||
**Cartesian Point** method. Sometimes, BIM applications combine both of these
|
||||
methods in a single IFC project. To see which workaround was used on an object,
|
||||
check the "Blender Offset" property in the **Transform** panel in the **Object
|
||||
Properties**. This is an advanced property used by powerusers to debug
|
||||
coordinate issues and may be safely ignored by most users.
|
||||
|
||||
.. image:: images/offsetmode.png
|
||||
|
||||
Incorrect coordinate use
|
||||
------------------------
|
||||
|
||||
Sometimes, a model may mix **Map Coordinates** and **Local engineering
|
||||
coordinates**. For example, a surveyed pipe may have its placement use **Map
|
||||
Coordinates** with large Eastings and Northings. However, the placement of the
|
||||
site object may be still set at 0, 0, 0. Since this range of coordinates exceed
|
||||
the default 1km distance limit, this creates a problem. Blender needs to choose
|
||||
between displaying the pipe accurately and sacrificing precision at the site
|
||||
placement, or vice versa, but it is impossible to satisfy both simultaneously in
|
||||
the same Blender session.
|
||||
|
||||
.. warning::
|
||||
|
||||
Many IFC viewers only show geometry, and don't show object placements. This may
|
||||
give users the false impression that their coordinates in their IFC project
|
||||
do not have such a large range. However, as a native IFC authoring platform,
|
||||
the BlenderBIM Add-on will not accept this inconsistency.
|
||||
|
||||
At this point, it is the users responsibility to reconcile this inconsistency in
|
||||
their coordinates. Either the user needs to fix their file to consistently
|
||||
offset all coordinates, or the user needs to manually tell the BlenderBIM Add-on
|
||||
the coordinates of the desired false origin and accept the precision loss.
|
||||
|
||||
Converting local and map coordinates
|
||||
------------------------------------
|
||||
|
||||
You can convert **Local engineering coordinates** to **Map coordinates** and
|
||||
vice versa in the **Viewport** panel. First, enable ``View > Sidebar`` then type
|
||||
in your coordinate in the **Input** field. Press either the **Local to Global**
|
||||
or **Global to Local** button to convert the coordinate. You will see the result
|
||||
of the calculation in the **Output** field.
|
||||
|
||||
.. image:: images/coordinateconversion.png
|
||||
|
||||
True north
|
||||
----------
|
||||
|
||||
When **Local engineering coordinates** are used, the model's +Y axis points to
|
||||
**Project North** for the convenience of drafting. When **Map Coordinates** are
|
||||
used, the model's +Y axis points to **Grid North** for the necessity of
|
||||
surveying.
|
||||
|
||||
**Project North** and **Grid North** is different to **True North**. The angle
|
||||
to **True North** is not a fixed angle. It will actually vary depending on the
|
||||
Eastings and Northings you choose to calculate it from.
|
||||
|
||||
However, this variable **True North** is a great source of confusion to
|
||||
architects, who typically just want to do a shadow study, solar study, or
|
||||
similar and go out for an early lunch. IFC can store a fixed **True North**
|
||||
value as a reference to be used for these types of usecases. If one is stored in
|
||||
your project, you may see it under the **True North** section of the **IFC
|
||||
Georeferencing** panel. Your surveyor will be able to provide the **True North**
|
||||
vector, but it should be only used as a reference, never used as a way to
|
||||
coordinate model rotations, and always with the understanding that it is not a
|
||||
fixed value.
|
||||
|
||||
.. image:: images/truenorth.png
|
||||
|
||||
.. warning::
|
||||
|
||||
Fun fact: **Magnetic North** is useless for the purposes of construction.
|
||||
|
||||
Coordinate precision limits
|
||||
---------------------------
|
||||
|
||||
The BlenderBIM Add-on focuses on vertical construction. Vertical construction
|
||||
typically uses **Local engineering coordinates** on a small site. The
|
||||
buildingSMART georeferencing technical experts panel have determined that a
|
||||
small site under 1km square can be assumed to have a constant **Map
|
||||
Conversion**.
|
||||
|
||||
Therefore, if your model is less than 1km square, you are within the coordinate
|
||||
precision limits. This is where the 1km default distance limit is derived from.
|
||||
|
||||
If you want to exceed the 1km square surveying limitation, you will need to be
|
||||
aware of software limitations that can result in precision loss when large
|
||||
coordinate ranges are used.
|
||||
|
||||
Blender, and subsequently the BlenderBIM Add-on, is not designed for **Map
|
||||
Coordinates**. Blender internally uses single precision floating point
|
||||
calculations. A full description of the precision implications are described in
|
||||
the `Blender working limits documentation
|
||||
<https://docs.blender.org/manual/en/latest/advanced/limits.html>`__.
|
||||
|
||||
This means that lengths greater than 5,000 meters start to accumulate software
|
||||
precision errors that affect the nearest millimeter. Therefore, from a software
|
||||
perspective, it is unwise to embark on a project with coordinates ranging
|
||||
greater than +/- 5km.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
@@ -0,0 +1,10 @@
|
||||
Advanced Use Cases
|
||||
==================
|
||||
|
||||
Advanced topics and large-scale modeling.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
georeferencing
|
||||
dealing_with_large_models
|
||||
@@ -0,0 +1,35 @@
|
||||
Costing and Scheduling
|
||||
======================
|
||||
|
||||
This section covers the cost estimation and project scheduling features in BlenderBIM.
|
||||
|
||||
.. note::
|
||||
This page is a stub. More detailed content will be added in future updates.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
BlenderBIM offers integrated tools for cost estimation and project scheduling, allowing users to link BIM elements directly to cost data and timeline information.
|
||||
|
||||
Key Features
|
||||
------------
|
||||
|
||||
- Material and element cost association
|
||||
- Quantity takeoffs
|
||||
- Project timeline creation
|
||||
- Resource allocation
|
||||
- 4D BIM visualization
|
||||
|
||||
Getting Started
|
||||
---------------
|
||||
|
||||
To begin using the costing and scheduling features in BlenderBIM:
|
||||
|
||||
1. Access the Costing and Scheduling panel in the BlenderBIM interface
|
||||
2. Associate costs with materials and elements
|
||||
3. Create a project timeline
|
||||
4. Link BIM elements to schedule activities
|
||||
|
||||
.. seealso::
|
||||
- :doc:`/users/modeling/ifc_modeling`
|
||||
- :doc:`/users/advanced/index`
|
||||
@@ -0,0 +1,119 @@
|
||||
======================
|
||||
Drawings and Documents
|
||||
======================
|
||||
|
||||
The BlenderBIM Add-on provides powerful tools for generating 2D drawings from your 3D BIM models and adding detailed annotations.
|
||||
This section covers the process of creating various types of drawings and enhancing them with annotations.
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
|
||||
Before starting with 2D drafting:
|
||||
|
||||
1. Ensure you have completed the IFC modeling section or have a completed IFC model ready.
|
||||
2. Install and update to the latest compatible version of the BlenderBIM addon as Drafting module is still in early development.
|
||||
3. Install InkScape as the drafting is heavily based on SVG files.
|
||||
|
||||
Generating 2D Drawings
|
||||
======================
|
||||
|
||||
Creating a Floor Plan
|
||||
---------------------
|
||||
|
||||
|
||||
Creating Elevations and Sections
|
||||
--------------------------------
|
||||
|
||||
The process for creating elevations and sections is similar:
|
||||
|
||||
|
||||
Annotations
|
||||
===========
|
||||
|
||||
Using Annotation Tool
|
||||
---------------------
|
||||
|
||||
|
||||
Annotating Plan Layout
|
||||
------------------------
|
||||
|
||||
1. Dimension key plan elements:
|
||||
a. Wall lengths - both external and internal
|
||||
b. Door/window openings
|
||||
c. Room sizes
|
||||
2. Snap dimensions to wall edges/corners.
|
||||
3. Position dimensions.
|
||||
|
||||
|
||||
Line Work
|
||||
=========
|
||||
|
||||
Annotations & Tags
|
||||
==================
|
||||
|
||||
Text Labels
|
||||
-----------
|
||||
|
||||
Leader Lines
|
||||
------------
|
||||
|
||||
Room Labels
|
||||
-----------
|
||||
|
||||
Door/Window Tags
|
||||
----------------
|
||||
|
||||
Sanitary Symbols
|
||||
================
|
||||
|
||||
Loading Symbol Types
|
||||
--------------------
|
||||
|
||||
|
||||
Placing Sanitaryware
|
||||
--------------------
|
||||
|
||||
Doors and Windows 2D outline
|
||||
----------------------------
|
||||
|
||||
|
||||
IFC Grids
|
||||
=========
|
||||
|
||||
Adding Grid Lines
|
||||
-----------------
|
||||
|
||||
|
||||
Positioning Grids
|
||||
-----------------
|
||||
|
||||
Displaying Grids in Drawings
|
||||
----------------------------
|
||||
|
||||
Materials/Hatching
|
||||
==================
|
||||
|
||||
Naming Material Layers
|
||||
----------------------
|
||||
|
||||
Automatic Hatch Patterns
|
||||
------------------------
|
||||
|
||||
Custom Materials
|
||||
----------------
|
||||
|
||||
Legend
|
||||
------
|
||||
|
||||
Next Steps
|
||||
==========
|
||||
|
||||
After mastering these basics, you may want to explore:
|
||||
|
||||
- Generating elevations and sections
|
||||
- Creating detail drawings
|
||||
- Setting up custom hatch patterns and line styles
|
||||
- Advanced annotation techniques
|
||||
|
||||
Remember, effective drawings are key to communicating your design intent.
|
||||
Take time to explore the various options and develop a consistent style for your project documentation.
|
||||
@@ -0,0 +1,221 @@
|
||||
Tracking revisions with Git
|
||||
===========================
|
||||
|
||||
BlenderBIM supports tracking the development of your IFC files with a Git
|
||||
repository.
|
||||
|
||||
BlenderBIM is an IFC file editor, you can create or load an IFC project,
|
||||
change, add or remove BIM objects and save to disk. A Git repository is a
|
||||
special folder on your computer where text files, such as IFC files, can be
|
||||
efficiently stored and past versions recalled.
|
||||
|
||||
Git is also a tool to share files with other people, transmitting only file
|
||||
changes, and allowing multiple people to keep local copies of the same
|
||||
repository up-to-date.
|
||||
|
||||
.. Note::
|
||||
|
||||
If you don't already have Git installed on your system, you will need to
|
||||
`Download from the Git website <https://git-scm.com/downloads>`__.
|
||||
You may have to restart Blender after installation.
|
||||
|
||||
Adding your IFC file to a repository
|
||||
------------------------------------
|
||||
|
||||
First, save your file to disk. If the folder is already a repository you can
|
||||
*Add* the file in the *IFC Git panel* to tell Git you want to track it,
|
||||
otherwise BlenderBIM will offer to convert the folder into a repository.
|
||||
|
||||
.. Warning::
|
||||
|
||||
You probably don't want to turn your entire HOME or User folder into a Git
|
||||
repository. Create one folder per project, this folder can contain multiple
|
||||
IFC files, optionally in subfolders, plus any resources needed to support
|
||||
them.
|
||||
|
||||
After adding an IFC file, this action will appear as the most recent item at
|
||||
the top of the revision list.
|
||||
|
||||
'Committing' changes
|
||||
--------------------
|
||||
|
||||
As you work on your IFC project, save the file regularly as usual. When you
|
||||
get to a point where it would be useful to later retrieve this state, you need
|
||||
to *commit* this to the Git repository. BlenderBIM gives you three options:
|
||||
|
||||
- Showing uncommitted changes will temporarily highlight the differences
|
||||
between the saved file and the last committed revision. Green objects are new
|
||||
and blue objects exist in the previous revision but have since been modified.
|
||||
|
||||
- Discarding uncommitted changes will throw away all your saved changes and
|
||||
revert the model to the previous revision.
|
||||
|
||||
- Committing changes will save this state of the model in the repository, along
|
||||
with a short commit message, the date, and your author details.
|
||||
|
||||
.. Tip::
|
||||
|
||||
All revisions need to have some sort of commit message. Typically this
|
||||
should be kept to 50 characters or less, but there is no practical limit,
|
||||
consider that this message may appear in various places, including on
|
||||
drawings, web pages, email subject lines etc.. It is also best to describe the
|
||||
status of the revision rather than the changes, ie. "Kitchen now has a
|
||||
door" is better than "Add a kitchen door" - but this is a matter of taste.
|
||||
|
||||
Visualising differences
|
||||
-----------------------
|
||||
|
||||
As you add commits, the revision list will build up. Usually you are working at
|
||||
the HEAD of a branch, ie. at the top of the list, but you can select items in
|
||||
the list to view commit metadata. You can also temporarily colourise the current
|
||||
model showing differences between this and any other saved revision - colours
|
||||
are the same as above: green objects are new to the current model, blue
|
||||
objects have changed in some way, and (if you have an older revision loaded)
|
||||
red objects have been deleted.
|
||||
|
||||
Viewing object history
|
||||
----------------------
|
||||
|
||||
The history of *everything* in the project is tracked in Git, the revision log
|
||||
for the currently selected object can be viewed with the BlenderBIM side-bar.
|
||||
|
||||
Retrieving Revisions
|
||||
--------------------
|
||||
|
||||
Colourising the model will show you *which* things are different, but it won't
|
||||
show you *how* they are different. As long as you have no uncommitted changes,
|
||||
you can switch to the selected revision, this will load in BlenderBIM as a
|
||||
full model that can be viewed and even edited.
|
||||
|
||||
.. Warning::
|
||||
|
||||
Switching to a different revision actually changes the file on disk before
|
||||
loading it in BlenderBIM. Don't worry, the original hasn't been lost,
|
||||
simply select the revision at the top of the list, switch back to
|
||||
that and you can continue as before.
|
||||
|
||||
Branching
|
||||
---------
|
||||
|
||||
Git supports a branched workflow. Say that you want to explore some design
|
||||
options, but don't want to mess-up the primary design, you can fork off any
|
||||
revision into a new branch and work on this without breaking anything in any
|
||||
other branches.
|
||||
|
||||
.. Note::
|
||||
|
||||
The primary branch in a Git repository is usually called *main*, though
|
||||
this is a convention, and older versions of Git call it *master*. Branch
|
||||
names should be short, but can contain unicode characters, emojis etc...
|
||||
Branch names can't contain spaces, and have some other minor limitations -
|
||||
BlenderBIM will not allow you to create invalid branch names.
|
||||
|
||||
To create a new branch from the current HEAD (ie. the top of the revision list)
|
||||
enter a branch name when committing. Leaving this field empty just adds a
|
||||
normal commit without creating a branch, however committing a change to an
|
||||
earlier revision necessarily implies a new branch, so BlenderBIM will insist
|
||||
that you give it a name.
|
||||
|
||||
Each branch can now be navigated separately in the revision list, to switch
|
||||
between branches, and to any previous revision in any branch, select the
|
||||
revision you are interested-in and switch as before.
|
||||
|
||||
.. Tip::
|
||||
|
||||
Conceptually a local branch is equivalent to a remote fork in somebody
|
||||
else's copy of your repository, and indeed by adding a remote you
|
||||
can fetch their work into a *remote branch* in your local repository.
|
||||
|
||||
Merging
|
||||
-------
|
||||
|
||||
.. Warning::
|
||||
|
||||
Merging is experimental functionality. There are various circumstances
|
||||
where a merge will fail, don't worry, this won't break your model but you
|
||||
may not want to rely on this functionality without having some experience
|
||||
of what changes are likely to merge and what won't.
|
||||
|
||||
You can merge changes that exist in a selected revision into the current
|
||||
model, even if changes have been made in both revisions - as long as these
|
||||
changes don't directly conflict.
|
||||
|
||||
.. Note::
|
||||
|
||||
Merging requires the *ifcmerge* tool installed in your `PATH`, if it is
|
||||
not installed the merge operator will not be enabled.
|
||||
|
||||
When two branches have diverged, merging an IFC model requires *conflict
|
||||
resolution* (because added entities may inadvertently reuse the same Step-IDs),
|
||||
this means that data on one side or the other may be rewritten by BlenderBIM in
|
||||
order to accommodate both sets of changes. ie. the merge process is
|
||||
*asymmetrical*. BlenderBIM privileges data in the remote `origin/main` branch
|
||||
over the local working branch, similarly it privileges data in the local `main`
|
||||
branch over any other local working branch. The practical result of this is
|
||||
that branches branched-off the `main` branch can generally be merged back into
|
||||
`main`, but any sub-branches of these will need to be merged back into their
|
||||
parent-branch *before* merging the parent-branch back into `main`.
|
||||
|
||||
Tags
|
||||
----
|
||||
|
||||
Git tags are useful to label important revisions (think of *TENDER*,
|
||||
*CONSTRUCTION*, *RevA* etc..). Tags appear as a prefix in the revision list,
|
||||
which can be filtered to only show revisions with tags. Tags for the selected
|
||||
revision are also listed in full below the revision list along with their
|
||||
optional message text.
|
||||
|
||||
.. Note::
|
||||
|
||||
Tag names have the same limitations as branch names, names should be short
|
||||
and without spaces, but can contain unicode characters, emojis etc...
|
||||
BlenderBIM will not allow you to create invalid or duplicate tag names.
|
||||
Similar to commit messages, tag messages should be 50 characters or less,
|
||||
though there is no practical limit.
|
||||
|
||||
.. Warning::
|
||||
|
||||
Tags can be deleted locally, but Git is distributed, so if the tag has
|
||||
migrated to a remote repository it will reappear when you fetch changes
|
||||
from that repository.
|
||||
|
||||
Remote operations
|
||||
-----------------
|
||||
|
||||
Git is a *distributed revision control system*, your local repository can be a
|
||||
version of a remote repository and vice-versa. This is conceptually similar to
|
||||
local branching except this remote repository could belong to someone else or
|
||||
could be hosted by an online Git-forge service.
|
||||
|
||||
Your repository can have multiple remote repositories registered, each
|
||||
can have potentially multiple branches.
|
||||
|
||||
BlenderBIM allows you to make a local *clone* of a remote repository. You will
|
||||
need to provide a URL *origin* to fetch, and an empty local folder to become
|
||||
the local repository.
|
||||
|
||||
The *Fetch* operator retrieves new data from the remote repository. This isn't
|
||||
automatically merged, each branch fetched from the remote repository appears as
|
||||
a branch that can be browsed, switched-to or merged just like a local branch.
|
||||
These remote branches have prefixed names, eg. `origin/main`.
|
||||
|
||||
Once you have committed changes to your local repository, the *Push* operator
|
||||
tries to update the remote branch using changes from the selected local branch.
|
||||
|
||||
.. Warning::
|
||||
|
||||
Remote repositories can be accessed in multiple ways; ssh, ftp or https
|
||||
protocols, for example, can require authentication. This authentication may
|
||||
expect you to generate and upload ssh keys, store API tokens, save
|
||||
username/password pairs, or use some other form of credential.
|
||||
BlenderBIM can't configure these credentials for you, follow the
|
||||
configuration instructions provided by your online service before trying
|
||||
actions that require authentication.
|
||||
|
||||
Using other Git tools
|
||||
---------------------
|
||||
|
||||
BlenderBIM is not a full Git user interface, but it provides most of the tools
|
||||
you will need for day-to-day usage. In general if you need other Git
|
||||
functionality you can use external Git tools with your repository and any
|
||||
changes will be reflected in the BlenderBIM UI.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 9.2 KiB |
@@ -0,0 +1,51 @@
|
||||
============================
|
||||
Advanded Modeling Techniques
|
||||
============================
|
||||
|
||||
Complex modeling techniques for advanced users.
|
||||
|
||||
.. note::
|
||||
This page is a stub. More detailed content will be added in future updates.
|
||||
|
||||
Custom Parametric Wall Types
|
||||
----------------------------
|
||||
|
||||
[Content about creating custom parametric wall types]
|
||||
|
||||
Material assignment
|
||||
-------------------
|
||||
|
||||
:doc:`material_assignment`
|
||||
|
||||
Modeling Furniture and Fixtures
|
||||
-------------------------------
|
||||
|
||||
[Content about modeling furniture and fixtures]
|
||||
|
||||
Structural Elements
|
||||
-------------------
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`/users/structural_analysis/index`
|
||||
|
||||
[Content about modeling structural elements]
|
||||
|
||||
Multi-Story Buildings
|
||||
---------------------
|
||||
|
||||
[Content about modeling multi-story buildings]
|
||||
|
||||
Complex Structures
|
||||
------------------
|
||||
|
||||
[Content about modeling complex structures]
|
||||
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Sections
|
||||
:maxdepth: 2
|
||||
|
||||
material_assignment
|
||||
parametric_geometry
|
||||
@@ -0,0 +1,102 @@
|
||||
Material Assignment
|
||||
===================
|
||||
|
||||
This section covers how to assign and customize materials in your BIM model using the BlenderBIM Add-on.
|
||||
|
||||
Types of Material Definitions
|
||||
-----------------------------
|
||||
|
||||
In BIM, materials can be defined in several ways:
|
||||
|
||||
1. Single Material: The simplest approach, where an object has one material.
|
||||
2. Material Constituent Set: For objects with multiple materials (e.g., a window with an aluminum frame and glass glazing).
|
||||
3. Material Layer Set: Used for objects like walls or slabs, defining layers of different materials and thicknesses.
|
||||
4. Material Profile Set: Typically used for structural elements, defining materials in relation to a specific profile shape.
|
||||
|
||||
Basic Material Assignment
|
||||
-------------------------
|
||||
|
||||
To assign a material to an object:
|
||||
|
||||
1. Select the object in the 3D viewport.
|
||||
2. Go to the Material Properties panel.
|
||||
3. Click "New" to create a new material.
|
||||
4. Give the material a name.
|
||||
5. Set the material type (single, constituent set, layer set, or profile set).
|
||||
|
||||
Material Categories
|
||||
-------------------
|
||||
|
||||
Materials should be categorized for easy identification and scheduling:
|
||||
|
||||
- In IFC4 models, materials are automatically grouped into categories (e.g., concrete, steel, wood).
|
||||
- For IFC2x3 models, materials may appear uncategorized.
|
||||
|
||||
To view all materials in your project:
|
||||
|
||||
1. Go to the Materials schedule in the BlenderBIM panels.
|
||||
2. You'll see a list of all materials used in the model.
|
||||
|
||||
Best Practices for Material Naming
|
||||
----------------------------------
|
||||
|
||||
- Use standardized naming conventions for materials.
|
||||
- Names should match how materials are tagged in drawings, schedules, and specifications.
|
||||
- Avoid using color codes as material names.
|
||||
|
||||
Material Properties
|
||||
-------------------
|
||||
|
||||
In IFC4 models, materials can have associated properties:
|
||||
|
||||
1. Select a material in the Materials panel.
|
||||
2. Look for the "Common Properties" section.
|
||||
3. Set relevant properties for the material (e.g., density, thermal properties).
|
||||
|
||||
Note: IFC2x3 models have limited support for material properties.
|
||||
|
||||
Profiles for Structural Elements
|
||||
--------------------------------
|
||||
|
||||
For structural models, especially steel structures:
|
||||
|
||||
1. Use Material Profile Sets for elements like beams and columns.
|
||||
2. Name profiles according to standardized codes in your region.
|
||||
3. In IFC4 models, profiles can have associated structural properties.
|
||||
|
||||
To view profiles:
|
||||
|
||||
1. Look for the Profiles schedule in BlenderBIM panels.
|
||||
2. You should see a list of all profiles used in the project.
|
||||
|
||||
Color vs. Material
|
||||
------------------
|
||||
|
||||
It's important to distinguish between an object's color and its material:
|
||||
|
||||
- Color is a visual property for rendering and display.
|
||||
- Material defines the physical properties and composition of the object.
|
||||
|
||||
Avoid merging these concepts; an object can have a material without a specific color, and vice versa.
|
||||
|
||||
Saving and Exporting
|
||||
--------------------
|
||||
|
||||
Remember that BlenderBIM .ifc files cannot currently save textures from image files. To preserve both BIM data and detailed materials:
|
||||
|
||||
1. Save your project as a .blend file to retain all material and texture information for rendering.
|
||||
2. Also save as an .ifc file to store BIM data.
|
||||
|
||||
Always maintain both .blend and .ifc versions of your project to ensure all information is preserved.
|
||||
|
||||
IFC Version Considerations
|
||||
--------------------------
|
||||
|
||||
- IFC4 provides better support for material properties, categories, and profiles compared to IFC2x3.
|
||||
- Consider migrating to IFC4 for more comprehensive material information and structural analysis capabilities.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`../../structural_analysis/index`
|
||||
- :doc:`../../costing_and_scheduling/index`
|
||||
@@ -0,0 +1,37 @@
|
||||
Parametric Geometry
|
||||
===================
|
||||
|
||||
The BlenderBIM Add-on provides tools for creating and editing parametric geometry for IFC elements.
|
||||
Parametric geometry allows you to define building elements using parameters that can be easily adjusted, rather than modeling fixed geometry.
|
||||
|
||||
Key features of the parametric geometry system include:
|
||||
|
||||
- Predefined parametric types for common building elements like walls, windows, doors, slabs, etc.
|
||||
- Custom parametric types that can be created and saved
|
||||
- Parameters for dimensions, materials, profiles, and other properties
|
||||
- Automatic updating of geometry when parameters are changed
|
||||
- IFC-compliant parametric definitions that can be exchanged with other applications
|
||||
|
||||
To work with parametric geometry:
|
||||
|
||||
1. Select an IFC element in the 3D viewport
|
||||
2. Open the Geometric Relationships panel in the Scene Properties
|
||||
3. Expand the Parametric Geometry section
|
||||
4. Choose a parametric type from the dropdown or create a custom type
|
||||
5. Adjust the available parameters to define the element's geometry
|
||||
|
||||
Parameters may include options like:
|
||||
|
||||
- Overall dimensions (width, height, length)
|
||||
- Material layers and thicknesses
|
||||
- Profiles for extrusions
|
||||
- Opening sizes and positions
|
||||
- Component offsets and angles
|
||||
|
||||
The geometry will update in real-time as parameters are adjusted.
|
||||
The parametric definition is stored in the IFC data and can be exchanged with other applications that support parametric IFC.
|
||||
|
||||
Some elements like windows and doors have additional specialized parametric options in their respective tools.
|
||||
|
||||
Parametric geometry allows for efficient modeling and updating of BIM elements while maintaining IFC compatibility.
|
||||
Experiment with the available options to find parametric workflows that suit your modeling needs.
|
||||
@@ -0,0 +1,79 @@
|
||||
Creating Walls
|
||||
--------------
|
||||
|
||||
Walls are fundamental elements in any building design. BlenderBIM provides powerful tools for creating and manipulating wall elements.
|
||||
This section will guide you through the process of creating standalone walls, multiple connected walls, and joining walls using various techniques.
|
||||
|
||||
By following these steps and utilizing the various tools provided by BlenderBIM,
|
||||
you can efficiently create, modify, and join walls to form complex building layouts.
|
||||
Remember to use snapping and alignment tools to ensure precision in your model.
|
||||
|
||||
Creating a Standalone Wall
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Open an empty model (without predefined types).
|
||||
2. Click on the wall icon in the toolbar. The top bar will display "[No IfcWallType Found] | Name [TYPEX] | + Add IfcWallType".
|
||||
3. Edit [TYPEX] to use a wall type name of your choice (e.g., WALL100).
|
||||
4. Click "+ Add IfcWallType". The top bar will change, providing you with additional options.
|
||||
5. Click "Add" (or press SHIFT+A) to create a wall with its own type.
|
||||
6. You can adjust the wall's length and height using the parameters in the top bar.
|
||||
|
||||
Creating Multiple Connected Walls
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Activate the wall tool from the toolbar or use the shortcut (SHIFT + SPACEBAR, 6).
|
||||
2. Select the wall type from the dropdown menu, or create a new wall type if needed.
|
||||
3. Set the 3D cursor to the desired starting location for the wall by holding SHIFT and left-clicking in the 3D viewport.
|
||||
4. Add the first wall segment by pressing SHIFT + A.
|
||||
5. Adjust the length of the wall segment by dragging the "Length" parameter or entering a numeric value.
|
||||
6. Set the 3D cursor to the location for the next wall segment. Enable snapping to ensure precise connections between segments.
|
||||
7. Add the next wall segment by pressing SHIFT + A again.
|
||||
8. If needed, rotate the new wall segment by pressing SHIFT + R and adjusting the angle.
|
||||
9. Adjust the length of the new segment as required.
|
||||
10. Repeat steps 6-9 to create additional wall segments, setting the 3D cursor to the desired locations, until you've completed the wall layout.
|
||||
|
||||
Modifying and Joining Walls
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
BlenderBIM offers various tools for modifying and joining wall segments:
|
||||
|
||||
- **Extend (SHIFT + E)**: Extend an existing wall to intersect with another face.
|
||||
- **Butt (SHIFT + T)**: Join wall segments end-to-end.
|
||||
- **Mitre (SHIFT + Y)**: Create a mitre joint between two wall segments.
|
||||
- **Merge (SHIFT + M)**: Combine two wall segments into a single wall.
|
||||
- **Flip (SHIFT + F)**: Reverse the direction of a wall segment.
|
||||
- **Split (SHIFT + K)**: Divide a wall segment into two parts.
|
||||
- **Rotate 90° (SHIFT + R)**: Rotate the wall by 90 degrees.
|
||||
|
||||
To use these tools:
|
||||
|
||||
1. Select the wall segment(s) you want to modify.
|
||||
2. Use the appropriate shortcut or select the tool from the top bar.
|
||||
3. Follow the on-screen prompts or adjust parameters as needed.
|
||||
|
||||
Aligning Walls
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
You can align walls using the following options:
|
||||
|
||||
- **Align Exterior (SHIFT + X)**: Align the wall to its exterior face.
|
||||
- **Align Centerline (SHIFT + C)**: Align the wall to its centerline.
|
||||
- **Align Interior (SHIFT + V)**: Align the wall to its interior face.
|
||||
|
||||
Adding Openings
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
To add openings (e.g., for doors or windows) to your walls:
|
||||
|
||||
1. Select the wall where you want to add an opening.
|
||||
2. Click "Add Void" in the top bar or press SHIFT + O.
|
||||
3. Adjust the opening's size and position as needed.
|
||||
|
||||
Calculating Quantities
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
After creating your walls, you can calculate quantities to ensure accurate measurements:
|
||||
|
||||
1. Select the wall(s) you want to measure.
|
||||
2. Press Q or click "Calculate All Quantities" in the top bar.
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
Defining Rooms and Spaces
|
||||
=========================
|
||||
|
||||
.. note::
|
||||
This page is a stub. More detailed content will be added in future updates.
|
||||
|
||||
[Content about defining rooms and spaces]
|
||||
@@ -0,0 +1,44 @@
|
||||
=========================
|
||||
Basic Modeling Techniques
|
||||
=========================
|
||||
|
||||
Fundamental techniques for IFC modeling.
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`creating_walls`
|
||||
Learn how to create and modify walls in your IFC model.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`openings/index`
|
||||
Techniques for adding and customizing doors, windows and other openings.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`modeling_slabs_roofs`
|
||||
Guide to modeling slabs and different types of roofs.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`defining_rooms_spaces`
|
||||
Methods for defining and managing rooms and spaces in your model.
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Basic Modeling Techniques
|
||||
:maxdepth: 1
|
||||
|
||||
creating_walls
|
||||
openings/index
|
||||
modeling_slabs_roofs
|
||||
defining_rooms_spaces
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
Modeling Slabs and Roofs
|
||||
========================
|
||||
|
||||
.. note::
|
||||
This page is a stub. More detailed content will be added in future updates.
|
||||
|
||||
[Content about modeling slabs and roofs]
|
||||
@@ -0,0 +1,154 @@
|
||||
Door
|
||||
====
|
||||
|
||||
A door is a wall opening that allows passage between spaces, controlled access for people and goods.
|
||||
|
||||
In IFC, it's represented by the IfcDoor entity, which is a subtype of IfcBuildingElement.
|
||||
Doors play a crucial role in building design, affecting circulation, accessibility, and space functionality.
|
||||
|
||||
This section covers how to add and customize doors in your BIM model using the BlenderBIM Add-on.
|
||||
|
||||
Adding a Door
|
||||
-------------
|
||||
|
||||
1. Select the wall where you want to place the door.
|
||||
2. Set the 3D cursor on the wall at the desired door location.
|
||||
3. Click on the "Create Door" tool in the BlenderBIM toolbar.
|
||||
4. In the top bar, you'll see "[No IfcDoorType Found] | Name [TYPEX] | + Add IfcDoorType".
|
||||
5. Edit [TYPEX] to use a door type name of your choice (e.g., DOOR001).
|
||||
6. Click "+ Add IfcDoorType". The top bar will update with additional options.
|
||||
7. Click "Add" (or press SHIFT+A) to create a door with its own type.
|
||||
8. Adjust the door's width and height using the parameters in the top bar.
|
||||
|
||||
Placing a Door and Changing its Swing Direction
|
||||
-----------------------------------------------
|
||||
|
||||
1. Select the wall:
|
||||
- (Optional) Use the "Create Wall" tool to add a wall in your scene.
|
||||
- Select the wall where you want to place the door.
|
||||
|
||||
Selecting the wall is crucial as it ensures that the void relation between the door and the wall is automatically created.
|
||||
|
||||
2. Add a Door:
|
||||
- Use the "Create Door" tool from the toolbar.
|
||||
- Press SHIFT+A or click "Add" to place the door on the selected wall.
|
||||
|
||||
**Applying Void**
|
||||
|
||||
If you forgot to select the wall before placing the door, you'll need to manually create the void relation:
|
||||
|
||||
- Select both the wall and the door.
|
||||
- Click "Apply Void" (Shift+O) button.
|
||||
|
||||
.. important::
|
||||
If you need to use "Apply Void", do this before making any modifications to the door,
|
||||
as there are limitations with this function that may affect door orientation.
|
||||
|
||||
Usually, the Regen function will recalculate all the openings with existing void relationships.
|
||||
|
||||
3. Adjust Door Position (if needed):
|
||||
- With the door selected, use Blender's move tools to adjust its position along the wall.
|
||||
|
||||
4. Regenerate the Wall Geometry:
|
||||
- Select the wall.
|
||||
- Press Shift+G to regenerate the wall geometry, incorporating the door opening.
|
||||
|
||||
.. note::
|
||||
This step ensures the wall geometry is updated to include the door opening.
|
||||
|
||||
Moving the Door using Blender tools doesn't actually change the IFC model.
|
||||
Future versions need to improve UX in that regard.
|
||||
Synchronisation between the Blender scene and IFC model is an issue that has the highest priority.
|
||||
|
||||
5. Change Door Swing Direction:
|
||||
- Select only the door.
|
||||
- Press Shift+F to flip the door. It rotates the door by 180 degrees and moves the pivot point.
|
||||
- Locate the "Parametric Geometry" panel in the `Scene Properties > Geometry and Materials` subtab.
|
||||
- Find the "Door" section within this panel.
|
||||
- Change the "Operation Type" to "SINGLE_SWING_RIGHT".
|
||||
|
||||
.. note::
|
||||
The Shift+F shortcut is currently a hidden feature and not available as a button in the Door tool interface.
|
||||
|
||||
You may need to experiment with the combination of changing the Operation Type and using Shift+F to achieve the desired orientation.
|
||||
|
||||
6. Final Wall Geometry Regeneration:
|
||||
- Select the wall again.
|
||||
- Press Shift+G one more time to ensure all changes are properly applied.
|
||||
|
||||
Additional Notes
|
||||
----------------
|
||||
|
||||
- The Shift+F shortcut for flipping the door is not visible in the Door tool interface.
|
||||
This functionality may be added as a visible button in future updates.
|
||||
- Always use Shift+G (Regenerate) after making changes
|
||||
to ensure the wall and door geometries are correctly updated.
|
||||
- Avoid using Shift+O (Apply Void) as it may cause issues
|
||||
with the door's orientation.
|
||||
|
||||
|
||||
Modifying Doors
|
||||
---------------
|
||||
|
||||
.. note::
|
||||
Some functionality is not implemented.
|
||||
|
||||
You can modify doors using various tools:
|
||||
|
||||
- Resize: Adjust the width and height parameters in the top bar.
|
||||
- Move: Use Blender's standard move tools to reposition the door.
|
||||
- Flip: Change the opening direction using the flip tool (Shift+F).
|
||||
|
||||
.. note::
|
||||
After moving a door, you need to recalculate the void in the wall. To do this:
|
||||
|
||||
- Select the wall containing the moved door.
|
||||
- Click on the "Regen" (:kbd:`Shift` + :kbd:`G`) button in the top bar or use the appropriate shortcut.
|
||||
- This ensures that the opening in the wall is correctly positioned after moving the door.
|
||||
|
||||
If Regen operation doesn't achive the required result, use Apply Void function:
|
||||
|
||||
- Click on the "Apply Void" (:kbd:`Shift` + :kbd:`O`) button in the top bar or use the appropriate shortcut.
|
||||
- This ensures that the opening is linked to the wall.
|
||||
|
||||
|
||||
Door Properties
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
.. note::
|
||||
This functionality is not implemented.
|
||||
|
||||
After adding a door, you can customize its properties:
|
||||
|
||||
1. Select the door in the 3D viewport.
|
||||
2. Go to the ... panel.
|
||||
3. Find the ... section.
|
||||
4. Here you can set various properties such as fire rating, u-value, or any custom properties required for your project.
|
||||
|
||||
.. note::
|
||||
This functionality is not implemented.
|
||||
|
||||
You can customize various properties of the door:
|
||||
|
||||
- Dimensions (width, height, thickness)
|
||||
- Opening direction
|
||||
- Door type (e.g. single swing, double swing, sliding)
|
||||
- Material
|
||||
|
||||
|
||||
Creating Multiple Doors
|
||||
-----------------------
|
||||
|
||||
To create multiple doors of the same type:
|
||||
|
||||
1. Select the desired door type from the dropdown menu in the top bar.
|
||||
2. Set the 3D cursor on a wall where you want to place a new door.
|
||||
3. Select the wall
|
||||
4. Click "Add" (or press SHIFT+A) for each new door you want to create.
|
||||
5. Adjust the 3D cursor, position and parameters for each new door as needed.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`../creating_walls`
|
||||
- :doc:`../../advanced_modeling/material_assignment`
|
||||
@@ -0,0 +1,66 @@
|
||||
Openings
|
||||
========
|
||||
|
||||
This section covers the creation and management of openings in BlenderBIM.
|
||||
Openings are crucial elements in building design, serving various purposes such as passage, ventilation, and lighting.
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`door`
|
||||
Learn how to add and customize doors in your BIM model.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`window`
|
||||
Discover the process of creating and modifying windows.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`opening`
|
||||
Create openings without fillings for special architectural features.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
In the context of Building Information Modeling (BIM) and the Industry Foundation Classes (IFC)
|
||||
standard, openings are represented through a combination of elements:
|
||||
|
||||
1. Voids: Represented by IfcOpeningElement, these are the actual cut-outs in the wall.
|
||||
2. Fillings: These are the elements that occupy the voids, such as doors (IfcDoor) or windows (IfcWindow).
|
||||
3. Relationships: These are abstract objects that connect fillings to voids and voids to elements in which they're created.
|
||||
|
||||
BlenderBIM provides tools to create and manage these elements:
|
||||
|
||||
- Door Creation Tool: For adding doors to walls.
|
||||
- Window Creation Tool: For adding windows to walls.
|
||||
- Wall Creation Tool > Void Application: For creating openings without fillings
|
||||
(currently achieved by creating a door or window and removing it
|
||||
or by using "Add Void" feature of the Create Wall tool or any element).
|
||||
|
||||
These tools allow you to:
|
||||
|
||||
- Create openings with precise dimensions and positions.
|
||||
- Modify opening properties and geometries.
|
||||
- Manage the relationships between walls, voids, and fillings.
|
||||
|
||||
The following pages provide detailed guides on working with each type of wall opening in BlenderBIM.
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Wall Openings
|
||||
:maxdepth: 1
|
||||
|
||||
door
|
||||
window
|
||||
opening
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`../creating_walls`
|
||||
@@ -0,0 +1,64 @@
|
||||
Opening Without Filling
|
||||
=======================
|
||||
|
||||
An opening without a filling is a void in a building element,
|
||||
typically a wall, that doesn't contain a door or window.
|
||||
|
||||
These openings can serve various purposes such as ventilation, pass-throughs, service penetrations, or architectural features.
|
||||
|
||||
In IFC, it's represented by the IfcOpeningElement entity, which is a subtype of IfcFeatureElementSubtraction.
|
||||
|
||||
This section covers how to create openings without fillings in your BIM model using the BlenderBIM Add-on.
|
||||
|
||||
|
||||
Creating an Opening Without Filling
|
||||
-----------------------------------
|
||||
|
||||
Currently, there isn't a dedicated tool for creating openings without fillings.
|
||||
However, every door or window is a filling for an opening element, so it's created implicitly.
|
||||
|
||||
It means, you can achieve an opening without a filling by creating a door or window and then removing it and its type.
|
||||
|
||||
Here's the process:
|
||||
|
||||
1. Select the wall where you want to create the opening.
|
||||
2. Set the 3D cursor on the wall at the desired opening location.
|
||||
3. Use either the "Create Door" or "Create Window" tool from the toolbar,
|
||||
depending on the shape you need for your opening.
|
||||
4. Follow the steps to create a door or window as described in their respective sections.
|
||||
5. After creating the door or window, select it in the 3D viewport and press Delete.
|
||||
6. In the Outline panel, find the "Type" field and press Delete.
|
||||
|
||||
This process will leave you with an opening element without a filling.
|
||||
|
||||
.. note::
|
||||
Future versions of BlenderBIM may include a dedicated tool for creating openings without fillings, which would simplify this process.
|
||||
|
||||
Additionally, you can create an opening by using the "Add Void" button in Create Wall tool.
|
||||
This tool will add an Opening IFC element to the Outline and its 3D representation in the 3D Vieport.
|
||||
Blender move and scale tools will allow you to modify the opening.
|
||||
After you finished with modifications, you can press the check mark to complete the void.
|
||||
|
||||
Modifying Openings
|
||||
------------------
|
||||
|
||||
You can modify openings using various tools:
|
||||
|
||||
- Resize: Adjust the width and height parameters in the top bar.
|
||||
- Move: Use Blender's standard move tools to reposition the opening.
|
||||
|
||||
.. note::
|
||||
The opening is hidden object. To show it, press the "eye" button hear the "Add Void" in the Create Wall tool.
|
||||
|
||||
.. note::
|
||||
After moving an opening, you need to recalculate the void in the wall. To do this:
|
||||
|
||||
- Click on checkmark near the "Add Void" in the Create Wall tool.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`../creating_walls`
|
||||
- :doc:`door`
|
||||
- :doc:`window`
|
||||
@@ -0,0 +1,145 @@
|
||||
Window
|
||||
======
|
||||
|
||||
A window is an opening that allows light and air to enter a building, providing ventilation and views to the outside.
|
||||
|
||||
In IFC, it's represented by the IfcWindow entity, which is a subtype of IfcBuildingElement.
|
||||
Windows play a crucial role in building design, affecting natural lighting, ventilation, energy efficiency, and aesthetics.
|
||||
|
||||
This section covers how to add and customize windows in your BIM model using the BlenderBIM Add-on.
|
||||
|
||||
Adding a Window
|
||||
---------------
|
||||
|
||||
1. Select the wall where you want to place the window.
|
||||
2. Set the 3D cursor on the wall at the desired window location.
|
||||
3. Click on the "Create Window" tool in the BlenderBIM toolbar.
|
||||
4. In the top bar, you'll see "[No IfcWindowType Found] | Name [TYPEX] | + Add IfcWindowType".
|
||||
5. Edit [TYPEX] to use a window type name of your choice (e.g., WINDOW001).
|
||||
6. Click "+ Add IfcWindowType". The top bar will update with additional options.
|
||||
7. Click "Add" (or press SHIFT+A) to create a window with its own type.
|
||||
8. Adjust the window's width and height using the parameters in the top bar.
|
||||
|
||||
Placing a Window and Changing its Configuration
|
||||
-----------------------------------------------
|
||||
|
||||
1. Select the wall:
|
||||
- (Optional) Use the "Create Wall" tool to add a wall in your scene.
|
||||
- Select the wall where you want to place the window.
|
||||
|
||||
Selecting the wall is crucial as it ensures that the void relation between the window and the wall is automatically created.
|
||||
|
||||
2. Add a Window:
|
||||
- Use the "Create Window" tool from the toolbar.
|
||||
- Press SHIFT+A or click "Add" to place the window on the selected wall.
|
||||
|
||||
**Applying Void**
|
||||
|
||||
If you forgot to select the wall before placing the window, you'll need to manually create the void relation:
|
||||
|
||||
- Select both the wall and the window.
|
||||
- Click "Apply Void" (Shift+O) button.
|
||||
|
||||
.. important::
|
||||
If you need to use "Apply Void", do this before making any modifications to the window,
|
||||
as there are limitations with this function that may affect window orientation.
|
||||
|
||||
Usually, the Regen function will recalculate all the openings with existing void relationships.
|
||||
|
||||
3. Adjust Window Position (if needed):
|
||||
- With the window selected, use Blender's move tools to adjust its position along the wall.
|
||||
|
||||
4. Regenerate the Wall Geometry:
|
||||
- Select the wall.
|
||||
- Press Shift+G to regenerate the wall geometry, incorporating the window opening.
|
||||
|
||||
.. note::
|
||||
This step ensures the wall geometry is updated to include the window opening.
|
||||
|
||||
Moving the Window using Blender tools doesn't actually change the IFC model.
|
||||
Future versions need to improve UX in that regard.
|
||||
Synchronisation between the Blender scene and IFC model is an issue that has the highest priority.
|
||||
|
||||
5. Change Window Configuration:
|
||||
- Select only the window.
|
||||
- Locate the "Parametric Geometry" panel in the `Scene Properties > Geometry and Materials` subtab.
|
||||
- Find the "Window" section within this panel.
|
||||
- Change the "Operation Type" to the desired configuration (e.g., "DOUBLE_PANEL").
|
||||
|
||||
6. Final Wall Geometry Regeneration:
|
||||
- Select the wall again.
|
||||
- Press Shift+G one more time to ensure all changes are properly applied.
|
||||
|
||||
Modifying Windows
|
||||
-----------------
|
||||
|
||||
.. note::
|
||||
Some functionality is not implemented.
|
||||
|
||||
You can modify windows using various tools:
|
||||
|
||||
- Resize: Adjust the width and height parameters in the top bar.
|
||||
- Move: Use Blender's standard move tools to reposition the window.
|
||||
- Flip: Change the opening direction using the flip tool (if available).
|
||||
|
||||
.. note::
|
||||
After moving a window, you need to recalculate the void in the wall. To do this:
|
||||
|
||||
- Select the wall containing the moved window.
|
||||
- Click on the "Regen" (:kbd:`Shift` + :kbd:`G`) button in the top bar or use the appropriate shortcut.
|
||||
- This ensures that the opening in the wall is correctly positioned after moving the window.
|
||||
|
||||
If Regen operation doesn't achieve the required result, use Apply Void function:
|
||||
|
||||
- Click on the "Apply Void" (:kbd:`Shift` + :kbd:`O`) button in the top bar or use the appropriate shortcut.
|
||||
- This ensures that the opening is linked to the wall.
|
||||
|
||||
Window Properties
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. note::
|
||||
This functionality is not implemented.
|
||||
|
||||
After adding a window, you can customize its properties:
|
||||
|
||||
1. Select the window in the 3D viewport.
|
||||
2. Go to the ... panel.
|
||||
3. Find the ... section.
|
||||
4. Here you can set various properties such as thermal transmittance (U-value), solar heat gain coefficient, or any custom properties required for your project.
|
||||
|
||||
.. note::
|
||||
This functionality is not implemented.
|
||||
|
||||
Customize window properties such as:
|
||||
|
||||
- Dimensions
|
||||
- Window type (e.g. fixed, casement, sliding)
|
||||
- Glazing options
|
||||
- Frame material
|
||||
|
||||
Creating Multiple Windows
|
||||
-------------------------
|
||||
|
||||
To create multiple windows of the same type:
|
||||
|
||||
1. Select the desired window type from the dropdown menu in the top bar.
|
||||
2. Set the 3D cursor on a wall where you want to place the new window.
|
||||
3. Select the wall
|
||||
4. Click "Add" (or press SHIFT+A) for each new window you want to create.
|
||||
5. Adjust the 3D cursor, position and parameters for each new window as needed.
|
||||
|
||||
Calculating Quantities
|
||||
----------------------
|
||||
|
||||
After creating windows, you can calculate quantities:
|
||||
|
||||
1. Select the window(s) you want to measure.
|
||||
2. Press Q or click "Calculate All Quantities" in the top bar.
|
||||
|
||||
This will update the quantity information for the selected elements.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`../creating_walls`
|
||||
- :doc:`../../advanced_modeling/material_assignment`
|
||||
@@ -0,0 +1,4 @@
|
||||
Classification and Types
|
||||
========================
|
||||
|
||||
IFC classification hierarchy and the concept of types and occurrences.
|
||||
@@ -0,0 +1,81 @@
|
||||
Geometry and Representations
|
||||
============================
|
||||
|
||||
Understanding IFC Elements and Geometry
|
||||
---------------------------------------
|
||||
|
||||
In BlenderBIM, it's crucial to understand the relationship between IFC elements, their classification, types, and geometry.
|
||||
These concepts work together but serve different purposes.
|
||||
|
||||
IFC Classification
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Every IFC element has a two-level classification:
|
||||
|
||||
1. IFC Class: The top level (e.g., IfcWall)
|
||||
2. Predefined Type: The second level (e.g., PARTITIONING)
|
||||
|
||||
This classification is purely for categorization and filtering. It doesn't determine the element's geometry or appearance.
|
||||
|
||||
Types and Occurrences
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
IFC uses the concept of "Types" and "Occurrences":
|
||||
|
||||
- Types: Define common properties or materials shared by multiple elements.
|
||||
- Occurrences: Individual instances of a type.
|
||||
|
||||
If a type has geometry associated with it, all its occurrences must have the same geometry (similar to instancing or cloning in other applications).
|
||||
However, if a type has no material or geometry, it doesn't impact the geometry of its occurrences.
|
||||
|
||||
Representations
|
||||
---------------
|
||||
|
||||
In IFC, unlike traditional 3D modeling:
|
||||
|
||||
- An object may have no geometry, one geometry, or multiple geometries.
|
||||
- Each geometry is called a "Representation".
|
||||
- Representations are differentiated by their "Context". A "Context" defines what the geometry is used for (e.g., 3D Body, 2D Plan, etc.).
|
||||
|
||||
The most common context is the 3D Body context, which represents the physical shape of the object.
|
||||
|
||||
Representation Types
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
IFC supports various geometry types:
|
||||
|
||||
- Mesh-like: Facetations, tessellations, triangulations, or planar breps.
|
||||
- Solid modeling: CSGs, swept solids, extrusions, lofts, etc.
|
||||
|
||||
In BlenderBIM, you can create simple mesh geometries (like a cube) and assign them to IFC elements.
|
||||
However, for more complex elements like walls, slabs, or columns, other representation types are more appropriate.
|
||||
|
||||
Parametric Materials
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
IFC standardizes certain parametric modeling techniques:
|
||||
|
||||
1. Material Layers: Uses an axis line and material layers to derive the body of an object by extruding layers of different thicknesses to a particular height.
|
||||
2. Material Profiles: Extrudes a profile (arbitrary or parametric) along a 3D axis.
|
||||
|
||||
These are typically defined at the type level and inherited by occurrences.
|
||||
|
||||
Working with Representations in BlenderBIM
|
||||
------------------------------------------
|
||||
|
||||
- Creating swept solids: Currently, the best method is to use parametric material layers (e.g., for walls) or material profiles.
|
||||
- Mesh editing: For mesh-like representations, you can edit them directly in Blender's edit mode.
|
||||
- Non-mesh modeling: BlenderBIM currently has limited tools for direct modeling of non-mesh geometries.
|
||||
Future updates will include more intuitive interfaces for this purpose.
|
||||
- Deleting representations: This should be avoided as it can create invalid IFC data.
|
||||
If you delete a representation, the element should no longer be visible in the 3D view.
|
||||
|
||||
.. note::
|
||||
The current implementation allows low-level manipulation of IFC data, which requires a deep understanding of IFC rules.
|
||||
Users should exercise caution when manually editing representations or other low-level IFC data.
|
||||
|
||||
Future Developments
|
||||
-------------------
|
||||
|
||||
The BlenderBIM team plans to develop more intuitive interfaces for non-mesh direct modeling tools in future versions.
|
||||
This will make it easier to create and manipulate complex geometric representations without needing to understand the intricacies of IFC data structures.
|
||||
@@ -0,0 +1,10 @@
|
||||
Basic Spatial Objects
|
||||
=====================
|
||||
|
||||
IFC organizes building information in a hierarchical structure:
|
||||
|
||||
- IfcProject
|
||||
- IfcSite
|
||||
- IfcBuilding
|
||||
- IfcBuildingStorey
|
||||
- IfcSpace
|
||||
@@ -0,0 +1,108 @@
|
||||
Working with Representations
|
||||
----------------------------
|
||||
|
||||
BlenderBIM provides tools to view, edit, and manage representations of IFC elements directly within Blender's interface.
|
||||
This section covers how to work with these representations effectively.
|
||||
|
||||
Viewing Representations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To view the representations of an IFC element:
|
||||
|
||||
1. Select the element in the 3D viewport.
|
||||
2. Navigate to Scene > Geometry and Materials > Representations in the Properties panel.
|
||||
3. You'll see a list of all representations associated with the element, including their context and type.
|
||||
|
||||
Editing Representations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To edit an existing representation:
|
||||
|
||||
1. In the Representations panel, click on the representation you want to edit to make it active.
|
||||
2. Switch to Edit Mode in the 3D viewport.
|
||||
3. Make your desired changes to the geometry.
|
||||
4. Once finished, click "Manually Save Representation" in the Representation Utilities section.
|
||||
|
||||
.. note::
|
||||
Not all representation types can be directly edited. For example, SweptSolid representations cannot be modified in this way.
|
||||
|
||||
Adding Representations
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To add a new representation to an element:
|
||||
|
||||
1. Select the element in the 3D viewport.
|
||||
2. In the Representations panel, use the dropdown menu at the top to select the desired context (e.g., Model, Plan).
|
||||
3. Click the "+" button next to the dropdown.
|
||||
4. In the dialog that appears, choose the method for creating the representation (e.g., Trace Outline, Bounding Box).
|
||||
5. Follow any additional prompts to complete the creation of the new representation.
|
||||
|
||||
Common Representation Types in BlenderBIM
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
BlenderBIM supports several representation types, each suitable for different purposes:
|
||||
|
||||
1. SweptSolid
|
||||
- RepresentationIdentifier: 'Body'
|
||||
- RepresentationType: 'SweptSolid'
|
||||
- Description: Used for 3D shapes created by extruded area solids or revolved area solids.
|
||||
- Typical use: Walls, columns, beams with simple profiles.
|
||||
|
||||
2. Tessellation
|
||||
- RepresentationIdentifier: 'Body'
|
||||
- RepresentationType: 'Tessellation'
|
||||
- Description: Represents 3D shapes using tessellated surface models.
|
||||
- Typical use: Complex geometries, imported meshes.
|
||||
|
||||
3. Clipping
|
||||
- RepresentationIdentifier: 'Body'
|
||||
- RepresentationType: 'Clipping'
|
||||
- Description: 3D shapes created using Boolean operations with half-spaces.
|
||||
- Typical use: Complex shapes with cutouts or intersections.
|
||||
|
||||
4. Curve2D
|
||||
- RepresentationIdentifier: 'Axis'
|
||||
- RepresentationType: 'Curve2D'
|
||||
- Description: 2D curves, often used for wall axes or material layer alignments.
|
||||
- Typical use: Defining the centerline of walls.
|
||||
|
||||
5. Curve3D
|
||||
- RepresentationIdentifier: 'Axis'
|
||||
- RepresentationType: 'Curve3D'
|
||||
- Description: 3D curves, used for axes of longitudinal elements.
|
||||
- Typical use: Defining the profile of walls, openings.
|
||||
|
||||
|
||||
Converting Representations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
BlenderBIM offers tools to convert between different representation types:
|
||||
|
||||
1. Select the representation you want to convert.
|
||||
2. In the Representation Utilities section, you'll find options like:
|
||||
- Convert To Tessellation
|
||||
- Convert To Rectangle Extrusion
|
||||
- Convert To Circle Extrusion
|
||||
- Convert To Arbitrary Extrusion
|
||||
|
||||
.. warning::
|
||||
Converting representations may result in loss of parametric information. Use these tools with caution.
|
||||
|
||||
Best Practices
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
- Always use the appropriate representation type for the element you're modeling.
|
||||
- Be cautious when editing representations directly, as this may affect the element's relationship with its type or other elements.
|
||||
- When possible, use parametric definitions (like Material Layers for walls) instead of direct mesh editing.
|
||||
- Regularly check the IFC validity of your model after making significant changes to representations.
|
||||
|
||||
Future Developments
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The BlenderBIM team is continually working on improving the representation editing experience. Future updates may include:
|
||||
|
||||
- More intuitive interfaces for non-mesh modeling.
|
||||
- Enhanced tools for working with parametric representations.
|
||||
- Improved validation and error checking when editing representations.
|
||||
|
||||
For the latest updates and feature requests, refer to the BlenderBIM Add-on GitHub repository.
|
||||
@@ -0,0 +1,66 @@
|
||||
============
|
||||
IFC modeling
|
||||
============
|
||||
|
||||
This chapter covers the essential aspects of working with Industry Foundation Classes (IFC) in BlenderBIM. It is divided into five main sections:
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`understanding_ifc`
|
||||
An introduction to IFC standards, schemas, and concepts.
|
||||
This section explains the structure of IFC data, key spatial objects, and the role of organizations
|
||||
like buildingSMART in maintaining IFC standards. It also covers IfcOpenShell and the broader ecosystem
|
||||
of open standards in the AEC industry.
|
||||
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`importing_viewing_models`
|
||||
A guide on how to import existing IFC models into BlenderBIM and navigate them effectively.
|
||||
This section includes techniques for inspecting and querying IFC data within the BlenderBIM environment.
|
||||
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`starting_new_project`
|
||||
Instructions on creating and setting up a new IFC project from scratch in BlenderBIM.
|
||||
This covers initial project setup, including advanced options for more complex projects.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`basic_modeling/index`
|
||||
An exploration of fundamental IFC modeling techniques, including:
|
||||
- Creating walls
|
||||
- Adding doors and windows
|
||||
- Modeling slabs and roofs
|
||||
- Defining rooms and spaces
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`advanced_modeling/index`
|
||||
A deep dive into more complex modeling techniques for experienced users, including:
|
||||
- Creating custom parametric wall types
|
||||
- Modeling furniture and fixtures
|
||||
- Working with structural elements
|
||||
- Designing multi-story buildings
|
||||
- Modeling complex structures
|
||||
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: IFC Modeling
|
||||
:maxdepth: 2
|
||||
|
||||
understanding_ifc
|
||||
importing_viewing_models
|
||||
starting_new_project
|
||||
basic_modeling/index
|
||||
advanced_modeling/index
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
@@ -0,0 +1,4 @@
|
||||
Importing and Viewing IFC Models
|
||||
================================
|
||||
|
||||
[Content about importing and viewing IFC models]
|
||||
@@ -0,0 +1,92 @@
|
||||
============================
|
||||
BlenderBIM Interface Guide
|
||||
============================
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
The BlenderBIM interface extends Blender's powerful 3D environment with specialized tools for Building Information Modeling (BIM). This guide will help you navigate the BlenderBIM interface and understand its key components.
|
||||
|
||||
BlenderBIM Workspace
|
||||
====================
|
||||
|
||||
When you start Blender with BlenderBIM installed, you can switch to the BlenderBIM workspace
|
||||
by clicking on the BIM workspace tab at the top of the Blender window.
|
||||
|
||||
This workspace is preconfigured with the most commonly used panels and tools for BIM workflows.
|
||||
|
||||
|
||||
Key Interface Elements
|
||||
======================
|
||||
|
||||
Properties Extended
|
||||
-------------------
|
||||
|
||||
The Properties Editor is extended to provide IFC-specific properties and settings.
|
||||
|
||||
- Scene
|
||||
- Project Information
|
||||
- Tool
|
||||
- Object
|
||||
|
||||
BIM Toolbar
|
||||
-----------
|
||||
|
||||
The BIM toolbar, typically located at the left of the 3D Viewport, contains shortcuts to frequently used BIM tools:
|
||||
|
||||
- Explore tool
|
||||
- Create various building elements
|
||||
- Create annotations, measure distance and angles, calculate volumes, etc
|
||||
|
||||
|
||||
IFC Tree View
|
||||
-------------
|
||||
|
||||
Found in the Outliner, the IFC Tree View displays the hierarchical structure of your BIM model:
|
||||
|
||||
- Spatial Structure (Site, Building, Storey)
|
||||
- Building Elements
|
||||
- Types
|
||||
|
||||
Customizing the Interface
|
||||
=========================
|
||||
|
||||
BlenderBIM respects Blender's highly customizable interface. You can:
|
||||
|
||||
- Rearrange editors and panels
|
||||
- Save custom workspace layouts
|
||||
- Create custom shortcuts for BIM operations
|
||||
|
||||
Tips for Efficient Use
|
||||
======================
|
||||
|
||||
1. Familiarize yourself with IFC classes and their properties.
|
||||
2. Utilize Blender's search function (F3) to quickly access BlenderBIM tools.
|
||||
|
||||
|
||||
Next Steps
|
||||
==========
|
||||
|
||||
Now that you're familiar with the BlenderBIM interface, you have two main paths to continue your learning:
|
||||
|
||||
1. Proceed with IFC Modeling:
|
||||
If you're ready to start creating and working with BIM models, you can move on to:
|
||||
|
||||
- :doc:`IFC Modeling Basics </users/modeling/ifc_modeling>`
|
||||
|
||||
2. Dive deeper into the User Interface:
|
||||
If you want to explore more details about the BlenderBIM interface, you can refer to:
|
||||
|
||||
- :doc:`User Interface Reference </users/user_interface>`
|
||||
|
||||
Choose the path that best suits your current needs and learning style. You can always come back to explore the other option later.
|
||||
|
||||
Remember, as you become more comfortable with the interface and basic modeling, you can explore more advanced topics such as:
|
||||
|
||||
- :doc:`Generating Documentation </users/drawing/index>`
|
||||
- :doc:`Advanced BIM Techniques </users/advanced/index>`
|
||||
|
||||
The BlenderBIM interface is designed to integrate seamlessly with Blender while providing powerful BIM-specific functionality.
|
||||
As you progress, you'll find your BIM workflow becoming increasingly efficient and productive.
|
||||
|
||||
|
||||
@@ -0,0 +1,143 @@
|
||||
Starting a New IFC Project
|
||||
==========================
|
||||
|
||||
To ensure the best start for your IFC project, follow these steps:
|
||||
|
||||
Start a New Blender Session
|
||||
---------------------------
|
||||
|
||||
- Close any open Blender windows.
|
||||
- Launch a fresh instance of Blender.
|
||||
|
||||
This ensures there are no lingering connections or data from previous projects.
|
||||
|
||||
Create a New IFC Project
|
||||
------------------------
|
||||
|
||||
There are two main methods to create a new IFC project:
|
||||
|
||||
Using File Menu (Recommended)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. figure:: images/file_new-ifc-project-submenu.png
|
||||
:alt: New IFC Project submenu options
|
||||
|
||||
New IFC Project submenu options
|
||||
|
||||
1. Go to File > New IFC Project.
|
||||
2. Choose from the following options:
|
||||
|
||||
- New Metric (m) Project: Creates a project using meters as the base unit.
|
||||
- New Metric (mm) Project: Creates a project using millimeters as the base unit.
|
||||
- New Imperial (ft) Project: Creates a project using feet as the base unit.
|
||||
- New Demo Project: Creates a project with pre-populated demo content.
|
||||
- New Project Wizard: Opens the Project Info panel for customized setup.
|
||||
|
||||
3. If you chose one of the first four options, your project will be created immediately.
|
||||
4. New Project Wizard is detailed below.
|
||||
|
||||
Using New Project Wizard / Scene Properties
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. figure:: images/project_wizard.png
|
||||
:alt: Project Wizard in `Scene Properties > Project Overview` subtab
|
||||
|
||||
Project Wizard in `Scene Properties > Project Overview` subtab
|
||||
|
||||
|
||||
1. You can access this method in two ways:
|
||||
|
||||
- Go to `File > New IFC Project > New Project Wizard`
|
||||
- Navigate to Scene `Properties > Project Overview > Project Info`
|
||||
|
||||
2. In the Project Info panel:
|
||||
|
||||
- Choose the IFC Schema (IFC2X3, IFC4, or IFC4X3).
|
||||
- Select the Unit System (Metric or Imperial).
|
||||
- Choose Length, Area, and Volume units.
|
||||
- Select a Template (Blank or IFC4 Demo Template).
|
||||
|
||||
3. Click the "Create Project" button.
|
||||
|
||||
Cleaning the scene
|
||||
------------------
|
||||
|
||||
- After creating a new project, BlenderBIM considers the presence of three default Blender objects:
|
||||
a mesh (usually the default cube), a camera, and a light.
|
||||
- If have scene setup like this, BlenderBIM will clean it up
|
||||
- Any customizations you make to the Blender scene before finalizing the IFC project creation will be preserved.
|
||||
|
||||
If you like, you can delete the default cube, camera and light manually. Or create your own objects.
|
||||
This is only recommended for users proficient in Blender. Otherwise, use the File menu or Create Project button in New Project Wizard.
|
||||
|
||||
Project Initialization
|
||||
----------------------
|
||||
|
||||
.. figure:: images/outliner.png
|
||||
:alt: A basic spatial tree in the Outliner
|
||||
|
||||
A basic spatial tree in the Outliner
|
||||
|
||||
|
||||
- A basic spatial tree will be created with `IfcProject > IfcSite > IfcBuilding > IfcStorey`.
|
||||
- You can view this structure in the Outliner.
|
||||
- The Project Info panel will update to show details about your new IFC project.
|
||||
|
||||
Saving
|
||||
------
|
||||
|
||||
.. figure:: images/project-info_unsaved.png
|
||||
:alt: Project Info in Unsaved Mode
|
||||
|
||||
Project Info in Unsaved Mode
|
||||
|
||||
|
||||
After creating a new project, BlenderBIM enters an Unsaved Mode. It's important to understand how saving works in BlenderBIM:
|
||||
|
||||
**Saving IFC Project**:
|
||||
- Using the keyboard shortcut `Ctrl+S` or `File > Save IFC Project` will save only the `.ifc` file.
|
||||
- The `.blend` file remains unsaved and unnamed after this operation.
|
||||
|
||||
**Initial Save**:
|
||||
- On your first save, you'll be prompted to choose a location and name for your `.ifc` file.
|
||||
- This does not automatically save a `.blend` file.
|
||||
|
||||
**Blend File Saving**:
|
||||
- To save the `.blend` file, you need to use Blender's standard `File > Save` or `File > Save As...` options.
|
||||
- This operation is separate from saving the IFC project.
|
||||
|
||||
**File Menu Options**:
|
||||
- `File > Save IFC Project` saves only the `.ifc` file.
|
||||
- `File > Save IFC Project As...` allows you to save the .ifc file to a new location or with a new name.
|
||||
- Standard Blender save options (`File > Save`, `File > Save As...`) only affect the .blend file.
|
||||
|
||||
**Opening Projects**:
|
||||
- `File > Open IFC Project` loads only the `.ifc` file. It does not automatically load a corresponding `.blend` file.
|
||||
- To open a `.blend` file associated with an IFC project, you need to open it separately using Blender's standard open options.
|
||||
|
||||
**Best Practices**:
|
||||
- Always use `File > Open IFC Project` to load your BIM data.
|
||||
- If you want to preserve Blender-specific settings or custom scene setups, save the `.blend` file separately.
|
||||
- Be aware that opening a `.blend` file directly will not load the associated IFC data.
|
||||
|
||||
**For BIM Workflows**:
|
||||
- Focus on the `.ifc` file as the primary source of truth for your BIM data.
|
||||
- Use `.blend` files if you need to preserve specific Blender setups or visual configurations, but remember these are secondary to the IFC data.
|
||||
|
||||
Remember, in BlenderBIM, the `.ifc` file contains the critical BIM information.
|
||||
The `.blend` file is primarily for Blender-specific settings and visual representations.
|
||||
Always ensure your IFC project is saved before closing Blender or starting a new session.
|
||||
If you need to preserve Blender-specific configurations, save the `.blend` file separately.
|
||||
|
||||
Remember to save your work regularly using `File > Save IFC Project`.
|
||||
|
||||
Next Steps
|
||||
----------
|
||||
|
||||
- Begin modeling your building elements (walls, slabs, etc.).
|
||||
- Set up project properties and classifications.
|
||||
- Start defining spaces and zones within your building.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`/users/user_interface/property_editor/scene_editor/project_overview/project_info`
|
||||
- :doc:`/users/user_interface/topbar`
|
||||
@@ -0,0 +1,80 @@
|
||||
=================
|
||||
Understanding IFC
|
||||
=================
|
||||
|
||||
Industry Foundation Classes (IFC) is an open, international standard for Building Information Modeling (BIM) data.
|
||||
It provides a standardized way to describe, exchange, and share information about building and construction industry data.
|
||||
|
||||
IFC Schema
|
||||
----------
|
||||
|
||||
The IFC schema defines a comprehensive set of consistent data representations of building information for exchange between AEC software applications.
|
||||
It covers various aspects of buildings throughout their lifecycle, from conception to demolition.
|
||||
|
||||
|
||||
buildingSMART and Standards
|
||||
---------------------------
|
||||
|
||||
buildingSMART International (bSI) is the organization responsible for developing and maintaining the IFC standard.
|
||||
They also develop other related standards like BCF (BIM Collaboration Format) and bSDD (buildingSMART Data Dictionary).
|
||||
|
||||
IfcOpenShell
|
||||
------------
|
||||
|
||||
IfcOpenShell is the open-source software library used by BlenderBIM to read, write, and manipulate IFC files.
|
||||
It provides the core functionality for working with IFC data.
|
||||
|
||||
Interoperability and Other Standards
|
||||
------------------------------------
|
||||
|
||||
IFC is part of a broader ecosystem of open standards in the AEC industry. Other relevant standards include:
|
||||
|
||||
- COBie (Construction Operations Building Information Exchange)
|
||||
- CityGML (City Geography Markup Language)
|
||||
- gbXML (Green Building XML)
|
||||
|
||||
The use of open standards like IFC ensures interoperability between different software tools
|
||||
and preserves data integrity throughout the building lifecycle.
|
||||
|
||||
|
||||
Key Concepts
|
||||
============
|
||||
|
||||
This section provides an overview of key IFC concepts and how they're implemented in BlenderBIM.
|
||||
|
||||
|
||||
.. only:: builder_html and (not singlehtml)
|
||||
|
||||
.. container:: toc-cards
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`ifc_concepts/spatial_objects`
|
||||
Basic spatial objects.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`ifc_concepts/classification_and_types`
|
||||
IFC classification hierarchy and the concept of types and occurrences.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`ifc_concepts/geometry_and_representations`
|
||||
Understanding IFC geometry, representations, and parametric materials.
|
||||
|
||||
.. container:: card
|
||||
|
||||
:doc:`ifc_concepts/working_with_representations`
|
||||
Representations in BlenderBIM.
|
||||
|
||||
.. container:: global-index-toc
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Understanding IFC
|
||||
:maxdepth: 2
|
||||
|
||||
ifc_concepts/spatial_objects
|
||||
ifc_concepts/classification_and_types
|
||||
ifc_concepts/geometry_and_representations
|
||||
ifc_concepts/working_with_representations
|
||||
@@ -0,0 +1,52 @@
|
||||
Other add-ons
|
||||
=============
|
||||
|
||||
Blender has a large ecosystem of add-ons. The BlenderBIM Add-on is one of many
|
||||
add-ons which provide utility to the architecture, engineering, and construction
|
||||
industry.
|
||||
|
||||
Some of these add-ons come with Blender and merely need to be enabled in the
|
||||
``Edit > Preferences > Add-ons`` tab.
|
||||
|
||||
- **Sun Position** - will allow you to set the correct location of the sun and
|
||||
true north. Integrates with IFC4 georeferencing features in the BlenderBIM
|
||||
Add-on.
|
||||
- **AutoCAD DXF Format (.dxf)** - provides import and export support of the DXF
|
||||
format in Blender.
|
||||
- **tinyCAD Mesh tools** - provides basic intersection and circle reconstruction
|
||||
utilities similar to trim / extend / centroid tools in CAD tools.
|
||||
|
||||
Some of these add-ons are not shipped with Blender:
|
||||
|
||||
- `CAD Transform for Blender <https://gumroad.com/l/nqvcs>`__ - This will
|
||||
provide CAD snapping, move, rotate, and scale functions in Blender. This is
|
||||
highly recommended for precision modeling in Blender.
|
||||
- `Blender Archipack <https://blender-archipack.org/>`__ - Archipack lets you
|
||||
create parametric architectural objects, like walls, floors, ceilings, doors,
|
||||
roofs, and furniture with a single click from a preset templates. It
|
||||
integrates with the BlenderBIM Add-on, so you have the choice to combine both
|
||||
parametric and modeling by hand.
|
||||
- `Sverchok <https://github.com/nortikin/sverchok/>`__ - Sverchok is a visual
|
||||
programming add-on for Blender that allows you to generate parametric
|
||||
geometry, create scripts for non-programmers, model solids from FreeCAD, and
|
||||
much more. There is also
|
||||
`IfcSverchok <https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.8.0/src/ifcsverchok/README.md/>`__
|
||||
that adds IFC features to Sverchok.
|
||||
- `BlenderGIS <https://github.com/domlysz/BlenderGIS>`__ - BlenderGIS lets you
|
||||
import GIS data, grab elevation data from the web, and generate TINs from
|
||||
survey points and contours.
|
||||
- `Ladybug Tools for Blender
|
||||
<https://github.com/ladybug-tools/ladybug-blender/releases/download/ladybug-blender-240529/ladybug-blender-240529.zip>`__ - Ladybug Tools
|
||||
is an extension of Sverchok for environmental analysis and building physics
|
||||
simulation. It allows analysis of solar, daylight, energy, and CFD.
|
||||
- `Topologic <https://topologic.app/>`__ - Perform spatial and topological
|
||||
analysis of simplified building geometry and space connectivity.
|
||||
- `Speckle Blender <https://speckle.systems/tag/blender/>`__ - Use Speckle to
|
||||
get your designs in Blender from other CAD software.
|
||||
- `Point Cloud Visualizer <https://blendermarket.com/products/pcv>`__ - Display,
|
||||
edit, filter, render, convert, generate and export colored point cloud PLY
|
||||
files.
|
||||
- `MeasureIt_ARCH <https://github.com/kevancress/MeasureIt_ARCH>`__ - Simple
|
||||
dimensioning and annotation tools in Blender.
|
||||
- `Sorcar <https://aachman98.itch.io/sorcar>`__ - Another visual node
|
||||
programming alternative to Sverchok.
|
||||
@@ -0,0 +1,92 @@
|
||||
Creating an IFC model
|
||||
=====================
|
||||
|
||||
We're going to create a new native IFC model from scratch, starting from a
|
||||
single shape, up to a simple building.
|
||||
|
||||
A BIM model is not just a 3D format. This means that you cannot just load any 3D
|
||||
model, and press a "Save as IFC" button. In fact, 3D is optional and you
|
||||
can have a large IFC model storing work schedules, cost rates, asset registers
|
||||
and more, and absolutely no 3D geometry at all.
|
||||
|
||||
However, in these tutorials, we will focus on basic 3D geometry. At a minimum,
|
||||
you will need to categorise your 3D elements (such as "Wall", "Column",
|
||||
"Window", etc), and give them a location (such as "Level 01" of a building).
|
||||
|
||||
Creating a single object
|
||||
------------------------
|
||||
|
||||
In the **Properties** panel on the right, ensure the icon for the **Scene
|
||||
Properties** tab is active showing the **Project Overview**. Click on **Create
|
||||
Project** to create a blank IFC project.
|
||||
|
||||
.. image:: images/create-project.png
|
||||
|
||||
In the left **Outliner** panel, you will see a hierarchy of spaces that has
|
||||
been automatically created for you. This hierarchy is known is the **Spatial
|
||||
Tree**.
|
||||
|
||||
.. image:: images/default-spatial-tree.png
|
||||
|
||||
There are many ways to create objects. In practice, you should use an element
|
||||
type library, and we will see how to do this later. For now, we will only add a
|
||||
single element. In the **Add** menu, add a cube.
|
||||
|
||||
.. image:: images/add-cube.png
|
||||
|
||||
Any Blender object that you want to be part of IFC project must be converted
|
||||
into a IFC object by assigning a category. This category is known as the **IFC
|
||||
Class**.
|
||||
|
||||
.. seealso::
|
||||
|
||||
Use the `IFC Class search tool
|
||||
<https://blenderbim.org/search-ifc-class.html>`__ to help choose an **IFC
|
||||
Class**!
|
||||
|
||||
Select the cube (selected objects are highlighted in orange, careful not to
|
||||
select anything else!) and switch to the **Object Information** tab. Let's
|
||||
pretend our Cube is a column, so select **IfcElement** from the **Products**
|
||||
dropdown, **IfcColumn** from the **Class** drop-down, and press **Assign IFC
|
||||
Class**.
|
||||
|
||||
.. image:: images/assign-class.png
|
||||
|
||||
.. tip::
|
||||
|
||||
There are no restrictions on which **IFC Class** you can choose regardless of
|
||||
the shape of your object. You can have a monkey-shaped wall if you want!
|
||||
|
||||
All IFC objects must also belong inside the **Spatial Tree**. In the
|
||||
**Outliner** panel, you will see that your newly created **IfcColumn/Cube** has
|
||||
been automatically placed in **IfcBuildingStorey/My Storey**.
|
||||
|
||||
.. image:: images/outliner-cube.png
|
||||
|
||||
In the top left **File** menu, Save your new IFC model on your computer.
|
||||
|
||||
.. image:: images/save-project.png
|
||||
|
||||
Congratulations! You have now created your first OpenBIM model from Blender! You
|
||||
can open the IFC file in any other program, and you will see something similar
|
||||
to the image below. Three simple open source online viewers you can test with
|
||||
are `IfcPipeline <https://view.ifcopenshell.org>`__, `ThatOpenEditor
|
||||
<https://platform.thatopen.com/app>`__, and `3DViewer
|
||||
<https://3dviewer.net/>`__.
|
||||
|
||||
.. image:: images/ifc-pipeline.png
|
||||
|
||||
Placing occurrences of an element type
|
||||
--------------------------------------
|
||||
|
||||
TODO
|
||||
|
||||
Changing the locations of elements
|
||||
----------------------------------
|
||||
|
||||
TODO
|
||||
|
||||
Modeling a simple building
|
||||
--------------------------
|
||||
|
||||
TODO
|
||||
@@ -0,0 +1,445 @@
|
||||
Exploring an IFC model
|
||||
======================
|
||||
|
||||
We're going to load an existing IFC model and explore some common properties
|
||||
most users will be interested in.
|
||||
|
||||
If you don't have an IFC model available, here's a small one for your
|
||||
convenience provided by the Institute for Automation and Applied Informatics
|
||||
(IAI) / Karlsruhe Institute of Technology. It's in German, so you may need to
|
||||
use some creativity when reading the data :)
|
||||
|
||||
.. container:: blockbutton
|
||||
|
||||
`Download sample IFC <https://www.ifcwiki.org/images/e/e3/AC20-FZK-Haus.ifc>`__
|
||||
|
||||
.. seealso::
|
||||
|
||||
You can find more sample models online in the `OSArch Open Data Directory
|
||||
<https://wiki.osarch.org/index.php?title=AEC_Open_Data_directory>`__
|
||||
|
||||
Loading a model
|
||||
---------------
|
||||
|
||||
Blender's interface is divided into three panels. The left **Outliner** panel
|
||||
shows a tree of geometric objects. The centre main **Viewport** panel shows 3D
|
||||
geometry. The right **Properties** panel shows data and relationships.
|
||||
|
||||
.. image:: images/blenderbim-layout.png
|
||||
|
||||
The **Properties** panel has tabs to switch between different types of
|
||||
properties.
|
||||
|
||||
.. image:: images/properties-tabs.png
|
||||
|
||||
Click on ``File > Open IFC Project`` and browse to your ``.ifc`` file.
|
||||
|
||||
.. image:: images/properties-loadproject.png
|
||||
|
||||
After loading, you will see the model appear in the **Viewport** panel.
|
||||
|
||||
.. image:: images/example-project.png
|
||||
|
||||
Take a look at the **Project Info** subpanel. It shows the loaded filename, as
|
||||
well as the **IFC Schema**. There are two commonly seen **IFC Schema**
|
||||
versions: IFC2X3 and IFC4. Checking the **IFC Schema** is important because it
|
||||
has an impact on what BIM data may be stored. IFC4 is the newer version and it
|
||||
is recommended to use IFC4 models as it has significantly more BIM capabilities
|
||||
compared to IFC2X3.
|
||||
|
||||
.. tip::
|
||||
|
||||
Blender's interface is highly customisable. Panels, panel types, colours,
|
||||
sizes, and tabs may be edited to suit your workflow. If you want a `Hot Pink
|
||||
theme <https://github.com/kame404/Blender-Themes>`__ look no further.
|
||||
|
||||
Navigating a model in 3D
|
||||
------------------------
|
||||
|
||||
To navigate, can use the **Navigate Gizmo** on the top right corner of the
|
||||
**Viewport** panel. Click and drag on the coloured axes to **Orbit**, click and
|
||||
drag on the magnifying glass to **Zoom**, and click and drag on the hand icon to
|
||||
**Pan**. You can also click on the grid icon to switch between perspective and
|
||||
orthographic view.
|
||||
|
||||
To switch to a top view, front view, or side view, click the relevant axis on
|
||||
the **Navigate Gizmo**.
|
||||
|
||||
.. image:: images/navigate-gizmo.png
|
||||
|
||||
You can also use your mouse to navigate. Hover your mouse over the **Viewport**
|
||||
panel and click and drag the Middle Mouse Button (``MMB``) to **Orbit**. Scroll
|
||||
the mousewheel to **Zoom**, and use ``Shift-MMB`` to **Pan**.
|
||||
|
||||
If you have a numpad, you can use the numpad keys to quickly switch to top,
|
||||
front, or side view. Use ``7`` for top view, ``1`` for front view, and ``3`` for
|
||||
side view.
|
||||
|
||||
.. warning::
|
||||
|
||||
Blender's hotkeys are context sensitive. This means that a hotkey has a
|
||||
different meaning depending on the panel your mouse cursor is hovering over.
|
||||
If you press ``7`` to go to top view, make sure your mouse cursor is over the
|
||||
**Viewport** panel. Be very careful where your mouse is, or you might press a
|
||||
hotkey and it will have unintended consequences!
|
||||
|
||||
If you click on an object, such as a wall in the **Viewport** panel, you can
|
||||
zoom to the selected object by clicking on ``View > Frame Selected``. The hotkey
|
||||
is the ``.`` button on the numpad. After zooming into an element, when you
|
||||
**Orbit** the 3D view will rotate around the center of that element.
|
||||
|
||||
You can also zoom to all objects in the project by clicking on ``View > Frame
|
||||
All``.
|
||||
|
||||
.. image:: images/frame-selected.png
|
||||
|
||||
Another good way to navigate is by flying or walking around similar to a video
|
||||
game. Choose ``View > Navigation > Walk Navigation``, or use the ``Shift-```
|
||||
hotkey (the backtick key is usually to the left of the number 1 on the
|
||||
keyboard). With **Walk Navigation** enabled, use the ``WASD`` keys and the mouse
|
||||
to move around like a video game. You can use the ``Shift`` key to switch
|
||||
between moving fast and slow. If you scroll with the mousewheel, it will adjust
|
||||
the speed that you move at.
|
||||
|
||||
Sometimes, you want to look through objects. You can toggle **X-Ray Mode** by
|
||||
pressing the button on the top right of the **Viewport** panel. The hotkey is
|
||||
``Alt-Z``.
|
||||
|
||||
.. image:: images/x-ray-mode.png
|
||||
|
||||
.. tip::
|
||||
|
||||
Blender has lots of hotkeys to do things quickly. These can take time to
|
||||
learn but it is worth it as you will be much faster. These hotkeys can be
|
||||
customised in Blender's preferences.
|
||||
|
||||
|
||||
Overview of all objects
|
||||
-----------------------
|
||||
|
||||
The **Outliner** panel on the top right shows a hierarchy of all the currently
|
||||
loaded physical **Objects** in your IFC project. These **Objects** correlate to
|
||||
what you can see in the **Viewport** panel.
|
||||
|
||||
Every **Object** in the **Outliner** represents an IFC **Element**. These
|
||||
**Objects** have a name with the pattern ``Class/Name``. The class prefix
|
||||
represents the type of object, and the name is the name of the object. Examples
|
||||
of classes you will see are ``IfcBuilding``, or ``IfcWall``. This naming
|
||||
convention makes it easy to quickly spot types of objects.
|
||||
|
||||
.. image:: images/outliner.png
|
||||
|
||||
Objects are organised in a hierarchy. By default, this hierarchy represents a
|
||||
breakdown of spaces, from large spaces such as a site and a building, down to
|
||||
smaller spaces like building storeys and room spaces. The hierarchy will always
|
||||
begin with an **IfcProject** object. You can click on the triangle to toggle the
|
||||
hierarchy.
|
||||
|
||||
.. tip::
|
||||
|
||||
In large projects with deep hierarchies, you can ``Shift-LMB`` click the
|
||||
triangle to recursively toggle the hierarchy. You can also click and drag the
|
||||
``MMB`` to pan left and right.
|
||||
|
||||
When there are lots of objects, you can type a name in the filter box to quickly
|
||||
identify objects by name or type.
|
||||
|
||||
.. image:: images/outliner-filter.png
|
||||
|
||||
Clicking on an object in the **Outliner** panel also selects the corresponding
|
||||
object in the **Viewport** panel. A good strategy to find objects is to then use
|
||||
``View > Frame Selected`` to zoom to it in the **Viewport**.
|
||||
|
||||
The **Outliner** panel is also great for isolating portions of your project. You
|
||||
can include and exclude portions by clicking on the **Tick Icon** next to
|
||||
collections of objects in the hierarchy.
|
||||
|
||||
Let's isolate a single building storey. Start by disabling the **Tick Icon**
|
||||
next to the **IfcProject** collection. This will hide everything in the project.
|
||||
Then navigate through the hierarchy and enable the **Tick Icon** next to an
|
||||
**IfcBuildingStory**.
|
||||
|
||||
.. image:: images/outliner-isolate.png
|
||||
|
||||
Viewing element classes
|
||||
-----------------------
|
||||
|
||||
Usually the first thing you'll want to check is the **Class** of element that an
|
||||
object represents. The IFC **Class** is an international classification system
|
||||
provided by IFC. Example IFC **Classes** are Wall, Slab, and Door. Every IFC
|
||||
element must have a **Class**.
|
||||
|
||||
**Classes** aren't just for categorising elements. They also indicate what types of
|
||||
properties and relationships it is allowed to have. For example, a Wall
|
||||
**Class** can have a fire rating property, but a Grid **Class** cannot.
|
||||
|
||||
.. note::
|
||||
|
||||
There are hundreds of **Classes** to represent all aspects of our built
|
||||
environment, including non geometric classes like Task, Occupant, and CostItem.
|
||||
However, we'll focus only on simple physical **Classes** in this guide. Don't
|
||||
worry about memorising all the available **Classes**, you'll get a feel for them
|
||||
as you explore more.
|
||||
|
||||
To view an object's class, click on an object in the **Viewport** or **Outliner**
|
||||
panel, then switch to the **Object Information** tab in the **Properties** panel.
|
||||
You can see the **Class** name in the **Object Metadata** subpanel.
|
||||
|
||||
.. image:: images/element-class.png
|
||||
|
||||
In this case, the **Class** of our roof is an **IfcSlab**. You'll notice this is
|
||||
the same **Class** name used as a prefix for the object name in the **Outliner**
|
||||
panel. You can also see the name of the actively selected object in the top left
|
||||
of the **Viewport** panel.
|
||||
|
||||
.. warning::
|
||||
|
||||
Sometimes, an IFC model will use the wrong **Class**. For example, a chair might
|
||||
be assigned as the Wall **Class** instead the Furniture **Class**. There is a
|
||||
special class known as **IfcBuildingElementProxy**, used when the user is
|
||||
unable to find a more semantic **Class**. If you see many
|
||||
**IfcBuildingElementProxy** **Classes**, it is likely a symptom of a low
|
||||
quality IFC model. If this is the case, scold the project manager and ask
|
||||
them to do a better job.
|
||||
|
||||
After **IfcSlab** it also says **ROOF**. This is known as the
|
||||
**Predefined Type** of the element. You can think of it as a further level of
|
||||
classification. In this case, it distinguishes our object as a roof slab,
|
||||
compared to other types of slabs. The **Predefined Type** is optional so you may
|
||||
not see it all the time.
|
||||
|
||||
.. seealso::
|
||||
|
||||
You can use the `Search IFC Class
|
||||
<https://blenderbim.org/search-ifc-class.html>`__ tool to learn the correct
|
||||
classes and predefined types you should see.
|
||||
|
||||
Press the **Select Icon** to select all objects that are of the same
|
||||
**IfcSlab** **Class**. Then, you can isolate these elements by going to ``Object
|
||||
> Show/Hide > Hide Unselected`` (hotkey ``Shift-H``). To show all elements again, you can use
|
||||
``Object > Show/Hide > Show Hidden Objects`` (hotkey ``Alt-H``). If you want to
|
||||
hide elements instead, you can use ``Object > Show/Hidden > Hide Selected``
|
||||
(hotkey ``H``).
|
||||
|
||||
.. image:: images/element-class-select.png
|
||||
|
||||
.. note::
|
||||
|
||||
Remember that Blender's hotkeys are context sensitive. Make sure your mouse
|
||||
is hovering over the **Viewport** panel when you press a hotkey or no cake
|
||||
for you.
|
||||
|
||||
You can also see statistics about the number of selected objects. If you right
|
||||
click on the bottom right status bar and enable **Scene Statistics** you will
|
||||
see information like **Objects 4/4**, which means that 4 objects are selected
|
||||
out of 4 available objects. This is a great way of counting objects like toilets.
|
||||
|
||||
.. image:: images/scene-statistics.png
|
||||
|
||||
Viewing attributes and properties
|
||||
---------------------------------
|
||||
|
||||
You can view the **Attributes**, **Properties**, and **Quantities** of the
|
||||
selected object in the **Object Properties** tab.
|
||||
|
||||
Let's focus on **Attributes** first. Scroll down to the **Attributes**
|
||||
subpanel. **Attributes** are a limited set of fundamental data (usually less
|
||||
than 10) associated with all IFC elements. These are fixed by the IFC standard.
|
||||
|
||||
.. image:: images/attributes.png
|
||||
|
||||
Here are some common attributes and what they mean:
|
||||
|
||||
- **GlobalId**: a unique ID for the element useful for computer geeks
|
||||
- **Name**: a short name, code, number, or label to identify the object for a
|
||||
human. If you had to annotate the object on a drawing or a schedule, the
|
||||
**Name** is what you should see. For example, a pump **Name** might be ``P-10-A``.
|
||||
- **Description**: typically the longer form of the name, written to be
|
||||
descriptive and readable for humans. For example a pump **Description** might
|
||||
be ``Water Suction Pump``.
|
||||
- **Tag**: this is an ID that may link it back to another BIM application. For
|
||||
example if the IFC model was produced using Revit or ArchiCAD, it might hold
|
||||
the Revit or ArchiCAD element ID.
|
||||
- **Predefined Type**: A further level of classification to be read
|
||||
in conjunction with the IFC class.
|
||||
|
||||
.. warning::
|
||||
|
||||
Some IFC models have poor quality data. For example, if the **Name**
|
||||
of a Window doesn't match the window code (e.g. ``W01``) you see on a
|
||||
drawing, the project manager has clearly not put enough effort. Shame on
|
||||
them.
|
||||
|
||||
**Properties** are other data associated with the object. Every project will
|
||||
have different **Properties** depending on what information they want to store.
|
||||
Each **Property** has a name and a value, and are grouped into **Property
|
||||
Sets**. Each **Property Set** also has a name.
|
||||
|
||||
You can find **Properties** in the **Object Property Sets** subpanel.
|
||||
|
||||
.. image:: images/psets.png
|
||||
|
||||
Some very common **Properties** are standardised by international BIM standards.
|
||||
For example, the load bearing **Property** of a beam should always be called
|
||||
``LoadBearing``. If a **Property Set** is part of the international standard, it
|
||||
has a prefix of ``Pset_``, like ``Pset_BeamCommon``.
|
||||
|
||||
If you see a **Property Set** without the ``Pset_`` prefix, it is a custom
|
||||
property defined by the author of the IFC model.
|
||||
|
||||
.. tip::
|
||||
|
||||
It's important to distinguish between **Properties** that are
|
||||
part of the standard compared to custom ones. When **Properties** are
|
||||
standardised, it makes it easy to manage data. So if you need to isolate all
|
||||
``LoadBearing`` elements, you now know exactly where to look.
|
||||
|
||||
**Quantities** are very similar to properties. They also have a name and a
|
||||
value, and are grouped into **Quantity Sets**. Similarly, there are also common
|
||||
quantities defined as part of the international standard, denoted by the prefix
|
||||
``Qto_``. This prefix is short for "Quantity Take-Off".
|
||||
|
||||
You can find **Quantities** in the **Object Quantity Sets** subpanel.
|
||||
|
||||
.. image:: images/qtos.png
|
||||
|
||||
Finding the location of objects
|
||||
-------------------------------
|
||||
|
||||
Every object in the built environment has a location in the world. For example,
|
||||
a chair will be located in a space, and a wall is typically located in a
|
||||
building storey. You've already seen this hierarchy of spaces in the
|
||||
**Outliner** panel, where an IFC project is broken down into site, building,
|
||||
storeys, and spaces.
|
||||
|
||||
Sometimes, objects may have multiple relevant locations, such
|
||||
as a multi-storey column which can be related to multiple building storeys.
|
||||
Even in these cases, IFC enforces one location to be its primary
|
||||
location, known as its **Spatial Container**.
|
||||
|
||||
If you click on any object, you can see its location in the **Spatial
|
||||
Container** subpanel in the **Object Information** tab.
|
||||
|
||||
Press the **Select Icon** to select all objects that are in the same location.
|
||||
|
||||
.. image:: images/spatial-container.png
|
||||
|
||||
Checking construction types
|
||||
---------------------------
|
||||
|
||||
Almost everything in the built environment will have a **Construction Type**.
|
||||
For example, an architect will specify a door type for every door in a project.
|
||||
|
||||
You can see a list of **Construction Types** in the **Outliner** panel in the
|
||||
**Types** collection. For example, if the architect has a wall types schedule
|
||||
with the wall type names of ``WT01``, ``WT02``, and ``WT03``, you should see
|
||||
three **IfcWallType** objects with those same names in the **Outliner**.
|
||||
|
||||
You can click on these types to see more details about them in the
|
||||
**Properties** panel.
|
||||
|
||||
.. image:: images/outliner-types.png
|
||||
|
||||
When selecting an object, you can also see its construction type in **Object
|
||||
Information** under the **Type** subpanel. You can press the **Select Icon** to
|
||||
select all objects that are of the same **Construction Type**. You can use the
|
||||
hide and isolate hotkeys to quickly view them in the model.
|
||||
|
||||
.. image:: images/properties-types.png
|
||||
|
||||
A **Construction Type** defines properties that are common to all occurrences of
|
||||
that type. For example, if a wall type specifies a fire rating property, then
|
||||
all walls of that wall type will inherit that fire rating too.
|
||||
|
||||
A **Construction Type** may also specify geometry or geometric rules that are
|
||||
common to all occurrences of the type. For example, a pump type will define the
|
||||
geometry of the pump, so all occurrences of that pump will have the same
|
||||
geometry.
|
||||
|
||||
You can visually inspect types in isolation to the rest of the model. Types are
|
||||
hidden by default, so first enable the visibility of the **Types** collection in
|
||||
the **Outliner** by pressing the **Visibility Icon**. Then, select a type, and
|
||||
click on ``View > Local View > Toggle Local View`` (hotkey ``/``) in the
|
||||
**Viewport**. Toggle the view to see the entire model again.
|
||||
|
||||
.. image:: images/type-local-view.png
|
||||
|
||||
.. note::
|
||||
|
||||
Only **Construction Types** where the geometry is exactly the same for all
|
||||
occurrences will specify geometry. When the geometry varies based on the
|
||||
occurrence (such as a wall, which varies based on the wall length), the
|
||||
**Construction Type** will typically have no geometry.
|
||||
|
||||
Filtering by materials
|
||||
----------------------
|
||||
|
||||
Everything in the built environment is made from a physical raw **Material**
|
||||
resources. For example, a **Material** might be blockwork. Another
|
||||
**Material** might be in-situ concrete. **Materials** are grouped into
|
||||
categories like steel, concrete, brick, block, and so on.
|
||||
|
||||
We can see a list of **Materials** used in the project in the **Materials**
|
||||
subpanel in the **Geometry and Materials** tab.
|
||||
|
||||
Press the **Select Icon** to select all objects that are of the selected
|
||||
material.
|
||||
|
||||
.. image:: images/materials.png
|
||||
|
||||
Taking simple measurements
|
||||
--------------------------
|
||||
|
||||
The simplest form of measurement is the one that's already taken for you. The
|
||||
**Viewing attributes and properties** section describes how to view
|
||||
pre-calculated **Quantities**.
|
||||
|
||||
Sometimes, you may wish to take manual measurements yourself. You can view the
|
||||
overall X, Y, and Z dimensions of the currently selected object in the
|
||||
**Derived Coordinates** subpanel in the **Geometry and Materials** tab.
|
||||
|
||||
.. image:: images/dimensions.png
|
||||
|
||||
Another way to manually measure from two points is to use the **Measure** tool.
|
||||
First, press the **Snap Icon** to enable snapping. Then choose snap targets in
|
||||
the **Snap Menu** in the top middle section of the **Viewport** panel.
|
||||
|
||||
.. image:: images/snap-targets.png
|
||||
|
||||
.. tip::
|
||||
|
||||
It is recommended to choose multiple snap targets, like **Vertex**, **Edge**, and
|
||||
**Face**, and **Edge Center**. You can use the ``Shift`` key to select
|
||||
multiple snap targets. For example, the **Face** snap target means that your
|
||||
measurements will automatically snap to the nearest object's surface.
|
||||
|
||||
Now that you have configured snapping, press the **Measure Tool Icon** on the
|
||||
left of the **Viewport** panel. **Click** and **Drag** in the 3D viewport to
|
||||
take a measurement. A circle will appear guiding the first point of your
|
||||
measurement. While **Dragging**, press the ``X`` key to lock the measurement
|
||||
line along the X axis. Alternatively, press the ``Y`` or ``Z`` key to lock the
|
||||
measurement line along the Y or Z axis. Let go of the mouse to finish your
|
||||
measurement.
|
||||
|
||||
.. image:: images/measure-tool.png
|
||||
|
||||
To delete a measurement, just click on one point of the measurement, and press
|
||||
the ``Delete`` key. You can also click and drag the ends of your measurement
|
||||
lines to measure to another location.
|
||||
|
||||
What else is there?
|
||||
-------------------
|
||||
|
||||
Congratulations, and welcome to the digital built environment!
|
||||
|
||||
We've barely scratched the surface of the data and relationships available in an
|
||||
IFC model. We've yet to cover documents and drawings, clearance zones, tasks,
|
||||
cost items, structural loads and forces, analytical models, distribution system
|
||||
connectivity, energy analysis, rendering textures, and so much more. Our built
|
||||
environment and its relationships are vast and complex and it is exciting that
|
||||
you can join us on its digital journey!
|
||||
|
||||
Please do not hesitate to reach out with any questions.
|
||||
|
||||
- `OSArch live chat <https://osarch.org/chat>`__
|
||||
- `OSArch community forum <https://community.osarch.org>`__
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 117 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 331 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 305 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 287 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 377 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 351 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 317 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 155 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 215 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 91 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 332 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 309 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user