Difference between revisions of "MicroMVDs for exchange requirements/Geometric detail MicroMVD"
From Wiki.OSArch
(Created page with "The following MicroMVD vocabulary can be used to ensure classification system standards are correctly applied. <pre> Feature: Ge...") |
m |
||
Line 1: | Line 1: | ||
− | The following [[Using MicroMVDs for exchange requirements|MicroMVD]] vocabulary can be used to ensure | + | The following [[Using MicroMVDs for exchange requirements|MicroMVD]] vocabulary can be used to ensure that geometry is efficiently and appropriately stored in the IFC. Geometry has the single largest impact on file imports, exports, and coordination time. |
<pre> | <pre> |
Revision as of 22:03, 8 September 2020
The following MicroMVD vocabulary can be used to ensure that geometry is efficiently and appropriately stored in the IFC. Geometry has the single largest impact on file imports, exports, and coordination time.
Feature: Geometric detail To allow for the efficient transfer of geometry For any stakeholder using 3D geometry Geometry shall use the appropriate modeling techniques Scenario: Receiving a file * The IFC file "{file}" must be provided * IFC data must use the {schema} schema Scenario: Geometry must be efficiently modeled * All elements must be under {number} polygons
You can fill out the variables using the guide below.
Variable | Example | Description |
---|---|---|
{file}
|
project.ifc | The filename or path to any IFC file. |
{schema}
|
IFC4 | The schema version. At the moment, these are likely to be either IFC4 or IFC2X3. |
{number}
|
500 | Given that the vast majority of objects in AEC are box-like or cylindrical, most objects should not be above 500 polygons. For context, a single box is 6 polygons, and a cylinder, depending on its size, may be faceted into 18 polygons. However, many proprietary AEC applications have poor mesh support and may inefficiently translate geometry into a large number of polygons without the users intention. |