Primitive Geometry

The SEDRIS Data Representation Model APPENDIX A - Classes Primitive Geometry

Abstract Class Name: Primitive Geometry

Superclass - <Geometry Representation>

Subclasses

Definition

An instance of this DRM class specifies data to describe a <Geometry Representation> instance.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

Example

A <Primitive Geometry> instance can be used to represent the surface geometry of a vehicle.

FAQs

How can a data provider indicate the correct retrieval order for the <Primitive Geometry> components of a <Union Of Primitive Geometry> instance U?: One way of doing this is by attaching the <Primitive Geometry> components of U in the order in which they are to be consumed, and setting ordering_reason field of U to SE_ORDREAS_FIXED_LISTED.
What happens to the context of <Union Of Primitive Geometry> components of <Continuous LOD Related Geometry> instances?: As a constraint, <Union Of Primitive Geometry> components of <Continuous LOD Related Geometry> instances are not allowed to have other <Union Of Primitive Geometry> instances within the scope of any of their <Primitive Geometry> components, a mechanism provided to allow a data provider to specify subfacing information. A terrain <Polygon> instance usually does not have subfaces. If there is a terrain <Polygon> instance within another coplanar <Polygon> instance, a <Rendering Priority Level> instance can be provided to determine the correct drawing order. This is usually a layering issue, wherein soil is usually rendered first, then vegetation, then water, and so on.
What happens if a <Rendering Priority Level> instance is encountered under a subfaced <Polygon> instance P?: The <Rendering Priority Level> instance should be handled normally. The siblings for P should be examined and those siblings with a lower rendering priority should be processed before those with a higher rendering priority.
What should the ordering_reason be for the <Union Of Primitive Geometry> instance?: The ordering_reason could still be valid for any of the enumerants currently in SE_Ordering_Reason. The actual drawing order is explicitly defined using a depth-first search for <Primitive Geometry> instances.
When a <Primitive Geometry> instance has a <Union Of Primitive Geometry> component for nesting reasons, what are the restrictions on the nested <Primitive Geometry> instances?: See <<Nested Primitive Geometry>>.