Homovulgaris (Talk | contribs) (→Architecture) |
Homovulgaris (Talk | contribs) m (→Architecture) |
||

Line 28: | Line 28: | ||

Implementation of the above constraint network in the BRL-CAD system, involves 3 fundamental aspects. | 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 | Prerequisites for such a state is of course | ||

− | + | # "Handle" generation and storage | |

− | + | # Updated geometry storage | |

A typical constraint solution operation is shown below. | A typical constraint solution operation is shown below. |

Proposed sytem for parametrics and constraint implementation by Dawn Thomas (homovulgaris)

Provision for Parametrics and constraints greatly improves the performance of a Computer Aided Design System both in terms of geometry generation as well as analysis. Considering the unix model of division into multiple tools and libraries for individual functions as well as the fact that parametric/constraint functionalities are **not critical** elements in terms of geometry generation and raytracing, a logical solution would be the implemenation of a separate library (libpg)

libpg adds the following provisions to BRL-CAD system

- Creation & Modification of parameter-based geometry objects
- Creation of constraints between geometry objects
- Creation & Storage of Parametric Objects (non-geometric)
- Modification of geometry objects in .g files to indicate parametric nature

Part 1 would include building parametric objects based on existing non-parametric geometry objects as well as generation of purely parametric geometry. libpg acts as a library which sits above librt using the librt methods for creation and modification of geometry

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.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.

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.

From an Object Oriented point of view the major advantages is in terms of the structuring of data and in particular the system of calling methods or procedures. In effect each object knows how to evaluate equations within its space. For example a line or a curve **knows** ( has a method to ) calculate and return the coordinates of a point with a certain parameter value in its space ( a point at 0.6 ratio of length of the curve) With this value ( coordinates) thus returned and with the existing knowledge ( parent: curveid , parameter value:0.6 ) a parametric point object has the methods to instantiate it and store it.

The above method is efficient and useful only in the generation, modification and analysis of new geometry based on existing parametric/ non-parametric geometry. The evaluation method for constraints between already existing independent geometry would require special constraint objects. The effective difference between these objects and the earlier arises from the fact that generation of the parametric geometric objects depend on parametrics whereas constraints may or may not be feasible and thus evaluation would result in multiple solutions and they represent relationship between two independently defined elements ( parametrically or not )

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.

*Various standard methods of parametrics and constraints available in CAD Programs ( CATIA as a case study )*

- 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

- Distance
- Length
- Angle
- Radius/Diameter
- Semimajor axis
- Semiminor axis
- Symmetry
- Midpoint
- Equidistant point
- Fix
- Coincidence
- Cocentricity
- Tangency
- Parallelism
- Perpendicular
- Horizontal
- Vertical
- Angle with axis