Home > User Guide > Understanding Assembly Modeling

Basic Concepts in Assembly Modeling

This section discusses basic concepts in ACIS Assembly Modeling.

Topics include:

Model

(asm_model Class)

A "model" in ACIS Assembly Modeling is an abstraction which encapsulates a physical object or collection of physical objects. It can be thought of as corresponding to a document in your application. An asm_model object can contain zero or one ASM_ASSEMBLY entities, plus an arbitrary number of part modeling ("B-rep") entities. If an asm_model object contains an ASM_ASSEMBLY entity, then the object is referred to as an assembly model, otherwise it is referred to as a part model. The asm_model class is one of the central classes of the ACIS Assembly Modeling design. Model objects form the nodes in an assembly’s model reference tree.

Model Reference

(ASM_MODEL_REF Class)

Model references provide the mechanism for instantiating sub-models (either parts or sub-assemblies) within an assembly model. An ASM_MODEL_REF object associates a transform with a pointer to an asm_model object. Model references are aggregated within an assembly model by the ASM_ASSEMBLY object belonging to the assembly model. Model references define the links between nodes in an assembly’s model reference tree.

Model Reference Tree

An assembly is constructed by adding, to the assembly’s root model, references to part or sub-assembly models. This construction can be represented by a (folded) "model reference tree", with each node of the tree corresponding to a model and each connection within the tree corresponding to a model reference. The term "folded tree" indicates that a node in the tree can have more than one parent, which is the case because more than one model reference can refer to a particular model (the folded tree forms a Directed Acyclic Graph). For example, the front and rear references to the axle assembly model in a cart model (obviously) both refer to the same model, the axle assembly model. When constructing or manipulating an assembly’s structure, thinking in terms of (and using) the model reference tree view of the assembly is best, because these operations are performed by manipulating the assembly’s model references.

Component

(component_handle Class)

A component is a constituent of an assembly, similar to something that might be delivered (in the physical world) in a packing crate. A component corresponds to the entire assembly (for example, a cart), a particular sub-assembly (for example, the front axle assembly of a cart), or a leaf "part" (for example, the front-left wheel of the cart, or the left wheel of the axle assembly model).

A component is specified by its location within the assembly, which can be thought of as a path within the assembly’s model reference tree. For example, the front-left wheel within the cart assembly is the left reference to the wheel model within the front reference to the axle assembly model. The components of an assembly can be organized into an (unfolded) "component tree", with:

Note:  The term "unfolded" indicates that any non-root node in the tree has exactly one parent node. (The root node has zero parents, of course.)

The component tree structure can also be obtained (conceptually) from the model reference tree by unfolding it, where the unfolding process consists of duplicating branches corresponding to shared nodes (resulting in a set of unshared branches), and then modifying the resulting tree by any properties, such as suppression, which have been applied to the components of the assembly.

Note:  The component tree of the assembly (as reported by the asmi_component_* queries) contains more information than the raw model reference tree, because it also includes modifications to the components due to properties. For example, an axle assembly model with its left wheel suppressed only reports one wheel (the right one) component when queried for its sub-components, but reports two references to the wheel model. For this reason, you should generally use the asmi_component_* queries in order to find the actual constituents of the assembly, for instance, when rendering the assembly or computing physical properties of it.

Component Entity

A component entity corresponds to a particular entity within a component. For example, the "whitewall" face of the front-left wheel model in a car corresponds to a component entity containing an entity handle for the whitewall face of the wheel model and a component handle for the front-left wheel component. The concept of component entity is necessary in order to uniquely specify the result of a pick in assembly modeling; the whitewall face pointer alone corresponds to four different possible "faces" (actually component faces) within the car model (one for each wheel).

Property

Properties are used to modify components, for example by applying a color. As in ACIS Part Modeling, properties are represented by ACIS attribute objects, with the difference that the attributes are attached to a proxy entity for the object being modified (because neither component nor component entity are entities). ACIS Assembly Modeling can be categorized as follows:

Physical
Physical properties are properties that change the physical observables of the assembly. For example, applying the suppression property to a component removes that component from the mass properties calculation of the assembly, thereby changing the center of mass of the assembly. Because ACIS must be “aware” of physical properties in order to correctly calculate properties, such as mass properties, of the assembly, attempts to add your own physical property attributes require a large amount of re-coding to replace the ACIS physical property queries with a version that respects your attribute.

Rendering
Rendering properties do not change the physical observables of the assembly, but do change the way the assembly appears when rendered, for example, its color or transparency. You can apply application-specific rendering attributes that you have developed for part modeling (or new ones developed especially for assembly modeling) as properties in ACIS Assembly Modeling.

Other
The "other" properties include those that affect neither physical observables nor rendering, such as names or customer meta-data. As with rendering properties, you can use your own application-specific attributes here.

Assembly modeling properties are designed to work with the component view of the assembly; they are assigned to a particular component and modify that component and all of its sub-components. For example, a red color applied to the front axle assembly also causes the front-left wheel component to be red (assuming no other properties affect the front-left wheel). An exception to this is the asmi_component_find_name() query; it ignores names applied to parent components. Naming the front axle assembly has no effect on the front-left wheel.

Special interface routines are provided for determining the properties (for example, color) of a particular component (for example, front-left wheel) in the assembly that take into account conflicts between the various properties that might have been applied to that component and its parents. For example, coloring the front-left wheel blue and the front axle assembly red results in a report of "blue" for the color of the front-left wheel, because the more specific color property (that is, front-left wheel) is dominant. For more details, refer to the section Assembly Properties.

Assembly-level Entities

An ACIS Assembly Modeling model can contain both an assembly entity and part modeling entities (that is, bodies) simultaneously. When part modeling entities are present in an assembly model, these entities are called "assembly-level entities". Hence, application code must never assume that an asm_model object or a component has no associated part modeling entities; application code must always explicitly query for part modeling entities, whether or not the object in question (model or component) represents a part or a sub-assembly.

Entity Manager

ACIS Assembly Modeling is designed to work with the application codes system for managing the contents of documents. This is done by having the application code include a subclass of asm_model_entity_mgr which wraps an application document object. This subclass object is called an "entity manager".

Related topics:

Assembly Modeling Overview
Assembly Modeling vs Part Modeling
Assembly Modeling Tutorial
Properties in Assembly Modeling
Assembly Modeling Save and Restore
Standard Workflows in Assembly Modeling
Assembly Modeling Limitations

[Top]

© 1989-2007 Spatial Corp., a Dassault Systèmes company. All rights reserved.