STEP#

A STEP file, which stands for “Standard for the Exchange of Product model data,” is a standardized file format used for exchanging 3D CAD (Computer-Aided Design) models and related data between different software applications and systems. It is a widely used format in the field of engineering, manufacturing, and product design.

A STEP file is designed to facilitate the seamless exchange of complex 3D product information across various software platforms. It provides a standardized way to represent geometric and non-geometric data associated with a product’s design, such as its shape, dimensions, assembly structure, materials, and other attributes.

To help users coming from another CAD software, the Volmdlr library provides step functionality that enables you to import STEP files and perform powerful analysis within volmdlr features.

Import a STEP file#

Here’s a example of how you can do it:

from volmdlr import model

volume_model = model.VolumeModel.from_step(step_file='/path/to/your/step/file.step')
volume_model.display_3d()

If we break it down we have:

  1. Importing Required Modules:

from volmdlr import model

The script imports the model module from the volmdlr library. This module provides functionality to work with STEP (Standard for the Exchange of Product model data) files, which are used for exchanging 3D CAD models and associated information.

  1. Loading a STEP File:

volume_model = model.VolumeModel.from_step(step_file='/path/to/your/step/file.step')

This line loads a STEP file using the model.VolumeModel.from_step method. You need to replace '/path/to/your/step/file.step' with the actual file path to the STEP file you want to load. It will return to you a volmdlr VolumeModel instance, containing the 3D CAD model and its data.

  1. Generating Babylon.js Visualization:

volume_model.display_3d()

This line generates a 3D visualization of the volume model using the Babylon.js format. Babylon.js is a JavaScript framework for rendering 3D graphics in web browsers. This step prepares the data and structure needed to render the 3D object, considering the visual properties and modifications applied earlier.

In summary, this script loads a 3D CAD model from a STEP file, converts it into a volume model, modifies the visual appearance of the model’s first primitive (color and transparency), and then generates a 3D visualization using the Babylon.js format. The resulting visualization displays the modified CAD model with the specified color and transparency settings.

Export a STEP file#

The export of a STEP is strait forward, Here’s a example of how you can do it:

from volmdlr import model

# define volume_model to be exported

volume_model.to_step(filepath="your/new/file/path/with/name.step")

The DocModel#

VolumeModel.from_step gives you the geometry. DocModel.from_step gives you the whole document: the assembly tree exactly as the CAD file describes it — prototypes, their instances, and the non-geometric data the file carries alongside the B-Rep (per-part metadata, materials, drafting sheets, visibility).

from volmdlr.assembly import DocModel

doc_model = DocModel.from_step('/path/to/your/step/file.step')
doc_model.view()

from_step takes an optional reading_unit ("M", the default, or "MM") declaring the length unit of one file unit, and DocModel.from_step_stream reads the same content from an already-open binary stream. view() opens the document in the GLB viewer and returns its URL; it needs the volmdlr[viewer] extra.

Walking the assembly tree#

A DocModel distinguishes what a part is from where it appears. A Prototype is the definition — geometry, metadata, material — and an Instance is one placement of that definition, carrying its own location and its own occurrence-level metadata. A part reused fifty times is one prototype and fifty instances, so the geometry is stored once.

root_prototype is the entry point, and prototypes is the flat {component_id: prototype} view of the whole tree, populated recursively when the document is read:

root = doc_model.root_prototype

for instance in root.child_instances:
    print(instance.instance_name, instance.prototype.name)

# every prototype in the document, at any depth
for component_id, prototype in doc_model.prototypes.items():
    print(component_id, prototype.name, len(prototype.meshes()))

has_brep tells you whether the document carries B-Rep geometry (as opposed to meshes only), and get_shape_from_prototype assembles a Shape from a prototype definition when it does.

Reading metadata and materials#

CAD readers fill metadata with one {"category", "type", "value"} entry per attribute — a PLM-managed CATPart carries several hundred. metadata_values flattens that into {key: value} so reading one attribute does not mean knowing the wrapper:

part = doc_model.prototypes[3]

part.metadata_values['Description']     # instead of part.metadata['Description']['value']

material returns the applied physical material — the entries the readers emit under the "Material" category (CATIA CATMaterial, SolidWorks material, NX material) with their material_ prefix stripped — or None when the file assigns none. Properties whose source carries a unit add a <key>_units entry next to the value:

part.material
# {'name': 'Steel', 'density': 7860.0, 'density_units': 'kg_m3',
#  'young_modulus': 200000000000.0, 'poisson_ratio': 0.266, ...}

doc_model.materials      # {component_id: material} for every prototype that has one

These accessors live on a mixin, so every Prototype, Instance, PartNode and AssemblyNode has them. On an Instance, instance-level entries win over the prototype’s, which is what you want for occurrence-specific fields.

Drawings#

DocModel has no 2D field of its own: the readers park drafting sheets on a prototype’s representation_node, the one slot the 3D traversals leave alone. A file holding both a model and its drawing (NX .prt, .CATDrawing, .dwg, …) therefore keeps both halves, and drawings collects them from the whole tree:

for drawing in doc_model.drawings:
    print([sheet.name for sheet in drawing.sheets])

The objects returned are dessia_drawing Drawing instances. volmdlr does not depend on dessia_drawing — they are recognised by duck-typing — so reading them needs that package installed.

Exporting for the viewer#

export_to_json_glb writes the document as a model.json manifest plus content-addressed GLB files, the format the 3D viewer consumes:

json_path = doc_model.export_to_json_glb('/path/to/output/directory')

The JSON is named after the hash of its own content, so several exports coexist in one directory and identical exports deduplicate — use the returned path rather than assuming a filename. Prototypes marked is_blanked are emitted with a hidden flag, and a hidden assembly node hides its whole subtree.