Saved view

From WikiSTEP

Jump to: navigation, search

According to ISO 16792 Technical product documentation — Digital product definition data practices a saved view is a "stored and retrievable specific orientation and a magnification factor of a model" and a model is a "combination of design model, annotation and attributes that describes a product". This page describes how to use AP203ed2/214 to fulfil the requirements of ISO 16792 to store a set of saved views, so that a receiving system is able to display the models in the desired way. This page belongs to the Recommended Practices for the Presentation of GD&T.

Contents

Introduction

Saved view is usually a view to 3D object with specific transformation applied to it. Popular views are TOP, FRONT and SIDE views, but saved view may also include any kind of perspective and isometric view. It is important to state that a saved view is not just limited to transformation. It may also include additional styling (colors, hatching, etc.) of particular element of object, clipping, additional annotation elements, etc.

L-Bracket from famous AS-1 test case (http://www.cax-if.de/library/as1.png) is taken as a basis for further explanations and examples. Original test case can be found here. In Figure 1, the widely used AS1 test example is displayed with one of the L-Bracket components selected. The further discussions and examples on this page are not using the complete assembly but only the single L-Bracket part.

As1.png
Figure 1. Original As1 example

Linking a set of saved views to a product

As initial step, we created 3 popular views: FRONT, TOP and SIDE(RIGHT). All of those views are linked to product structure using pattern similar to the one described in here. In this example 3 views belong to one presentation set, which is linked to the same product. Instance diagram for this particular test case is provided in Figure 2.

Saved view product structure.PNG
Figure 2. Linking a set of saved views to a product

All instances which are to the left of #1601=presentation_set() are representing 3 saved views. That's why each "instance box" in this diagram has 3 instances associated with it. In comparison to pattern described there, here we propose to use more generic types like presentation_area (instead of drawing_sheet_revision), area_in_set (instead of drawing_sheet_revision_usage) and presentation_set (instead of drawing_revision). Also instances of drawing_definition and draughting_title are no longer used here.

Partial population of instances from figure 2 (which matches one saved view and its association to presentation_set and product structure) is provided below:

#10400=PRESENTATION_VIEW('Front view',(#10410, #10323),#10401);
#10323=AXIS2_PLACEMENT_3D('',#10313,#10314,#10315);
#10510=MAPPED_ITEM('',#10511,#10501);
#10511=REPRESENTATION_MAP(#10323,#10400);
#10500=PRESENTATION_AREA('Sheet TOP',(#10510,#10521,#10501),#10504);
#10501=AXIS2_PLACEMENT_2D('',#10502,#10503);
#10520=PRESENTATION_SIZE(#10500,#10521);
#10521=PLANAR_BOX('',10.0,10.0,#10522);
#10522=AXIS2_PLACEMENT_2D('',#10523,#10524);
#10601=PRESENTATION_SET();
#10603=APPLIED_PRESENTED_ITEM((#711));
#10604=PRESENTED_ITEM_REPRESENTATION(#10601,#10603);
#10605=AREA_IN_SET(#10500,#10601);
#711=PRODUCT_DEFINITION_FORMATION('None','',#710);

The full test case is provided here.

Parallel and perspective projections

Saved view for the particular 3D object can be visualized using parallel or perspective projections. Latter one is also sometimes called central projection (in STEP as well). Type of projection is determined by attribute View_volume.projection_type. When value of View_volume.projection_type is .PARALLEL., object is displayed in parallel projection mode. When value of View_volume.projection_type is .CENTRAL., object is displayed in perspective projection mode. Entity View_volume and its attributes are more extensively described in this section. L-Bracket from as1 test case used throughout this section consists of 2 saved views (TOP and FRONT) displayed in parallel projection mode and one saved view displayed in perspective projection mode. This is graphically depicted in figure 3.

FRONT view.PNG TOP view.PNG SIDE view.PNG
Figure 3. Front, Top and Side views of L-bracket from AS1 test case.

Clipping planes

Clipping plane in STEP is associated with camera view. So first clipping is performed on 3D object and only after that 3D object is projected onto plane. "Entry point" to do clipping in STEP is entity camera_model_d3_multi_clipping. It can be combined with other subtypes of camera_model_d3: camera_model_d3_with_hlhsr and camera_model_with_light_sources. STEP data model is drawn in Figure 4.

Clipping model.PNG
Figure 4. STEP data model for clipping planes.

Simplest possible usage of clipping is to use one plane only without any further combinations. The next step towards more complex cases would be combination of 2 planes as intersecting or union. Most complex case would be mixture combination - union and intersecting of multiple planes. Simplified overview of those cases presented as projected into 2D plane is provided in Figure 5.

Clipping.PNG
Figure 5. Schematic representation of possible clipping cases.

Here symbols "+" and "-" identifies respectively positive and negative side of the plane. Positive side is the one where its normal is pointing to. Clipping plane according its definition divides the space into 2 halfspaces (positive and negative). Negative halfspace is removed, while positive should be displayed. In the case of union of 2 planes (top right case from figure 5) any point from 3D object is displayed if it is in the positive halfspace of any of 2 planes combined. In the case of intersection of 2 planes (bottom right case from figure 5) any point from 3D object is displayed only if it is in the positive halfspace of both planes combined. Likely most popular possible mixture of unions and intersections of few planes is so called "step". It is is displayed in figure 5, at bottom right corner. It is important to note that using mixture of few planes and especially multiple usage of unions may result in empty set (no point of 3D viewer is in resulted set), so it should be used with care.

Let's take the same test case - L-Bracket from AS1 as already used few times above. In the TOP view, it is quite useful to have simple clipping plane. Few cases with different location of clipping plane is provided in Figure 6. Placing clipping plane closer we can see all 3 drill holes in a cross section. Moving clipping plane further causes only one drill hole to be displayed. Moving clipping plane either further than the right picture from Figure 6 or closer than left picture of Figure 6 will cause no drill hole to be displayed.

Clipping TOP.PNG
Figure 6. Schematic representation of possible clipping cases.

Example p21 population for this test case with one clipping plane for TOP view is provided here:

#20311=(CAMERA_MODEL()CAMERA_MODEL_D3(#20312,#20320)CAMERA_MODEL_D3_MULTI_CLIPPING((#20330))
CAMERA_MODEL_D3_WITH_HLHSR(.T.)GEOMETRIC_REPRESENTATION_ITEM()REPRESENTATION_ITEM(' '));
/* Real transformation HERE */
#20312=AXIS2_PLACEMENT_3D(' ',#20313,#20314,#20315);
#20313=CARTESIAN_POINT('',(0.,0.,1.));
#20314=DIRECTION('',(1.,0.,0.));
#20315=DIRECTION('',(0.,0.,-1.));
#20320=VIEW_VOLUME(.PARALLEL.,#20321,0.,10.,.T.,10.,.F.,.T.,#20322);
#20330=PLANE('clipping plane for TOP view', #20331);
/* This is define in 'original' coordinate system */
#20331=AXIS2_PLACEMENT_3D(' ',#20332,#20333,#20334);
/* It is 'lifted' upwards to cut TOP view somewhere in the middle if center of object is arround (0, 0, 0) */
#20332=CARTESIAN_POINT('',(0.,20.,0.));
/* Z is pointing upwards and X - from end-user */
#20333=DIRECTION('',(0.,-1.,0.));
#20334=DIRECTION('',(0.,0.,-1.));

Another example is mixture of 3 clipping planes, so called "step" already schematically depicted in Figure 5 (bottom right corner).

SIDE view clipping mix.PNG
Figure 7. 3 clipping planes on Side view of L-Bracket from As1 test case.

Please note that sequence in which clipping planes are combined is important. So first 2 planes - far vertical plane and horizontal planes are combined as a union. As a next step - closer vertical plane is taken and combined as intersection with the result of union, which we get in the previous step.

Portion of entity instances for this complex mixture of 3 clipping planes is provided here:

/* Finally we do intersection of close horizontal plane with previously done union of 2 planes */
#30311=CAMERA_MODEL_D3_MULTI_CLIPPING('far vertical + horizontal planes',#30312,#30320,(#30351, #30330));
/* Real transformation HERE */
#30312=AXIS2_PLACEMENT_3D(' ',#30313,#30314,#30315);
#30313=CARTESIAN_POINT('',(0.,60.,0.));
#30314=DIRECTION('',(0.,0.,1.));
#30315=DIRECTION('',(0.,-1.,0.));
#30320=VIEW_VOLUME(.CENTRAL.,#30321,0.,10.,.T.,10.,.F.,.T.,#30322);
#30321=CARTESIAN_POINT(' ',(0.0,0.0,1.E2));
#30322=PLANAR_BOX(' ',3.,3.,#30323);
#30323=AXIS2_PLACEMENT_3D('',#30313,#30314,#30315);
/* First we do union of far vertical and horizontal clipping planes */
#30330=CAMERA_MODEL_D3_MULTI_CLIPPING_UNION('far vertical + horizontal planes',(#30331, #30341));
#30331=PLANE('far clipping plane for SIDE view', #30332);
/* This is define in 'original' coordinate system */
#30332=AXIS2_PLACEMENT_3D(' ',#30333,#30334,#30335);
/* It is 'pushed' further to cut SIDE view close the 'end' of 3D object, if center of object is arround (0, 0, 0) */
#30333=CARTESIAN_POINT('',(0.,0.,-40.));
/* Z is pointing to the end-user and X - to the right */
#30334=DIRECTION('',(0.,0.,1.));
#30335=DIRECTION('',(1.,0.,0.));
#30341=PLANE('horizontal clipping plane for SIDE view', #30342);
/* This is define in 'original' coordinate system */
#30342=AXIS2_PLACEMENT_3D(' ',#30343,#30344,#30345);
/* horizontal clipping plane cutting 3D object roughly halfly */
#30343=CARTESIAN_POINT('',(0.,0.,0.));
/* Z is pointing upwards and X - from end-user */
#30344=DIRECTION('',(0.,-1.,0.));
#30345=DIRECTION('',(0.,0.,-1.));
#30351=PLANE('near clipping plane for SIDE view', #30352);
/* This is define in 'original' coordinate system */
#30352=AXIS2_PLACEMENT_3D(' ',#30353,#30334,#30335);
/* Closest vertical clipping plane to cut SIDE view so that it just removes one closest plane */
#30353=CARTESIAN_POINT('',(0.,0.,-10.));

The full test case is provided here.

Annotation plane

Annotation_plane is a grouping of annotation elements that are arranged on a plane within a 3D coordinate space. The plane may be bounded by a rectangle and styled so that it becomes visible. EXPRESS data model is provided in Figure 8.

Annotation plane.PNG
Figure 8. EXPRESS data model for annotation_plane.

Annotation_plane is relating 2 instances - planar surface represented as plane or planar_box and optionally set of annotation elements which maybe placed on this plane. As plane is referred by annotation_plane as item, it can be also styled. The style is defined by presentation_style_assignment and subsequent items. Example of EXPRESS instances for annotation plane is provided here:

#30300=DRAUGHTING_MODEL('Right view',(#30311, #30312, #1235, #40000),#10167);
#30351=PLANE('near clipping plane for SIDE view', #30352);
/* This is define in 'original' coordinate system */
#30352=AXIS2_PLACEMENT_3D(' ',#30353,#30334,#30335);
/* Closest vertical clipping plane to cut SIDE view so that it just removes one closest plane */
#30353=CARTESIAN_POINT('',(0.,0.,-10.));

#40000=ANNOTATION_PLANE('front annotation plane',(#40001),#30351,(#40200));
#40001=PRESENTATION_STYLE_ASSIGNMENT((#40002));
#40002=FILL_AREA_STYLE('style for annotation plane',(#40003));
#40003=FILL_AREA_STYLE_COLOUR('blue',#40004);
/* Missing alpha value - don't know how to encode it */
#40004=COLOUR_RGB('partially transparent blue', 0.0, 0.0, 1.0);

/* --------- CALLOUT -------- */
#40200=LEADER_DIRECTED_CALLOUT('callout',(#40205,#40173,#40400));

This particular annotation_plane coincides with closest vertical clipping plane from Figure 7. Additionally leader_directed_callout (#40200) is placed in this annotation_plane. This callout is almost identical to the callout from section. The full test case is provided here.

Annotations in the 2D foreground plane

All the annotations and callouts that are items of a draughting_model or mechanical_design_geometric_presentation_representation rotate by default together with the 3D model because they share the same geometric_representation_context. But there may be annotations that should always be visible in the 2D foreground plane, in the front of 3D object. This canbe achieved by placing the annotations in either the presentation_area or the presentation_view of a saved_view.

As an example we take the text "Front view" displayed on top of 3D object, indication of center of mass for 3D object (indicated by cross "X") and supplemental text "Center of mass". The final result is provided in Figure 9. Those 3 elements - 2 strings and "X" indication are placed in 2D foreground.

FRONT view with foreground.PNG
Figure 9. Front view with 2D foreground plane.

EXPRESS instances, which are modeling example from Figure 9 is provided below:

#10400=PRESENTATION_VIEW('Front view',(#10410, #10323, #10573, #10623, #10650, #10654),#10401);
/* Annotation text - 'Front view' */
/* -------- TEXT ---------------*/
/* Text definition without style */
#10560=DRAUGHTING_PRE_DEFINED_TEXT_FONT('ISO 3098');
#10562=DIRECTION('',(1.0,0.0));
#10563=CARTESIAN_POINT('',(10,50));
#10564=AXIS2_PLACEMENT_2D('',#10563,#10562);
#10565=TEXT_LITERAL_WITH_EXTENT('','Front view',#10564,'baseline right',.RIGHT.,#10560,#10600);
/* Instance #10600 defines the planar_extent used to define the */
/* occupying space for the text string defined in #10565. */
#10600=PLANAR_EXTENT('extent of text string',60,10);
/* Text style */
#10569=DRAUGHTING_PRE_DEFINED_COLOUR('black');
#10570=TEXT_STYLE_FOR_DEFINED_FONT(#10569);
#10571=TEXT_STYLE_WITH_BOX_CHARACTERISTICS('a text style',#10570,
(BOX_HEIGHT(1.),
BOX_WIDTH(1.),
BOX_SLANT_ANGLE(0.),
BOX_ROTATE_ANGLE(0.)));
#10572=PRESENTATION_STYLE_ASSIGNMENT((#10571));
#10573=(ANNOTATION_OCCURRENCE()
ANNOTATION_TEXT_OCCURRENCE()
DRAUGHTING_ANNOTATION_OCCURRENCE()
GEOMETRIC_REPRESENTATION_ITEM()
REPRESENTATION_ITEM('')
STYLED_ITEM((#10572),#10565));
/* Annotation text - 'Centre of mass' */
#10623=(ANNOTATION_OCCURRENCE()
ANNOTATION_TEXT_OCCURRENCE()
DRAUGHTING_ANNOTATION_OCCURRENCE()
GEOMETRIC_REPRESENTATION_ITEM()
REPRESENTATION_ITEM('')
STYLED_ITEM((#10572),#10615));
#10613=CARTESIAN_POINT('',(-10,0));
#10614=AXIS2_PLACEMENT_2D('',#10613,#10562);
#10615=TEXT_LITERAL_WITH_EXTENT('','Center of mass',#10614,'baseline right',.RIGHT.,#10560,#10620);
/* Instance #10600 defines the planar_extent used to define the */
/* occupying space for the text string defined in #10565. */
#10620=PLANAR_EXTENT('extent of text string',80,10);
/*****************************/
/* 'X' made as 2 curves */
/* '\' curve */
#10650=(ANNOTATION_CURVE_OCCURRENCE()
ANNOTATION_OCCURRENCE()
DRAUGHTING_ANNOTATION_OCCURRENCE()
GEOMETRIC_REPRESENTATION_ITEM()
REPRESENTATION_ITEM('')
STYLED_ITEM((#10660),#10651));
#10651=POLYLINE('\\',(#10652,#10653));
/* Coordinates are very rough and likely not fully correct */
#10652=CARTESIAN_POINT('Left Top',(-1, 1));
#10653=CARTESIAN_POINT('Right Bottom',(1, -1));
/* '/' curve */
#10654=(ANNOTATION_CURVE_OCCURRENCE()
ANNOTATION_OCCURRENCE()
DRAUGHTING_ANNOTATION_OCCURRENCE()
GEOMETRIC_REPRESENTATION_ITEM()
REPRESENTATION_ITEM('')
STYLED_ITEM((#10660),#10655));
#10655=POLYLINE('/',(#10656,#10657));
/* Coordinates are very rough and likely not fully correct */
#10656=CARTESIAN_POINT('Left Bottom',(-1, -1));
#10657=CARTESIAN_POINT('Right Top',(1, 1));
/* Line style */
#10660=PRESENTATION_STYLE_ASSIGNMENT((#10661));
#10661=CURVE_STYLE('',#10662,#10664,#10663);
#10662=DRAUGHTING_PRE_DEFINED_CURVE_FONT('continuous');
#10663=DRAUGHTING_PRE_DEFINED_COLOUR('black');
#10664=LENGTH_MEASURE_WITH_UNIT(POSITIVE_LENGTH_MEASURE(0.1),#4);

Here, in presentation_view (#10400), already containing Front view via camera_image (#10410), we also directly added 2 annotation_text_occurrences (#10573, #10623), representing text 'Front view' and 'Center of mass' respectively. Presentation_view also contains 2 annotation_curve_occurrences (#10650, #10654) representing 2 curves ('\' and '/') of 'X' in the center of the picture.

The full test case is provided here.

Styling MDGPR

Styling of Mechanical_design_geometric_presentation_representation is extensively described in section.

Here, we use the same pattern to style L-Bracket of AS1. The EXPRESS instances are provided below:

#1227=MANIFOLD_SOLID_BREP('52D',#1226);
#50200=MECHANICAL_DESIGN_GEOMETRIC_PRESENTATION_REPRESENTATION('',(#1227, #50201, #50301, #50401),#10167);
#50201=STYLED_ITEM('',(#50202),#1227); 
#50202=PRESENTATION_STYLE_ASSIGNMENT((#50210)); 
/* By default all surfaces are displayed in green */
#50210=SURFACE_STYLE_USAGE(.BOTH.,#50211);
#50211=SURFACE_SIDE_STYLE('',(#50212));
#50212=SURFACE_STYLE_FILL_AREA(#50213);
#50213=FILL_AREA_STYLE('',(#50214));
#50214=FILL_AREA_STYLE_COLOUR('',#50215);
#50215=DRAUGHTING_PRE_DEFINED_COLOUR('green');
#50300=REPRESENTATION_RELATIONSHIP('', $, #10300, #50200);

The full test case is provided here.

Overriding style for particular items

As this style is applied to manifold_solid_brep (#1227), all surfaces of this 3D-body are displayed in green colour as visible in Figure 3 and others. This styling is handful when it is applied to the whole object or even group of objects. If some parts of objects has to use different styles - e.g. 1 or 2 surfaces has to be displayed in different colour or styling - over_riding_styled_item entity should be used. If the style for the item should be overridden only within specific context - subtype context_dependent_over_riding_styled_item shall be used. Entities relevant for the overriding of the style are presented in Figure 10.

Error creating thumbnail: Unable to run external programs in safe mode.
Figure 10. EXPRESS data model for overriding the default style for the item.

As an example we take TOP view (as shown in Figure 3) and make one face of red colour and one face of yellow as shown in Figure 11. Here the TOP view is slightly modified - rotated so that styled planes are better visible.

TOP view styled.png
Figure 11. TOP view with one face in red and another one in yellow.

In order to achieve such a styling of 2 planes - 2 context_dependent_over_riding_styled_item are used. As we are styling only one and the same view - they both point to the same "context". In this case it consists of 2 entities #20400(presentation_view) and #20410(camera_image). This means that style for the particular items is overriden only with the that context. EXPRESS instances, which 'encodes' those 'red' and 'yellow' faces within TOP view are presented here:

#50301=CONTEXT_DEPENDENT_OVER_RIDING_STYLED_ITEM('', (#50302), 
#1031, /* Overriding style for advanced_face for one plane */
#50201, /* Overriding style that all objects are displayed in green */
(#20400, #20410)); /* Context - Top view */
/* New style for particular item */
#50302=PRESENTATION_STYLE_ASSIGNMENT((#50310));
#50310=SURFACE_STYLE_USAGE(.BOTH.,#50311);
#50311=SURFACE_SIDE_STYLE('',(#50312));
#50312=SURFACE_STYLE_FILL_AREA(#50313);
#50313=FILL_AREA_STYLE('',(#50314));
#50314=FILL_AREA_STYLE_COLOUR('',#50315);
#50315=DRAUGHTING_PRE_DEFINED_COLOUR('red');

#50401=CONTEXT_DEPENDENT_OVER_RIDING_STYLED_ITEM('', (#50402), 
#1066, /* Overriding style for advanced_face for one plane */
#50201, /* Overriding style that all objects are displayed in green */
(#20400, #20410)); /* Context - Top view */
/* New style for particular item */
#50402=PRESENTATION_STYLE_ASSIGNMENT((#50410));
#50410=SURFACE_STYLE_USAGE(.BOTH.,#50411);
#50411=SURFACE_SIDE_STYLE('',(#50412));
#50412=SURFACE_STYLE_FILL_AREA(#50413);
#50413=FILL_AREA_STYLE('',(#50414));
#50414=FILL_AREA_STYLE_COLOUR('',#50415);
#50415=DRAUGHTING_PRE_DEFINED_COLOUR('yellow');

The full test case is provided here.

Light sources

Similar like with clipping planes - light sources are also associated to camera model in STEP. Overview diagram is already provided in Figure 4. Now we will analyze details of STEP model in the area of light sources. EXPRESS diagram is provided in Figure 12.

Light sources.png
Figure 12. EXPRESS model to represent light sources within camera model.

EXPRESS model was created at the times when graphics standards GKS-3D and PHIGS were in use. So it is slightly different than current trends in OpenGL or Direct3D. In spite of that, the major classification of light sources into positional (light_source_positional) and directional (light_source_directional) is still the same. Schematic comparison of those type of light sources is provided in Figure 13.


Light source directional.gif Light source positional.gif Light source spot.gif
Figure 13. Schematic representation of directional, positional and spot light sources.

In comparison to e.g. OpenGL - 'spot' is treated as separate type of light source, while in OpenGL it is just a 'special effect' of positional light source. So STEP has a limitation in this area - it is not possible to have positional and spot light source as one (make a complex instances), because there is a ONEOF constraint on supertype light_source. This can be workaround by making 2 light sources (one positional and one spot) at the same position. Another difference is that attenuation may have constant, linear and exponential factors in OpenGL, while in STEP there is only constant and distant factors. Otherwise 'lighting model' is compatible. Ambient light source (light_source_ambient) is the one which does not depend on neither position or orientation or light source nor the orientation of 3D object it is affecting. It is so called 'surrounding' light, usually matching the colour of daylight in the room or similar applications. Attenuation of the intensity of light is the feature of positional light sources (light_source_positional) only. This attenuation simulates the phenomena that intensity of light decrease when increasing the distance from light source to the object. Finally spot light (light_source_spot) simulates the phenomena which we usually see when using searchlight in the night or simple lamp in the room. Such kind of the light source do not emit the light equally in all directions. light_source_spot.spread_angle specifies the angle in which the light is transmitted. It is also possible to make distribution of the light within this angle non-linear. Light of laser has very big concentration around the 'central' direction (light_source_spot.orientation) and intensity is decreasing drastically for direction having bigger angle to 'central' direction. Usually in order to better see particular light sources it is better avoid light_source_ambient and light_source_directional. E.g. in Figure 3 all views are made with one light source point in the direction (0, 0, -1). So after some experiments it was chosen to add one light_source_positional and one light_source_spot. Result is provided in Figure 14.

Front view with lights.png
Figure 14. Front view with 2 positional and spot light sources.

First light source is positioned in upper part of 3D-object, with attenuation factors equal to 1(constant_attenuation) and 0.3(distant_attenuation) respectively. By default those factors are equal to 1 and 0 (meaning attenuation as an 'effect' is switched off). Second light source (of type light_source_spot) is positioned in lower part of 3D-object and its spot direction is upwards/right/towards 3D-object. Light_source_spot.concentration_exponent is set to 1 (it is 'switched off' - light is equally distributed inside the cone), Light_source_spot.spread_angle is equal to 7.5 degrees. This angle is half angle of the whole cone, according the definition. As it can be seen in Figure 14, first light source (due to higher attenuation) gives only little effect on 3D-object - that's why it is much darker in the upper part of the object. But it is not fully black as it is the side plane (on the right side of the picture), which does not get any light. Second spot light gives most intensive light, so the 'effect' is best noticeable in the lower part of 3D-object. Colour of both light sources is gray (0.3, 0.3, 0.3). In general it is a good practice to use white/gray colour for the light sources, unless someone wants to get some special effects. EXPRESS instances representing those 2 lights sources is given below:

#10311=CAMERA_MODEL_WITH_LIGHT_SOURCES(' ',#10312,#10320,(#60001,#60010));
#60001=LIGHT_SOURCE_POSITIONAL('light No.1',#60002,#60003,1,0.3);
#60002=COLOUR_RGB('gray', 0.3, 0.3, 0.3);
#60003=CARTESIAN_POINT('',(-2, 1, 3));
#60010=LIGHT_SOURCE_SPOT('light No.2',#60002,#60011,#60012,1,1,0,7.5);
#60011=CARTESIAN_POINT('',(-2, -2, 3));
#60012=DIRECTION('',(0.5, 0.5, -1));

The full test case is provided here.

Hierarchy of draughting_models and MDGPR

Sometimes it is useful to subdivide styling of the same model into few representations so that some styling is reused few times. Representation which have to be reused, shall be linked with another representation using representation_relationship (or its subtype). As an example we take styled MDGPR (#50200) from Figure 11. In addition we reuse it for another MDGPR (#60200), which makes front face white. Another reuse of MDGPR (#50200) is for Draughting_model (#60600), where we indicate with leader_directed_callout to the yellow face. Graphical representation of this structure is represented in Figure 15.

MDGPR hierarchy.PNG
Figure 15. Example of hierarchy structure linking MDGPRs and Draughting_model.

Here link between MDGPR is represented by #60100=MECHANICAL_DESIGN_AND_DRAUGHTING_RELATIONSHIP, link between MDGPR and Draughting_model is done via #60500=REPRESENTATION_RELATIONSHIP. How to link MDGPR and Draughting_model is described in section. EXPRESS instances representing the example given above is provided here:

#50200=MECHANICAL_DESIGN_GEOMETRIC_PRESENTATION_REPRESENTATION('',(#1227, #50201, #50301, #50401),#10167);

#60100=MECHANICAL_DESIGN_AND_DRAUGHTING_RELATIONSHIP('', $, #50200,#60200);
#60200=MECHANICAL_DESIGN_GEOMETRIC_PRESENTATION_REPRESENTATION('',(#1227, #60401),#10167);
#60401=CONTEXT_DEPENDENT_OVER_RIDING_STYLED_ITEM('', (#60402), 
#1211, /* Overriding style for advanced_face for one plane - front face */
#50201, /* Overriding style that all objects are displayed in green */
(#20400, #20410)); /* Context - Top view */
/* New style for particular item */
#60402=PRESENTATION_STYLE_ASSIGNMENT((#60410));
#60410=SURFACE_STYLE_USAGE(.BOTH.,#60411);
#60411=SURFACE_SIDE_STYLE('',(#60412));
#60412=SURFACE_STYLE_FILL_AREA(#60413);
#60413=FILL_AREA_STYLE('',(#60414));
#60414=FILL_AREA_STYLE_COLOUR('',#60415);
#60415=DRAUGHTING_PRE_DEFINED_COLOUR('white');

/* Making MDGPR - with one leader curve */
#60500=REPRESENTATION_RELATIONSHIP('', $, #50200,#60600);
#60600=DRAUGHTING_MODEL('',(#1227, #70200),#10167);
#70200=LEADER_DIRECTED_CALLOUT('callout for one plane',(#70205,#70173,#70400));
/* callout is further modeled the same way as it is already described in section for callouts */

The full test case is provided here.

Association of representation and presentation data for Datum stuff

General mechanism used to associate representation and presentation data is provided in section. Patterns specific to Datum stuff (Datum, Datum_target) are described here. In this section example callouts.stp will be extended to also have representation of datum and datum_target and link it their presentation. EXPRESS-G diagram for associativity between presentation and representation of datum_feature is provided in Figure 16.

Datum feature associativity.png
Figure 16. Associativity between presentation and representation of datum_feature.

Here Datum_feature(#12010) as a subtype of Shape_aspect is associated with the Datum (#12030) it belongs to. Datum_feature via geometric_item_specific_usage (#12050) is associated with the plane (#10096), which is 'representation'. 'Presentation' is datum_feature_callout (#1000), which is associated with the same Datum_feature via draughting_model_item_association (#12040). EXPRESS instances specific to this particular case from callouts.stp test case is provided here:

#12040=DRAUGHTING_MODEL_ITEM_ASSOCIATION(' ',$, #12010, #151, #1000);
#12010=DATUM_FEATURE('',$,#97,.T.);
#12020=SHAPE_ASPECT_RELATIONSHIP('feature in datum A',$,#12010,#12030);
#12030=DATUM('',$,#97,.T.,'A');
#12050=GEOMETRIC_ITEM_SPECIFIC_USAGE(' ',$, #12010, #10168, #10096);

It is important to note that there is not 'datum_callout', therefore there is no direct associativity between presentation and representation of datum itself. It is done only via datum's features and targets. Case of datum_feature is already provided above. Datum_target is not very much different from datum_feature from the perspective of the pattern to be used. We took one edge of the plane representing datum as an example of datum_target. Diagram is provided in Figure 17.

Datum target associativity.png
Figure 17. Associativity between presentation and representation of datum_target.

EXPRESS instances specific to this example are provided below:

#13040=DRAUGHTING_MODEL_ITEM_ASSOCIATION(' ',$, #13010, #151, #3000);
#13010=DATUM_TARGET('',$,#97,.T.,'A1');
#13020=SHAPE_ASPECT_RELATIONSHIP('target in datum A',$,#13010,#12030);
#13050=GEOMETRIC_ITEM_SPECIFIC_USAGE(' ',$, #13010, #10168, #10074);

The full test case is provided here.

Personal tools