Home > User Guide > Understanding Assembly Modeling

Assembly Modeling Limitations

---

Limitations

• Atomic Save
  The "Atomic" ASAT format should only be used as embedded segments within customer files. This requirement is due to the customer having the specific knowledge needed to re-associate object in one model file with the handles that refer to them in a different file. The default implementation of the derived classes which implement atomic save and restore that is provided with ACIS Assembly Modeling should never be used in an end-user application; customers must provide their own versions of these classes if they wish to use atomic save and restore in their applications.
  
• Model Reference Transforms
  Only translations and rigid-body rotations (that is, rotations which do not incorporate a reflection) may be applied to model references. This limitation must be respected when manipulating model references.
  
• Restore Progress Meter
  The ASAT restore function, asmi_restore_model_list, sequentially launches multiple instances of the restore progress meter (if it has been activated by the client application), rather than a single instance tracking the progress of the restoration of the entire file. This is because, internally, ASAT restore launches a SAT restore for each entity segment in the data file (for example, one per model for a monolithic file without history); the progress of each entity segment is tracked independently.
  
• No Flattening
  Routines to "flatten" an assembly, that is, convert a multi-level assembly tree into either a single level tree or a part model (containing copies of bodies in place of model references) are not provided in ACIS R17.
  
• PHL V5 Support
  A routine api_asm_model_phlv5_compute is provided to perform PHL V5 calculations on asm_model objects. The output of this routine, however, is a set of part-modeling objects, that is, PHLV5_EDGE and PHLV5_SEGMENT. These output objects should only be used for drawing at the time of calculation; they should not be persisted in any way. In particular, customers should not:
  • Attempt to save these PHL V5 entities to SAT or ASAT files.
  • Call api_save_entity_list on an entity list which contains these PHLV5 entities.
  • Add these PHL V5 entities to an ACIS PART.
  • Store these PHL V5 entities in attributes.
  • Return these PHL V5 entities in from customer overrides of asm_model_entity_mgr::get_top_level_entities_vf.
    
  These limitations are necessary because these entities contain entity pointers to entities which may reside in other models. They only apply to PHLV5 entities which are generated by api_asm_model_phlv5_compute; PHLV5 entities generated by api_phlv5_compute do not have these limitations. In keeping with these limitations, api_asm_model_phlv5_compute (unlike api_phlv5_compute) will not attach PHLV5_EDGEs as attributes.
  
• No Properties in Non-assembly Models
  Part models (that is, those not containing assembly entities) cannot own component properties.
  
• (pick:*) Behavior
  The Scheme part modeling pick commands, for example, (pick:entity) and (pick:face), ignore component-entities; they only operate on entities that belong directly to the model in which the pick is being performed. This behavior is necessary because these commands return entity pointers, which are not unique identifiers for component-entity pick result. Equivalent assembly modeling pick commands, for example, (pick-asm:entity) and (pick:asm-face), have been provided which return component-entity handles; these routines (and their C++ equivalents) should be used for assembly modeling picks.
  
• (entity:*) Scheme Extensions
  In general, the entities ASM_ASSEMBLY and ASM_MODEL_REF should only be manipulated through the asmi interface functions. Calling API functions or scheme commands directly on these objects may result in undefined behavior.
  
• Copying Entities between Models
  High-level routines to copy an ENTITY from one model (with specific units, tolerances, and history stream) to another are not provided in ACIS R17. ACIS provides a "deep copy" API function which allows copying of entities between history streams, but the details of rescaling, tolerizing, sliver removal, etc. are left up to customer code. Note that this limitation also applies to a routine to flatten an assembly into a part model; such a routine is not provided in ACIS R17.
  
• No Component Entity Properties
  Component Entity Properties are not exposed to customers in ACIS R17. This is due to subtleties in their interactions with the history and roll mechanism.
  
• Sharing History Among ACIS PART Objects
  The ACIS Part Management component supports two modes of history sharing among parts:
  • Distributed: Each PART object owns an independent HISTORY_STREAM.
  • Non-Distributed: All PART objects share a single default stream.
    
  Because of this limitation, ASAT files which have been saved with history with a more complicated sharing structure between the models in the file (for example, two models per history stream) cannot be loaded using an entity manager factory which creates ACIS PART objects (for example, acis_pm_entity_mgr_factory or acis_scm_entity_mgr_factory). When such files are encountered, they can be loaded into memory using a default_entity_mgr_factory and then the contents of the offending models can be deep-copied into new PART objects.
  
  Note:  This assumes that the application is working in distributed history mode.
  

Known Issues

General ACIS Assembly Known Issues

• The example code demonstrating the workflow for a non-ACIS Assembly Modeling customer to import an ASAT file does not properly transfer properties to any part models created by splitting a model into an assembly model and a part model.
  
• HA_bridge Interaction with Roll
  The callbacks which re-render assembly models upon roll are incorrectly implemented in the HA_bridge. Customers must explicitly perform a (render:rebuild) after rolling a history stream associated with an assembly model in order to obtain correct rendering.
  
• Transparency in HA_bridge
  The code implementing transparency in the HA_bridge (both for Assembly and Part modeling) incorrectly interprets the numerical value of the transparency. For a numerical value t of 1.0 is treated as if no transparency were set, that is, as opaque; this agrees with the documentation for transparency which states that t = 0 is transparent and t = 1.0 is opaque. Numerical values of 0 <= t < 1.0 are "reversed" relative to the documentation: t = 0 is interpreted as opaque and t = .99 is interpreted as almost transparent.

ACIS Assembly Interface Known Issues

• asm_restore_file::needs_restore_vf()
  The virtual method asm_restore_file::needs_restore_vf() is ignored by assembly modeling code. Customers should not override this virtual method when deriving their asm_restore_file sub-classes.
  
• Multiple Models in asmi_raytest_ents
  The routine asmi_raytest_ents accepts an asm_model_list as an input argument for testing, rather than a single asm_model. It only makes sense to call this routine with a single model, however, because the input test ray is defined in the coordinate system of the model being tested, which is independent of the coordinate systems of other models. You should only call this routine with a single asm_model in the input model list, as this signature of the routine is likely to be deprecated in a future release in favor of a signature which operates on a single asm_model.
  
• model_id for Internal Use
  The model_id data member of asm_model_info is for internal use only and should not be used by customer code.
  
• asmi_component_has_hiding_modifications
  The routine asmi_component_has_hiding_modifications and its corresponding Scheme extension, (component:has-hiding-modifications) are unable to detect any such modifications. This is planned to be corrected in a future Service Pack.

---

Related topics:

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

[Top]

---

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