Instancing And Patterning

Contents

• 54.1 Introduction
• 54.2 Instancing
  • 54.2.1 Summary of options
  • 54.2.2 Improving the performance of instancing operations
  • 54.2.3 Specifying the body type of target and tool
  • 54.2.4 Tracking information
    • 54.2.4.1 PK_FACE_instance_bodies
    • 54.2.4.2 PK_FACE_instance_tools
• 54.3 Patterning
  • 54.3.1 Ensuring new instances are contained within a face
  • 54.3.2 Ensuring new instances do not intersect other faces
  • 54.3.3 Returning errors when collisions occur
  • 54.3.4 Improving performance when new instances lie in the same faces as the original feature
  • 54.3.5 General patterning
    • 54.3.5.1 Instances all lie in the faces of the original feature
    • 54.3.5.2 Instances lie in different faces and boundary loops are coincident with their destination faces
    • 54.3.5.3 Instances lie in different faces and boundary loops are not coincident with their destination faces
    • 54.3.5.4 Summary
  • 54.3.6 Recreating blends around patterned instances

[back to top]

54.1 Introduction

This chapter explains how you combine a pattern of entities using instancing or patterning (or both) to produce the models you require.

Instancing and patterning are special cases of boolean operations; it is assumed that you are familiar with the behaviour and concepts of booleans as explained in Chapter 52, “Manifold Booleans”.

[back to top]

54.2 Instancing

Instancing refers to the process of performing a number of boolean operations involving a number of (often) identical tool bodies, e.g. when drilling several holes into a plate. Because of the repetitive nature of each boolean -- only a single boolean function is used, and many of the

tools are identical -- using a dedicated instancing operation often provides better performance than using a series of boolean operations.

Parasolid provides the following dedicated functions for performing instancing operations:

When the configuration of target and instances allows, these functions are able to perform the boolean operation more quickly by:

• First performing a single boolean for the first instance; and then
• Avoiding the work of performing a boolean for subsequent instances by copying and transforming the new faces, edges, etc. of the first instance.

Both functions can take a range of options, many of which are available in both functions. The rest of this section describes the options that are available.

Figure 54-1 Creating instances on solid and sheet bodies using single and multiple tools

54.2.1 Summary of options

The following table provides a summary of the options available in both instancing functions provided by Parasolid. The Availability column indicates whether the option is available in only PK_FACE_instance_ tools, PK_FACE_instance_ bodies, or both functions. Many of the instancing options available are identical to existing boolean options. Where this is the case, the table below references the appropriate boolean documentation in Chapter 52, “Manifold Booleans”, for further information.

function

configuration

select_region

matched_region

extend_face_list

stop_self_intersection

tracking

merge_imprinted

selective_merge

allow_disjoint

check_fa

repair_fa_fa

default_tol

max_tol

merge_attributes

keep_target_edges

imprint_complete_targ

imprint_complete_tool

fence

target_material_side

tool_material_side

resulting_body_type

limit_target_faces

flag_no_effect

tracking_type

track_edges

update

54.2.2 Improving the performance of instancing operations

The performance of the instancing operation can be improved by using the instancing options in the configuration option sub-structure. If you know that the tools and target received by either PK_FACE_instance_bodies or PK_FACE_instance_tools conform to a certain configuration, then you can set the fields in this structure to match that configuration. Doing this turns off relevant checks within the instancing operation, resulting in a corresponding performance improvement. For example, if you know that none of your tool bodies intersect each other, you can set the appropriate field, and the instancing operation will not check whether the supplied tools intersect before creating instances.

The options available are as follows:

no_tool_intersect

Figure 54-2 Tool bodies that do not intersect each other but intersect edges on the target

no_loop_intersect

Figure 54-3 Tool bodies that have intersected each other but not the edges on the target

identical_intersect

Figure 54-4 Identically positioned intersection loops on the instance tool body (cylinder) when it is united with an inclined planar face

one_in_all_in

54.2.3 Specifying the body type of target and tool

As with boolean operations, you can use the target_material_side and tool_material_side options in PK_FACE_instance_bodies_o_t to control how the tools and target specified are interpreted with regard to their body type. This is particularly useful, for instance, in the case of sheet bodies, since it allows you to treat a sheet body as if it was a solid, with material on a specific side of the sheet.

For instance, given suitable configurations of target and tool, you can use the material-side options to perform boolean punch and fence operations when creating instances. Figure 54-5 shows an example in which several instances are created on a sheet body using a punch operation and a solid tool body.

Figure 54-5 Punching blind holes in a sheet using target_material_side

See Section 51.4.14, “Specifying the body type of tool and target”, for more information on the behaviour of the target_material_side and tool_material_side options, and the effects that can be achieved using them.

54.2.4 Tracking information

Tracking behaviour is different for PK_FACE_instance_bodies and PK_FACE_instance_tools. In PK_FACE_instance_bodies, you can control the amount of tracking information that is returned. By contrast, PK_FACE_instance_tools just lets you turn tracking on or off.

54.2.4.1 PK_FACE_instance_bodies

In PK_FACE_instance_bodies, tracking is controlled using the following options:

tracking_type

track_edges

54.2.4.2 PK_FACE_instance_tools

In PK_FACE_instance_tools, tracking is controlled using the tracking option. If this field is PK_LOGICAL_true, PK_FACE_instance_tools returns tracking information. This tracking information includes:

• data to identify which of the instanced tools appear in the final body (subject to the flags in the configuration structure it is legal if an instance misses the target body);
• the number of faces in the tool body which are instanced at least once in the final body;
• an array of data structures for each face in the tool body which is instanced at least once in the resultant body, this information includes:
• the original face in the tool body;
• total number of times instanced copies of the original face appear in the resultant body; and
• the instanced faces of the original face, each accompanied by an index to indicate in which instance it appears.

You can also control the level of information that is returned for imprint completion using the tracking_type option. Note that this does not provide the same behaviour as the tracking_type option in PK_FACE_instance_bodies: see the documentation for PK_boolean_track_type_t for details.

[back to top]

54.3 Patterning

Patterning is very similar to the instancing operation, although it is not actually a boolean operation as it only operates on a single body.

The patterning function, PK_FACE_pattern, takes a set of faces that define a feature and an array of transforms. Each transform is to be applied to a copy of the faces that comprise the feature to create a new instance of the feature. In general, PK_FACE_pattern assumes that the faces are transformed far enough apart that they do not clash. However, diagnostics are optionally available to help applications identify unexpected clashes between instances. These options are discussed further on in this section.

Figure 54-6 shows a simple patterning example. The feature given to PK_FACE_pattern consists of the faces in both the pocket and the boss. There is only one transform applied and the result is shown on the right. Notice that this particular example could not be executed by a single boolean instancing operation, as that would imply an operation which would unite and subtract simultaneously.

Figure 54-6 Patterning example of one transform of both a pocket and a boss

There are restrictions on the kinds of feature that may be patterned; these restrictions are similar to those imposed for instancing. The patterning function is only able to copy the set of faces it is given and may only bring about a restricted set of topological changes. The patterning operation may split destination faces and edges on the target (underlying) body to enable successful completion. For a more detailed explanation of the restriction on changes of topology, please refer to the PK_FACE_pattern API documentation.

Figure 54-7 Patterning example that involves constant topology and geometry over the patterning operation

Apart from these restrictions, the form of the feature is relatively free: it may be disconnected, it may be closed or open (or a mixture of closed and open components), and it may be from a solid, sheet or general body. It may lie in one or more faces of the target body.

PK_FACE_pattern contains the following options in PK_FACE_pattern_o_t:

check_loops

check_fa_fa

same_face

coi_face

reblend

face_maps

collision

The returned data from the patterning function contains:

• Status codes indicating the nature of any failure.
• The new faces corresponding to the original faces.
• In the event of a problem, a status code to indicate the nature of the problem and, sometimes, some topological information to help locate the failure.

54.3.1 Ensuring new instances are contained within a face

By default, check_loops is set to PK_pattern_check_loops_no_c; this means that Parasolid creates new instances of a feature even if they do not fit into any of the faces in the target body. Depending on the configuration of the model, this could lead to undesirable results or invalidities.

If check_loops is PK_pattern_check_loops_yes_c, PK_FACE_pattern performs a two-stage check. This check ensures that each boundary loop (i.e., those loops of the feature that lie on the target body) of each new instance of the feature is wholly contained within a face of the body.

• Before copying a face of the feature, Parasolid first checks to see if the transformed boundary loop lies completely outside any face in the body. If so, this face is not copied.
• The second stage takes place after the face has been copied and transformed. The edges of the new boundary loop are checked for intersections with the edges of the destination face. If an intersection is found (that is, the new loop does not lie wholly within the destination face), the new faces corresponding to the transform are subsequently deleted.

Alternatively, check_loops may be set to PK_pattern_check_loops_outside_c. This tells PK_FACE_pattern to perform the first stage of the checking (mentioned above) but not the second. Consequently, instances that would lie completely outside any face in the body are not created, but those that may intersect a bounding edge of a face are allowed to remain. If faces are not copied (or copied and subsequently deleted), the returned information indicates this.

An example showing the differences between these three values of check_loops is given in Figure 54-8. Note that the body returned using PK_pattern_check_loops_no_c is invalid; those returned by using PK_pattern_check_loops_yes_c and PK_pattern_check_loops_outside_c are valid, however.

Figure 54-8 The effect of the check_loops option

54.3.2 Ensuring new instances do not intersect other faces

The check_fa_fa option intersects the faces of the new instances with existing faces of the body in order to detect any clashes that may have occurred. Figure 54-9 illustrates how this might happen.

Unlike the case for check_loops , if check_fa_fa detects clashes between instances and existing faces they are not removed, so the result body will be invalid due to the clashing faces. The returned information contains the tags of the clashing faces, so you can easily identify the location of the problem.

Figure 54-9 The effect of the check_fa_fa option

54.3.3 Returning errors when collisions occur

PK_FACE_pattern can detect when collisions occur, either between different instances in the resulting body, or between an instance and a pattern feature. You can use the collision option to choose whether or not to report these errors. By default, collision errors are not reported (PK_pattern_collision_no_c). Any collisions detected are not removed therefore the body will be invalid.

If this option is switched on, then you can find any collision errors in the relevant PK_pattern_status_t datatype for the colliding instance (found in pattern_results.patterns.status ). In the case of a collision, status has the value PK_pattern_status_colliding_c.

54.3.4 Improving performance when new instances lie in the same faces as the original feature

You can use the same_face option to improve performance when all of the boundary loops of the new instances of the feature lie in the faces containing the original feature.

If same_face is PK_pattern_same_face_yes_c (the default), performance of the patterning operation is improved provided that the boundary loops of the new instances remain in the faces containing the feature. An example of this is shown in Figure 54-10. Should they fall outside of these faces, the results depend on the value of check_loops : if set to PK_pattern_check_loops_yes_c, PK_FACE_pattern returns a valid body with only those instances that lie in the same faces; if set to PK_pattern_check_loops_no_c, it returns an invalid body with all the requested instances. In such cases you should consider setting same_face to PK_pattern_same_face_no_c as described in Section 54.3.5, “General patterning”.

Figure 54-10 New instances lie in the same faces as the original feature

54.3.5 General patterning

In general, the transformed versions of the feature may be altered during the patterning operation when creating new instances. These instances may or may not lie in the faces containing the original feature. Figure 54-11 illustrates a case where the transformed features must be altered in order to create instances that remain in contact with the destination faces (without passing through them).

If the transformed versions of the feature do not need to be altered before creating new instances, the boundary loops of the transformed features will be coincident with their respective destination faces; that is, they will lie wholly within the destination faces. In such cases, the coi_face option should be set to PK_pattern_coi_face_yes_c for optimal performance. If any alterations must be made to a transformed feature before creating the corresponding instance, one or more of its boundary loops will not be coincident with their respective destination faces. Here, the coi_face option should be set to PK_pattern_coi_face_unknown_c.

Figure 54-11 Transformed boundary loops are not coincident with their destination faces

Depending on whether the new instances all lie in the faces containing the original feature, and also whether transformed boundary loops are coincident with destination faces, different combinations of options should be specified as described below.

54.3.5.1 Instances all lie in the faces of the original feature

In this case, you should set same_face to PK_pattern_same_face_yes_c. If the transformed boundary loops are known to be coincident with the destination faces, you should set coi_face to PK_pattern_coi_face_yes_c; this is the case for the model shown in Figure 54-10. If not, coi_face should be PK_pattern_coi_face_unknown_c; this case is illustrated in Figure 54-11. The face_maps array should be set to NULL.

54.3.5.2 Instances lie in different faces and boundary loops are coincident with their destination faces

In this case, you should set same_face to PK_pattern_same_face_no_c and coi_face to PK_pattern_coi_face_yes_c. An example of this is shown in Figure 54-12. The face_maps array should be set to NULL.

Figure 54-12 New instances lie in different faces than the original feature and transformed boundary loops are coincident with their destination faces

54.3.5.3 Instances lie in different faces and boundary loops are not coincident with their destination faces

In this case, you should set same_face to PK_pattern_same_face_no_c and coi_face to PK_pattern_coi_face_unknown_c. If the destination faces of each new instance of the feature are known beforehand, the face_maps array should be used to specify them; this helps Parasolid maintain optimal performance. Each element of the array contains the mapping information for one instance. The fields in each element of the face_maps array are as follows:

n_loops

base_loops

target_faces

If the transformed boundary loops cross existing edges, however, or the destination faces are not known beforehand, you should set the face_maps array to NULL and check_loops to PK_pattern_check_loops_outside_c. Parasolid will then calculate the destination faces during the operation, at some additional cost to performance.

For the example given in Figure 54-13, the face_maps array consists of a single element containing the boundary loop and destination face shown in the diagram. The corresponding new instance is shown on the right-hand side.

Figure 54-13 The new instance lies in a different face than the original feature and the transformed boundary loop is not coincident with its destination face

For the example given in Figure 54-14, the feature is a hollow cylinder through the solid, with boundary loops on two faces as shown in the diagram. The face_maps array consists of two elements, each containing two boundary loops and two destination faces as shown. The corresponding new instances are shown on the right-hand side.

Figure 54-14 New instances lie in different faces than the original feature and transformed boundary loops are not coincident with their destination faces

For the sheet bodies shown in Figure 54-15, the new instances of the feature cross the boundaries of existing faces; therefore you should set face_maps to NULL and check_loops to PK_pattern_check_loops_outside_c. In Figure 54-15 (a), the new feature straddles two adjacent faces; in Figure 54-15 (b), it hangs off the end of an existing face. In both cases, the transformed boundary loops do not lie within a single destination face.

Figure 54-15 Examples of where new instances cross existing edges: face_maps should not be specified

54.3.5.4 Summary

The following table summarizes the possibilities for general patterning:

54.3.6 Recreating blends around patterned instances

If the boundary of the feature (to be copied) contains a face that has been blended, and the boundary loops of the transformed features may not be coincident with their respective destination faces (i.e., coi_face is PK_pattern_coi_face_unknown_c), you should recreate the blends during the patterning operation. This is done using the reblend option.

• If reblend is PK_pattern_reblend_no_c (the default), Parasolid does not attempt to recreate any blends when creating new instances. This may result in the failure of the operation if blend faces are present in the feature.
• If reblend is PK_pattern_reblend_yes_c, Parasolid recreates the blend on any resulting patterned faces, as shown in Figure 54-16.

Figure 54-16 Recreating blends on features with non-coincident boundary loops

[back to top]