 |
Checking |
Checking
| <<< General Bodies | Chapters | Boolean Operations >>> |
The Parasolid checker is intended to:
Checking is a time consuming operation and can be much slower than local checking. If you turn local checking OFF to save time when you are performing a sequence of local operations, or you want one of the intermediate operations to create an invalid body, you can call PK_BODY_check to check the final body. If PK_BODY_check indicates that the body is invalid then roll back to a point before the local operations, and try a different approach.
Local checking is a time saving tool, because, in contrast to a full body check, it only checks the features of the model that were changed by that particular operation.
By default, the checking functions make all the checks appropriate to the supplied entity, but the caller may control which checks are applied by supplying options to the relevant checking function. The checking functions available are listed below.
| Function | Description |
|---|---|
The different types of checks are performed in groups in a certain sequence, where each group of checks only proceeds if the previous checks have all passed; therefore, checks which rely on the results of previous checks are omitted if these have failed. This means that the checking functionality does not guarantee to find all the faults if there is more than one.
An option structure, specific to each checking function, allows for the setting of which of the relevant checks are to be performed and the setting of the number of faults that are to be returned:
| Check | Description |
|---|---|
|
which if any topology geometry consistent checks are to be performed |
|
The checks specific to each checking function are:
| BODY | EDGE | FACE | FACE_check_pair | GEOM | TRANSF | |
|---|---|---|---|---|---|---|
These checking functions never return more than
max_faults
faults. If
max_faults
is set to zero and any fault is found, the function fails with the error PK_ERROR_check_error. The application may thereby force all check faults to cause errors. The entity in error is returned in the error standard form.
If
max_faults
is set greater than zero then up to
max_faults
check faults may be returned. It is not guaranteed that all faults are found even if
max_faults
is large enough. To acquire as many faults as possible, the application should set
max_faults
to a large number, e.g. 1000.
Entities may fail the checker for a number of reasons; not all of these mean that the entity is completely corrupt and can not be modeled with. This section provides additional detail on each of the fault types, and suggestions on what should be done in each case.
Most modeling operations continue to work on a body which has failed the checker in a local fashion (e.g. with one invalid face, edge, or piece of geometry) so long as the offending area is not directly involved in the operation. Often the best way to salvage such a body is to remove the offending entities altogether with a local operation or boolean.
Similarly, many modeling operations work on a body which has failed the face-face inconsistency check (for instance, if regions interpenetrate), although the hidden-line algorithm may fail; and mass properties calculations may give misleading answers.
This can happen if the caller does not roll back after a modeling error (e.g. a boolean failure); otherwise it usually means a serious bug in Parasolid, which should be reported, although occasionally it may be caused by an invalid sequence of calls to the PK interface. The caller must roll back or restart the modeler (PK_ENTITY_delete sometimes fails on corrupt parts).
This fault should only occur in bodies made in v5 of Parasolid or before, or bodies created by modeling with such bodies in later versions.
This fault can be corrected by calling PK_PART_rectify_identifiers.
If this fault occurs in bodies created wholly in later versions of Parasolid, or after PK_PART_rectify_identifiers has been called on any body, it should be reported as a serious bug in Parasolid. However, it should not cause problems unless the application is using identifiers and relying on their uniqueness.
This can arise naturally after local operations, or if geometry has been explicitly deleted or detached; there are several ways to remedy the situation (e.g. PK_EDGE_attach_curves, PK_FACE_attach_surf_fitting).
Bodies which are invalid because of missing geometry are identified as such by the checker. You create a body like this in the process of making a sheet by scribing lines on a wire body. When the wire is closed you have a sheet with edge geometry. PK_BODY_check detects this, and the problem can be rectified using PK_FACE_attach_surf_fitting to create a surface for one of the faces.
A body with missing geometry can be manipulated by most local operations (see Chapter 12, "Local Operations"), provided the parts of the body which are changed have geometry attached. Boolean operations cannot be performed on bodies with missing geometry, and in general, care is needed in their manipulation.
This can happen if geometry is constructed incorrectly with parameter checking switched off (see PK_SESSION_set_check_arguments). It is usually possible to rescue the model by deleting the offending geometry and replacing it with valid geometry.
PK_GEOM_state_self_int_c, PK_GEOM_state_degenerate_c
These can happen if geometry is created with self-intersection checking switched off (see PK_SESSION_set_check_self_int); again, it is best to replace the offending geometry.
This can happen if the composite geometry checks are switched off (see PK_SESSION_set_check_continuity) when the geometry is attached to topology; some modeling operations may work with the offending geometry, but it is best to replace it if possible.
The related edge has been turned into a ring edge by the large tolerances, leaving an open curve as the geometry. This token should not arise under normal circumstances. It indicates an internal failure which could arise, for example, if the tolerances on the edge become so large as to consume features incorrectly.
The related edge has been turned into a ring edge by the large tolerances, leaving an open curve as the nominal geometry. This token should not arise under normal circumstances. It is similar to PK_EDGE_state_open_c, except that the problem is indicated by the nominal curve on the edge, rather than the edge itself.
This could arise as a result of a tolerance mismatch, or incorrect use of PK_EDGE_attach_curves. Resetting tolerances or re-positioning the geometry should resolve the fault.
PK_EDGE_state_bad_vertex_nmnl_c
This token should not arise under normal circumstances, because the functions for attaching nominal geometry perform enough checks to prevent it. It indicates an internal failure in which the tolerances on the nominal geometry have become too large, and a body exhibiting this would probably have other failures. To resolve this problem, either reset the tolerances on the nominal geometry or, failing this, detach the nominal geometry from the body.
This could arise as a result of incorrect use of PK_EDGE_attach_curves. Detaching the curve, negating it, and re-attaching it would solve the problem.
This token should not arise under normal circumstances, because the functions for attaching nominal geometry perform enough checks to prevent it. It indicates an internal failure in which the tolerances on the nominal geometry have become too large, and a body exhibiting this would probably have other failures. To resolve this problem, either reset the tolerances on the nominal geometry or, failing this, detach the nominal geometry from the body.
This could happen as a result of invalid SP-curve data, or more likely an unsuitable tolerance value on the edge, which could be resolved using PK_EDGE_set_precision or PK_VERTEX_attach_points.
This token should not arise under normal circumstances, because the functions for attaching nominal geometry perform enough checks to prevent it. It indicates an internal failure in which the tolerances on the nominal geometry have become too large, and a body exhibiting this would probably have other failures. To resolve this problem, either reset the tolerances on the nominal geometry or, failing this, detach the nominal geometry from the body.
PK_EDGE_state_vertices_touch_c
Again, this could be a tolerance problem or the result of incorrect use of PK_EDGE_attach_curves. Resetting tolerances or replacing the geometry of the edge or vertices should resolve the fault.
PK_EDGE_state_bad_face_order_c
This can only happen on a non-manifold edge. It means that the order of the faces around an edge in the topological data structure does not agree with the order of the surfaces attached to those faces.
This could arise as a result of a tolerance mismatch, or incorrect use of PK_FACE_attach_surfs or PK_VERTEX_attach_points. Resetting tolerances or re-positioning the geometry should resolve the fault.
This could arise as a result of a tolerance mismatch, or incorrect use of PK_EDGE_attach_curves or PK_FACE_attach_surfs. Resetting tolerances or re-positioning the geometry should resolve the fault.
This could arise as a result of a local operation which produces a self-intersecting body. Further local operations to remove the self-intersection, or a subsequent modeling operation which destroys the offending face, should resolve the fault.
PK_FACE_state_bad_edge_order_c
This could arise as a result of incorrect use of PK_EDGE_attach_curves. Re-attaching the curves so that their edges are correctly ordered around the vertex should resolve the fault.
This could arise as a result of incorrect use of PK_EDGE_attach_curves or PK_SURF_make_sheet_trimmed. It means either that the directions of the loops in the face are wrong, or that the number and types of loops in the face are inconsistent with the surface type.
PK_FACE_state_no_vtx_at_sing_c
This could arise as a result of incorrect use of PK_EDGE_attach_curves. The problem could be avoided by introducing the surface into the model in a different way (e.g. PK_SURF_make_sheet_body).
PK_FACE_state_bad_wire_fa_ed_c
This could arise as a result of incorrect use of PK_EDGE_attach_curves or PK_FACE_imprint_curve on a general body. It means that a wireframe edge intersects a face other than at a vertex.
PK_EDGE_state_bad_wire_ed_ed_c
This could arise as a result of incorrect use of PK_EDGE_attach_curves or PK_FACE_imprint_curve (with local checking turned off) on a wire or general body. It means that two wireframe edges intersect other than at a vertex.
This fault should be avoided, but does not mean that modeling operations will necessarily fail. Modeling with entities outside the size-box may often work, but is not recommended, as resolution problems are more likely to occur.
This could arise as a result of a local operation which produces a self-intersecting body. Further local operations to remove the self-intersection, or a subsequent modeling operation which destroys the offending region, should resolve the fault.
This could arise as a result of incorrect use of PK_EDGE_attach_curves. Negating the body with PK_BODY_reverse_orientation resolves the problem.
The checker returns this when a region itself is invalid. This could arise as a result of incorrect use of PK_FACE_attach_surfs (e.g. making a body with two positive shells). It is possible that the problem could be resolved with a local operation (deleting or tweaking the faces of one of the shells, for example).
The checker returns this when there is an inconsistency between regions. This could arise as a result of incorrect use of PK_FACE_attach_surfs. It means that either the body contains more than one infinite region, or that the infinite region is not the first region. In some cases the problem may be solved using PK_BODY_reverse_orientation or by PK_FACE_attach_surfs.
PK_SHELL_state_bad_topol_geom_c
This could arise as a result of incorrect use of PK_FACE_attach_surfs, it can only occur for general bodies. It means that a wireframe edge or a face in a shell is not geometrically inside that shell.
This could arise as incorrect use of PK_FACE_attach_surfs, it can only occur for general bodies. It means that an acorn shell is coincident with another shell.
PK_TOPOL_state_check_fail_c, PK_FACE_state_check_fail_c
These fault types are used to distinguish cases where the checker itself has failed, due to an internal numerical problem. They should not be taken to mean that the body itself is invalid.
This could arise if a non-printing character (such as a linefeed or carriage return) is used in an attribute definition name. See Chapter 46, "Attribute Definitions" for a description of attribute definitions.
Local checking only tests whether the body has been invalidated by the operation performed. If a body is invalid before a local operation, in a region not affected by the operation, local checking is not guaranteed to identify the body as invalid.
Local checking is activated through an argument of the relevant function. Functions that use the local checking switch are:
When local checking is turned ON then the
state
return argument of each local operation function is set to one of the following values:
If the body was previously invalid, in an area that isn't affected by the local operation, the body in general terms would therefore still be invalid.
Figure 8-1 Face normal senses on a valid body
Because of the direction of the face normal of the face from which the pyramid was created, the resulting face normal senses of the pyramid point into the body.
Figure 8-2 Face normal senses of a negative body
As this body is therefore negative and invalid, it is automatically negated by Parasolid and the token PK_local_check_negated_c is returned to advise you that this is what has happened.
The local operations can succeed (return PK_ERROR_no "state" argument after calling a local operation.
The checks that are performed by Parasolid when local checking is turned ON are completed in three stages:
If this initial check fails, an error is returned indicating why the check failed. When this occurs you are strongly advised to do a rollback.
Checking for, and correcting, negated shells is performed whether or not local checking is 'ON'; however if local checking is OFF then a state of PK_local_check_negated_c is not returned even though the check has been performed.
Providing that the body passes the initial stage PK_ERROR_no_errors are returned.
When Parasolid performs local operations with checking OFF, only very simple checks are made on the integrity of the body after the operation and the result returned is PK_local_check_no_c. This is desirable if the resulting body is an intermediate stage which you expect to be invalid.
For general bodies the result PK_local_check_negated_c is never returned since this has no meaning for general bodies.
Other modeling functions, though they don't have the
local_check
option, do have an argument to activate face-face checking. They include the following:
These functions all return further information about faults via the PK_ERROR standard form structure.
Checking is a time consuming operation. If you turn local checking OFF to save time when you are performing a sequence of local operations, or you want one of the intermediate operations to create an invalid body, you can call PK_BODY_check to check the final body. If the check indicates that the body is invalid then roll back to a point before the local operation, and try a different approach.
Local checking only tests whether the body has been invalidated by the operation performed. If a body is invalid before a local operation, in a region not affected by the operation, local checking is not guaranteed to identify the body as invalid.
When Parasolid performs local operations with checking ON, each affected face is checked to ensure it is consistent with itself and with every other face in the body. The checking can return a number of results.
This check is also performed when local checking is OFF, but in this instance the returned result is PK_local_check_no_c.
Local operation checking is more efficient than checking the whole body especially if the local operation affects a small proportion of the body's entities. However, if Parasolid is performing a number of local operations, you may prefer to check the entire body when all the operations are complete rather than performing local checking at each operation.
|
Note: When fixing blends, local checking is performed as part of the PK_BODY_fix_blends operation. |
When spinning bodies you must take care with the positioning of the axis. For example you are not permitted to spin a wire body through 2pi if an internal vertex rests on the axis as this would result in a non-manifold sheet body. Also it is easy to create self-intersecting bodies by sweeping or swinging. Always make sure to check the results, either by having local checking on, or using PK_BODY_check on the resulting bodies. For more information about these restrictions see the description of PK_BODY_spin.
If the local checking is ON the body is checked after the blending has been carried out. In the case of a planar body the altered body is valid, but for a non-planar body local checking may return that the altered body is invalid.
When creating curves and surfaces in Parasolid there are a few restrictions placed on the resulting curves and surfaces. These restrictions are to ensure that the curve or surface does not self-intersect or have a cusp. Any function that requires a surface which has been checked performs these checks. These checks shall only be performed once, with the result being stored in the data structure.
The PK_GEOM_check function can be used to test if the surface is acceptable to Parasolid for modeling purposes.
Full details of the restrictions on parametric curves and surfaces are given in Chapter 25, "B-Curves and B-Surfaces".
Applications should provide users with control over local checking, and should provide the option to check bodies whenever they like it: it is suggested that two levels of body checking be provided, both with and without the face-face inconsistency check. The face-face inconsistency check is by far the most time-consuming for all but the simplest models, and should only be used when self intersection is suspected.
With experience you will be able to judge when to use local checking and how often to use the checking functionality in the kind of modeling you typically do. To begin with, you will want to rely on it more, but with experience you will be able to work faster by skipping checks when they are not really needed.
The following checking options can be set by their relevant functions.
Parasolid performs simple checking of all arguments, but much more rigorous checking can be applied through PK_SESSION_set_check_arguments. This additional checking is ON by default, and has performance penalties but identifies problems as soon as possible. If this optional checking is not applied, a function argument error might not become apparent until it causes an error much later in the session.
Argument checking can be turned ON or OFF in a session; the current setting is returned by PK_SESSION_ask_check_arguments. It is expected that argument checking is switched ON in the vast majority of sessions since, in general, the improvement in error detection far outweighs the effects on performance. However, if you have tested a piece of code rigorously and performance is of prime importance, this balance may change.
Self intersection checking is optional and can be switched ON or OFF in a session using PK_SESSION_set_check_self_int.
To prevent the creation of invalid bodies Parasolid requires that for a curve or surface to be attached to an edge or face it must be valid. Attaching a self intersecting curve or surface, which is therefore invalid, to an edge or face would create an invalid body.
The checking of a B-curve, B-surface, or an offset of a B-surface for self intersection is an expensive operation. This facility allows curves and surfaces to be used in modeling operations without the self intersection check being made. It is not intended for this facility to provide a method of modeling with self intersecting geometry but to be used when there is confidence that the geometry does not self intersect.
With self intersection checking switched OFF B-curve/surface geometry is still checked against the usual restriction on these entities, e.g. chord length, continuity, etc. The current setting is returned by PK_SESSION_ask_check_self_int.
For further information see Chapter 25, "B-Curves and B-Surfaces".
PK_BODY_check only insists that the geometry does not self intersect if the self intersecting checking facility is switched ON.
Self intersection checking of offset surfaces is approached as follows:
Composite geometry checks that are performed on B-curves and B-surfaces, when determining whether the geometry can be modeled as a single topological entity, can be turned ON or OFF using PK_SESSION_set_check_continuity. The current setting is returned by PK_SESSION_ask_check_continuity.
| <<< General Bodies | Chapters | Boolean Operations >>> |