|
Rendering is one of the primary down-stream operations that requires facets. Faceting is used by all active and static renderers. In both the active and static renderers, the entity facets are what are rendered.
|
|
|
Information on active rendering can be found in the
OpenGL Rendering Component ManualInformation on static rendering can be found in the
Basic Rendering Component Manual.
|
|
|
In the case of the active renderers, each time an entity is added to the rendering context, the faceter automatically facets the entity.
|
|
|
In the case of a static renderer, the faceter does not automatically facet the entity. It expects that each entity in their list already has the appropriate
INDEXED_MESH. Therefore, at the beginning of an application, a call must be made to
api_initialize_faceter. Later in the application, when the list of entities is available, a call is made to one of the facet APIs:
api_facet_entities,
api_facet_entity,
api_facet_unfaceted_entities, or
api_facet_unfaceted_entity.
|
|
|
The following lists the steps that an application could perform to facet and render a model using a static renderer.
|
|
|
1.
|
When an application uses faceting, it must first determine whether or not the facet data will be saved. If saving the data is required, the application derives its own mesh manager which handles saving the facet data.
|
|
|
2.
|
Because rendering is desired and this example does not save any data, create an instance of the
INDEX_MESH_MANAGER.
|
|
|
3.
|
Create or retrieve an
ACIS model. This could be performed sooner or later in the process, but the model, obviously, must be available before attempting to facet its unfaceted entities.
|
|
|
4.
|
Initialize the renderer that the application is using. Refer to the renderer's component manual. Each active renderer has slightly different requirements.
|
|
|
5.
|
The mesh manager may be specified when faceting is initialized using the function
api_initialize_faceter. It may also be set after initialization with the function
api_set_mesh_manager. This is how the faceter is informed of which mesh manager is being used. For this example, call the
api_set_mesh_manager function with a pointer to the mesh manager (e.g.,
INDEX_MESH_MANAGER).
|
|
|
6.
|
After faceting is initialized and a mesh manager specified, the application must specify some refinements. Environment default refinements are set using the function
api_set_default_refinement, while individual refinements are set using the function
api_set_entity_refinement.
|
|
|
Note
|
Refinements attached to a face take precedence over the refinements attached to their owning body.
|
|
|
7.
|
If
Graphic Interaction is used, call the
api_initialize_graphic_interaction function to initialize the graphic interaction library.
|
|
|
8.
|
If
Part Management is used, call the
api_initialize_part_manager function to initialize the part manager library.
|
|
|
9.
|
Call the
api_rh_initialise function to initialize the data structures required by the renderers. This must be called before any other rendering function.
|
|
|
10.
|
Optionally, call the
api_rh_initialize_supl_shaders function to initialize a larger set of shaders. The shaders supplied with the Core Shader Library have already been initialized prior to this step.
|
|
|
11.
|
Call the
api_prepare_to_render function. This tells the renderer the specific
view3d that is to be overwritten with the rendered image. The
view3d that is used for rendering can be the same
view3d used by another rendering context, such as the
display_list_context; the
view3d is overwritten with the rendering data.
|
|
|
12.
|
The application can send an entity or a list of entities to be faceted, using either function
api_facet_entity or
api_facet_entities, respectively. Each entity may be a body, a lump, a shell, or a face. Alternatively, one can choose to facet only those faces that have changed since they were last faceted, using the functions
api_facet_unfaceted_entity or
api_facet_unfaceted_entities. This is called
incremental faceting. In this example, call the
api_facet_unfaceted_entities function with a pointer to the entity list. The entity list comes from the
ACIS model that was retrieved or created.
|
|
|
13.
|
Call the
api_rh_render_entities function to see the results of faceting. For the static renderers, this bypasses the normal viewing pipeline by rendering the supplied list of entities directly in a
view3d. The
api_rh_render_entities uses the rendering mode established by
api_rh_set_mode.
|
|
|
14.
|
At the end of an application or rendering section, the faceter should be turned off with a call to
api_terminate_faceter.
|
|
|
Figure 1-1 shows the data flow during a faceting session:
|
|
|
A
REFINEMENT is created and attached to an
ACIS entity using
ATTRIB_EYE_REF_VT.
|
|
|
The entity and the refinement are passed to the faceter.
|
|
|
The faceter creates an instance of the
MESH_MANAGER.
|
|
|
The mesh manager creates a mesh for each face of the entity.
|
|
|
If the mesh manager is an application-defined class, the application can store mesh information into one of its data structures.
|
|
|
The face entities and their meshes are coupled using
ATTRIB_EYE_ATTACHED_MESH.
|
|
|
The mesh manager instance goes away after faceting the face entities.
|
|
|
The generated mesh is available to down-stream operations, such as rendering. Rendering has a list of entities. The entities are aware of their attributes, one of which tells about the facet mesh.
|
|
|
If the associated entities are deleted or the application terminates, the mesh goes away.
|
|
|
The entities and their refinements can be saved and stored in an
ACIS save file.
|
|
|
|
|
Figure 1-1. Data flow among the application, faceter, and ACIS modeler
|