Mesh Managers

From DocR21

Jump to: navigation, search

Mesh Managers control how the mesh is streamed to applications. For most uses, the default mesh manager, INDEXED_MESH_MANAGER is a good choice. If more customized mesh formats are desired, the application may choose another MESH_MANAGER.

This involves either choosing one of the Mesh Managers provided by ACIS (refer to ACIS Mesh Managers), or writing a custom mesh manager (refer to Derived Mesh Managers), deriving from the MESH_MANAGER class. Making the right choice for an application ensures that:

  • only needed information is stored, and in a format suited to the application;
  • the right balance between performance and efficient memory use is struck; and
  • other support required by the application will be provided.

Contents

Derived Mesh Managers

The way in which facets should be stored always depends on the particular application. A data format designed to meet the needs of all end-user applications would make the data-storage requirements for faceting huge, if not unmanageable. Furthermore, applications rarely use everything output by the Faceter. If provided a huge data structure, applications would typically extract what they needed and discard the original data structure to save on storage. Saving storage space might come at the expense of computation, because downstream operations might need the original data structure and would be forced to regenerate (refacet) the model.

The solution used by ACIS is not to store any facet data directly. Instead, ACIS provides mesh managers with simple virtual functions that can output the facet data. Enabling application-specific mesh managers to be derived permits an application to redefine the functions, or class methods. In doing so, the application has the ability to store precisely the information it requires directly into its own structures. In addition, the application can have multiple mesh managers that generate facet data for various purposes. For example, one mesh manager may be used for display and another for generating stereolithography files. The correct mesh manager has to be set before faceting.

A mesh manager is simply a C++ class that is derived from the base class MESH_MANAGER. (For a complete list of MESH_MANAGER methods, refer to the documentation of the MESH_MANAGER class.) The mesh manager's virtual functions are divided into three different protocols. Each protocol represents a group of functions tailored to a commonly used data-storage format. The base MESH_MANAGER class defines numerous virtual member-function stubs that are grouped into these protocols. Derived classes can redefine these functions to switch on the desired protocol. When the Faceter has computed a set of facets, it outputs them according to the protocol specified:

  • Coordinate Protocol – Outputs the polygon vertices as explicit coordinates.
  • Indexed Protocol – First outputs the list of coordinates of all the vertices in a face mesh, then outputs the polygon vertices as indices referring to items of this list.
  • Global-Indexed Protocol - Is similar to the indexed protocol, but considers the entire body as a single mesh.

The MESH_MANAGER class has a virtual method announce_polygon_model_face to announce the model face from which the polygons are made. Being a virtual function, it works with all mesh managers. The method announces the face once before the polygons are announced. All mesh managers evaluate the coordinates on a node only once, regardless of the number of polygon edges that share that node.

The general flow of output is:

  • the counts,
  • the nodes,
  • the edges, and
  • the polygons for each mesh (the polygons are output node by node).

ACIS Mesh Managers

ACIS currently provides seven mesh managers in all, which cover all three of the protocols discussed above:

Coordinate Protocol

The POLYGON_POINT_MESH_MANAGER class is used primarily by the obsolete Faceted Hidden Line Component. The PPM_ON_FACE_MESH_MANAGER class, which is derived from POLYGON_POINT_MESH_MANAGER, has the single additional function of attaching the mesh to the owning face. It is the default ACIS mesh manager (that is, the one created by api_initialize_faceter), but it is almost always overridden.

These managers produce the simplest mesh format. They maintain one mesh per face, and announce the mesh polygon by polygon. The polygons are announced based on the xyz coordinates of their nodes, as created by the Faceter. The POLYGON_POINT_MESH created by these mesh managers places its data in a singly linked, NULL-terminated list. Coordinates are repeated for adjoining facets, which consumes additional memory, but avoids indirect references. The mesh maintains pointers to the first and last polygons as well as the number of polygons in the mesh. The mesh manager calculates the node information once and stores it for future use.

Indexed Protocol

These mesh managers likewise produce a separate mesh for each face.

The INDEXED_MESH_MANAGER is used primarily for rendering. It announces (declares) the nodes by their xyz positions. The nodes are first created by the Faceter, then are used to create polygons, and each face receives a mesh based on these polygons. The INDEXED_MESH created by this mesh manager maintains its data in contiguous arrays, thereby minimizing memory fragmentation. It is stored as an array of nodes and a set of polygons defined by numerical indices. In this packed representation, both nodes and polygon are referenced using an index into the array.

The LINKED_MESH_MANAGER was designed to improve the speed of faceting, at the expense of some memory fragmentation. It creates a LINKED_MESH, which is derived from a base class, SEQUENTIAL_MESH. The INDEXED_MESH is also derived from the same base class. This mechanism provides an easy transition between the two derived mesh managers. The interface has methods that allow one to traverse the mesh in a sequential fashion.

As its name suggests, the SIMPLE_INDEXED_MESH_MANAGER class, while offering an indexed protocol, does so at the cost of reduced functionality.

Global-Indexed Protocol

The primary distinction of this protocol is in maintaining a single mesh for an entire body, rather than one for each face. The class GLOBAL_MESH_MANAGER has no graphics or permanent storage services. The mesh is simply written to the standard output. The same is true of the STL_MESH_MANAGER class, which writes facet data to an STL (stereolithography)-formatted file.

Vertex Templates

A vertex template enables applications to request the mesh manager to attach data to the nodes of a mesh, if the mesh manager is designed to handle the request. The data, which is defined with the class VERTEX_TEMPLATE, includes:

  • coordinate data,
  • surface normal,
  • uv parameters,
  • partial derivatives and their magnitudes,
  • RGB color,
  • transparency,
  • texture, and
  • a pointer to user-defined data.

Indexed (non-global) and coordinate mesh managers create meshes on a face basis. Therefore, they can be designed to attach vertex template data to the nodes. Because global indexed mesh managers share node data between faces, they cannot store face related information such as attached vertex template data.

The VERTEX_TEMPLATE is typically used from a customized mesh manager. The template defines the information of importance from a mesh node. The template itself is stored in the save file, but not the resulting VERTEX_TEMPLATE instances for each node of the mesh. In other words, if a template is defined, then when the mesh is generated, a template for each node is filled out with information. When the mesh itself goes away, either because the owning entity was deleted or because the application was terminated, the individual templates go away. If the entity is saved to the save file, its refinements and master vertex template are saved as well. The mesh and the information in each individual vertex template are recreated from the entity, refinements, and master template when restored from the save file.

See Also

Personal tools
Live