Editing Libpg : A parametrics/constraint library
From BRL-CAD
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
{{DesignDocument}} | {{DesignDocument}} | ||
− | = | + | |
+ | = libpg : A parametrics/ constraint library = | ||
Proposed sytem for parametrics and constraint implementation | Proposed sytem for parametrics and constraint implementation | ||
Line 18: | Line 19: | ||
acts as a library which sits above librt using the librt methods for creation and modification of geometry | acts as a library which sits above librt using the librt methods for creation and modification of geometry | ||
− | |||
− | == | + | ==Architecture== |
A constraint system can be looked upon as a system of variables, their associated domains and set of constraints/relationships between the variables. | A constraint system can be looked upon as a system of variables, their associated domains and set of constraints/relationships between the variables. | ||
− | Fundamentally this can be visualised using a constraint network which is a 3-tuple. Further we can have a graph based visualization of the same using vertices as variables and edges connecting vertices as constraints. It would be intuitive only for networks having binary (between two variables) or unary ( | + | Fundamentally this can be visualised using a constraint network which is a 3-tuple.For a mathematical review please see ( Constraint Networks by Dawn Thomas ). Further we can have a graph based visualization of the same using vertices as variables and edges connecting vertices as constraints. It would be intuitive only for networks having binary (between two variables) or unary (constraints on self) constraints. Otherwise, one has to visualize hypergraphs which contain hyperedges which is basically a line connecting multiple vertices for example. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Implementation of the above constraint network in the BRL-CAD system, involves 3 fundamental aspects. | |
− | |||
− | |||
− | |||
− | + | # Domain extraction | |
+ | # Solution | ||
+ | # Geometry updation | ||
− | + | Prerequisites for such a state is of course | |
− | # | + | # "Handle" generation and storage |
− | # | + | # Updated geometry storage |
− | |||
− | |||
− | + | A typical constraint solution operation is shown below. | |
− | == | + | ==Object Architecture== |
An object oriented method of implementation would be the creation of a mixed ( in the sense that they contain both geometric and non-geometric information ) object. The object architecture is as shown below which shows the data types as well as the public and private methods. | An object oriented method of implementation would be the creation of a mixed ( in the sense that they contain both geometric and non-geometric information ) object. The object architecture is as shown below which shows the data types as well as the public and private methods. | ||
Line 88: | Line 73: | ||
'''What should be the convention for naming the parameters ? Also there is a certain issue in the sense that some of the geometry are special cases of more generic geometry. So for a sphere we are concerned with only radius and center where as it is defined using ( point center) and 3 vectors (a b c). Should we name the parameter radius make 3 fastf_t * to a[0], b[1], and c[2] Or should we make 3 vectp_t to a,b,c or make 1 fast_t* to a[0], doing a further check/constraint that a[0]=b[1]=c[2] ?''' | '''What should be the convention for naming the parameters ? Also there is a certain issue in the sense that some of the geometry are special cases of more generic geometry. So for a sphere we are concerned with only radius and center where as it is defined using ( point center) and 3 vectors (a b c). Should we name the parameter radius make 3 fastf_t * to a[0], b[1], and c[2] Or should we make 3 vectp_t to a,b,c or make 1 fast_t* to a[0], doing a further check/constraint that a[0]=b[1]=c[2] ?''' | ||
− | |||
− | |||
The datastructures necessary for the exchange of information (pc_pc_set which itself is built using a constraint set structure and parameter set structure) are defined currently in raytrace.h (Shift to pc.h in future? ) | The datastructures necessary for the exchange of information (pc_pc_set which itself is built using a constraint set structure and parameter set structure) are defined currently in raytrace.h (Shift to pc.h in future? ) | ||
Line 109: | Line 92: | ||
( param1= value, param2=value and so on) | ( param1= value, param2=value and so on) | ||
In this case the value is basically a region of the domain the parameter could occupy. | In this case the value is basically a region of the domain the parameter could occupy. | ||
+ | |||
+ | |||
+ | === Treatment of domain of parameters=== | ||
+ | |||
+ | # Option A: If a particular parameter has a domain(0.5<x<2.5) This can be viewed as the existance for two unary constraints on the parameter x ( x>0.5 and x<2.5 ) | ||
+ | # Option B: Utilization of a Domain class which basically is dynamic array of individual domains ( by individual domain I imply a [min,max] region ) | ||
For example | For example | ||
Line 117: | Line 106: | ||
#(p1, 2.3; p2, 2.2; p3, 1.4) : Unique solution P1=2.3, P2=2.2, P3=1.4 | #(p1, 2.3; p2, 2.2; p3, 1.4) : Unique solution P1=2.3, P2=2.2, P3=1.4 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
===Transfer of data from database to solver=== | ===Transfer of data from database to solver=== | ||
Line 133: | Line 117: | ||
Initial draft/intent | Initial draft/intent | ||
− | + | It would be ideal to provide both analytical and numeric evaluation methods the second one being of primary importance in terms of constraint based calculations. | |
− | + | Considering the standard methods of parametrization ( see Enumeration below ) I think the implementation of an analytic solving system would be easier. Though for the solution of more complex equation as well as majority of constraints , libpg will have to provide support for numerical solutions. | |
− | + | ||
− | + | ||
− | + | ==Enumeration of Parameters and Constraints== | |
+ | ''Various standard methods of parametrics and constraints available in CAD Programs ( CATIA as a case study )'' | ||
+ | ===Parametrics=== | ||
+ | #Point | ||
+ | ##Coordinates | ||
+ | ##On Curve | ||
+ | ##On Plane | ||
+ | ##On Surface | ||
+ | ##Circle/Sphere Centre | ||
+ | ##Tangent on Curve | ||
+ | ##Between (2 points) | ||
+ | ##Extremum | ||
+ | ##Extremum Polar | ||
+ | #Line | ||
+ | ##Point-Point | ||
+ | ##Point-Direction | ||
+ | ##Angle/Normal to the curve | ||
+ | ##Tangent to the Curve | ||
+ | ##Normal to the surface | ||
+ | ##Bisecting | ||
+ | #Plane | ||
+ | ##Offset from plane | ||
+ | ##Parallel through Point | ||
+ | ##Angle/Normal to Plane | ||
+ | ##Three points | ||
+ | ##Two Lines | ||
+ | ##Point and Line | ||
+ | ##Planar Curve | ||
+ | ##Normal to Curve | ||
+ | ##Tangent to Surface | ||
+ | ##Equation | ||
+ | ##Mean through points | ||
+ | #Axis | ||
+ | #Polyline | ||
+ | #Circle | ||
+ | #Corner | ||
+ | #Connect Curve | ||
+ | #Conic | ||
+ | #Spline | ||
+ | #Helix | ||
+ | #Spiral | ||
+ | |||
+ | ===Constraints=== | ||
+ | #Distance | ||
+ | #Length | ||
+ | #Angle | ||
+ | #Radius/Diameter | ||
+ | #Semimajor axis | ||
+ | #Semiminor axis | ||
+ | #Symmetry | ||
+ | #Midpoint | ||
+ | #Equidistant point | ||
+ | #Fix | ||
+ | #Coincidence | ||
+ | #Cocentricity | ||
+ | #Tangency | ||
+ | #Parallelism | ||
+ | #Perpendicular | ||
+ | #Horizontal | ||
+ | #Vertical | ||
+ | #Angle with axis | ||
+ | |||
+ | ==Notes== | ||
+ | |||
+ | ===Object Overlay=== | ||
+ | ===Extensibility=== | ||
+ | ===Interoperability=== |