https://brlcad.org/w/api.php?action=feedcontributions&user=203.110.245.32&feedformat=atomBRL-CAD - User contributions [en]2020-03-31T01:34:49ZUser contributionsMediaWiki 1.32.2https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=585Libpg : A parametrics/constraint library2008-06-13T00:30:24Z<p>203.110.245.32: /* Evaluation System */</p>
<hr />
<div>{{DesignDocument}}<br />
<br />
= libpg : A parametrics/ constraint library =<br />
<br />
Proposed sytem for parametrics and constraint implementation<br />
by Dawn Thomas (homovulgaris)<br />
<br />
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)<br />
<br />
==Function==<br />
libpg adds the following provisions to BRL-CAD system<br />
<br />
# Creation & Modification of parameter-based geometry objects<br />
# Creation of constraints between geometry objects<br />
# Creation & Storage of Parametric Objects (non-geometric)<br />
# Modification of geometry objects in .g files to indicate parametric nature<br />
<br />
Part 1 would include building parametric objects based on existing non-parametric geometry objects as well as generation of purely parametric geometry. libpg<br />
acts as a library which sits above librt using the librt methods for creation and modification of geometry<br />
<br />
<br />
==Architecture==<br />
<br />
A constraint system can be looked upon as a system of variables, their associated domains and set of constraints/relationships between the variables.<br />
<br />
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.<br />
<br />
Implementation of the above constraint network in the BRL-CAD system, involves 3 fundamental aspects.<br />
<br />
# Domain extraction<br />
# Solution<br />
# Geometry updation<br />
<br />
Prerequisites for such a state is of course<br />
<br />
# "Handle" generation and storage<br />
# Updated geometry storage<br />
<br />
A typical constraint solution operation is shown below.<br />
<br />
==Object Architecture==<br />
<br />
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.<br />
[[Image:LibpgObjectArch.png|600px|Object Architecture Image]]<br />
<br />
===Parametric Geometric Objects===<br />
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.<br />
===Constraint Objects===<br />
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 )<br />
<br />
<br />
==Integration with librt==<br />
<br />
Two major aspects of integration with librt are<br />
# Database I/O<br />
# Declaration/ Extraction of parameters/variables from respective rt_*_internal structures<br />
<br />
Since most of the database input-output presently is completely handled by librt, it is expedient to use the same convention for writing the new non-geometric constraint object to the database. This is achieved through the pc_constraint_export and pc_constraint_import functions which are called by such functions as wdb_export or rt_db_put_internal via a new functab entry in table.c<br />
Or in more detail the steps taken to achieve these are<br />
<br />
# Definition of ID_CONSTRAINT (39) in raytrace.h ( corresponding increment to ID_MAXIMUM)<br />
# Creation of a corresponding entry to functab array in table.c<br />
# Addition of pc_constraint_export,pc_constraint_import and pc_constraint_ifree functions<br />
<br />
Regarding the declaration or extraction of parameters, the method of approach is to use a callback function rt_functab. Associated with each existing element<br />
we add a rt_*_params function which is called via the functab. This would declare the list of parameters it is built on as well as the list of implicit constraints on these parameters if any ( for example in the case of an ellipse<br />
there are 4 parameters: 1 point - center, 3 vectors-a,b,c and associated constraints ). This data is stored as a pc_pc_set (ParameterConstraint Set)<br />
This way, after the implementation of libpc we can remove most of the code from existing rt_*_prep functions which do such implicit constraint checking handling the same via libpc<br />
<br />
#Addition of rt_*_params to the RT_DECLARE_INTERFACE macro in table.c<br />
#Addition to the functab table in table.c<br />
#Definition of corresponding function is various primitives/*.c files<br />
<br />
'''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] ?'''<br />
<br />
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? )<br />
<br />
==Evaluation System==<br />
<br />
June 10th: The idea is to implement a constraint network using graph representation of boost c++ library. From the solvers point of view the constraint network would be composed of the following ( which are class definitions in pc_solver.h file)<br />
<br />
* Constraint Network: A Graph composed of vertices being parameters and edges being constraint relations. The difference from the normal graph is in the sense that an edge (or hyperedge ) maybe connecting more than two vertices.<br />
** Parameter Object: Vertex of the graph:<br />
*** Pointers to various constraints it is connected to<br />
** Constraint Object: Edge/Hyperedge of the graph - Relation between parameters<br />
*** Pointers to the parameters int the particular relation<br />
*** Relation : Basic representation of the relationship<br />
**** Relation Stack : The stack based representation of the relationship<br />
<br />
The action of the Solver object/method is the production of a Solution Class<br />
A Solution is basically an instantiation of parameters along with their possible values or an instantiation of the form<br />
( param1= value, param2=value and so on)<br />
In this case the value is basically a region of the domain the parameter could occupy.<br />
<br />
For example <br />
consider parameter set p1,p2,p3<br />
The solution maybe<br />
#(p1, 0.5-1.5; p2, 0.2) : P3 can have any value if P2 =0.2 and P1 lies in the range [0.1,1.5]<br />
#(p1, 1.8; p2, 0.3-0.8; p3, 0.3-0.9) : P1=1.8, and P2 lies in the range [0.3,0.8] and P3 in the range [0.3,0.9]<br />
#(p1, 2.3; p2, 2.2; p3, 1.4) : Unique solution P1=2.3, P2=2.2, P3=1.4<br />
<br />
<br />
=== Treatment of domain of parameters=== <br />
<br />
# 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 )<br />
# Option B: Utilization of a Domain class which basically is dynamic array of individual domains ( by individual domain I imply a [min,max] region )<br />
<br />
===Transfer of data from database to solver===<br />
Modus operandi:<br />
# Import data and create pc_pc_set using rt_*_params functions via rt_functab<br />
# Run a domain extractor on the constraint objects in pc_set<br />
# Generate the constraint network<br />
# Call Solver<br />
<br />
<br />
Initial draft/intent<br />
<br />
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.<br />
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.<br />
<br />
==Enumeration of Parameters and Constraints==<br />
''Various standard methods of parametrics and constraints available in CAD Programs ( CATIA as a case study )''<br />
===Parametrics===<br />
#Point<br />
##Coordinates<br />
##On Curve<br />
##On Plane<br />
##On Surface<br />
##Circle/Sphere Centre<br />
##Tangent on Curve<br />
##Between (2 points)<br />
##Extremum<br />
##Extremum Polar<br />
#Line<br />
##Point-Point<br />
##Point-Direction<br />
##Angle/Normal to the curve<br />
##Tangent to the Curve<br />
##Normal to the surface<br />
##Bisecting<br />
#Plane<br />
##Offset from plane<br />
##Parallel through Point<br />
##Angle/Normal to Plane<br />
##Three points<br />
##Two Lines<br />
##Point and Line<br />
##Planar Curve<br />
##Normal to Curve<br />
##Tangent to Surface<br />
##Equation<br />
##Mean through points<br />
#Axis<br />
#Polyline<br />
#Circle<br />
#Corner<br />
#Connect Curve<br />
#Conic<br />
#Spline<br />
#Helix<br />
#Spiral<br />
<br />
===Constraints===<br />
#Distance<br />
#Length<br />
#Angle<br />
#Radius/Diameter<br />
#Semimajor axis<br />
#Semiminor axis<br />
#Symmetry<br />
#Midpoint<br />
#Equidistant point<br />
#Fix<br />
#Coincidence<br />
#Cocentricity<br />
#Tangency<br />
#Parallelism<br />
#Perpendicular<br />
#Horizontal<br />
#Vertical<br />
#Angle with axis<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability===</div>203.110.245.32https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=584Libpg : A parametrics/constraint library2008-06-13T00:29:38Z<p>203.110.245.32: /* Treatment of domain of parameters */</p>
<hr />
<div>{{DesignDocument}}<br />
<br />
= libpg : A parametrics/ constraint library =<br />
<br />
Proposed sytem for parametrics and constraint implementation<br />
by Dawn Thomas (homovulgaris)<br />
<br />
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)<br />
<br />
==Function==<br />
libpg adds the following provisions to BRL-CAD system<br />
<br />
# Creation & Modification of parameter-based geometry objects<br />
# Creation of constraints between geometry objects<br />
# Creation & Storage of Parametric Objects (non-geometric)<br />
# Modification of geometry objects in .g files to indicate parametric nature<br />
<br />
Part 1 would include building parametric objects based on existing non-parametric geometry objects as well as generation of purely parametric geometry. libpg<br />
acts as a library which sits above librt using the librt methods for creation and modification of geometry<br />
<br />
<br />
==Architecture==<br />
<br />
A constraint system can be looked upon as a system of variables, their associated domains and set of constraints/relationships between the variables.<br />
<br />
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.<br />
<br />
Implementation of the above constraint network in the BRL-CAD system, involves 3 fundamental aspects.<br />
<br />
# Domain extraction<br />
# Solution<br />
# Geometry updation<br />
<br />
Prerequisites for such a state is of course<br />
<br />
# "Handle" generation and storage<br />
# Updated geometry storage<br />
<br />
A typical constraint solution operation is shown below.<br />
<br />
==Object Architecture==<br />
<br />
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.<br />
[[Image:LibpgObjectArch.png|600px|Object Architecture Image]]<br />
<br />
===Parametric Geometric Objects===<br />
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.<br />
===Constraint Objects===<br />
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 )<br />
<br />
<br />
==Integration with librt==<br />
<br />
Two major aspects of integration with librt are<br />
# Database I/O<br />
# Declaration/ Extraction of parameters/variables from respective rt_*_internal structures<br />
<br />
Since most of the database input-output presently is completely handled by librt, it is expedient to use the same convention for writing the new non-geometric constraint object to the database. This is achieved through the pc_constraint_export and pc_constraint_import functions which are called by such functions as wdb_export or rt_db_put_internal via a new functab entry in table.c<br />
Or in more detail the steps taken to achieve these are<br />
<br />
# Definition of ID_CONSTRAINT (39) in raytrace.h ( corresponding increment to ID_MAXIMUM)<br />
# Creation of a corresponding entry to functab array in table.c<br />
# Addition of pc_constraint_export,pc_constraint_import and pc_constraint_ifree functions<br />
<br />
Regarding the declaration or extraction of parameters, the method of approach is to use a callback function rt_functab. Associated with each existing element<br />
we add a rt_*_params function which is called via the functab. This would declare the list of parameters it is built on as well as the list of implicit constraints on these parameters if any ( for example in the case of an ellipse<br />
there are 4 parameters: 1 point - center, 3 vectors-a,b,c and associated constraints ). This data is stored as a pc_pc_set (ParameterConstraint Set)<br />
This way, after the implementation of libpc we can remove most of the code from existing rt_*_prep functions which do such implicit constraint checking handling the same via libpc<br />
<br />
#Addition of rt_*_params to the RT_DECLARE_INTERFACE macro in table.c<br />
#Addition to the functab table in table.c<br />
#Definition of corresponding function is various primitives/*.c files<br />
<br />
'''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] ?'''<br />
<br />
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? )<br />
<br />
==Evaluation System==<br />
<br />
June 10th: The idea is to implement a constraint network using graph representation of boost c++ library. From the solvers point of view the constraint network would be composed of the following ( which are class definitions in pc_solver.h file)<br />
<br />
* Constraint Network: A Graph composed of vertices being parameters and edges being constraint relations. The difference from the normal graph is in the sense that an edge (or hyperedge ) maybe connecting more than two vertices.<br />
** Parameter Object: Vertex of the graph:<br />
*** Pointers to various constraints it is connected to<br />
** Constraint Object: Edge/Hyperedge of the graph - Relation between parameters<br />
*** Pointers to the parameters int the particular relation<br />
*** Relation : Basic representation of the relationship<br />
**** Relation Stack : The stack based representation of the relationship<br />
<br />
The action of the Solver object/method is the production of a Solution Class<br />
A Solution is basically an instantiation of parameters along with their possible values or an instantiation of the form<br />
( param1= value, param2=value and so on)<br />
In this case the value is basically a region of the domain the parameter could occupy.<br />
<br />
<br />
=== Treatment of domain of parameters=== <br />
<br />
# 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 )<br />
# Option B: Utilization of a Domain class which basically is dynamic array of individual domains ( by individual domain I imply a [min,max] region )<br />
<br />
===Transfer of data from database to solver===<br />
Modus operandi:<br />
# Import data and create pc_pc_set using rt_*_params functions via rt_functab<br />
# Run a domain extractor on the constraint objects in pc_set<br />
# Generate the constraint network<br />
# Call Solver<br />
<br />
<br />
Initial draft/intent<br />
<br />
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.<br />
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.<br />
<br />
<br />
==Enumeration of Parameters and Constraints==<br />
''Various standard methods of parametrics and constraints available in CAD Programs ( CATIA as a case study )''<br />
===Parametrics===<br />
#Point<br />
##Coordinates<br />
##On Curve<br />
##On Plane<br />
##On Surface<br />
##Circle/Sphere Centre<br />
##Tangent on Curve<br />
##Between (2 points)<br />
##Extremum<br />
##Extremum Polar<br />
#Line<br />
##Point-Point<br />
##Point-Direction<br />
##Angle/Normal to the curve<br />
##Tangent to the Curve<br />
##Normal to the surface<br />
##Bisecting<br />
#Plane<br />
##Offset from plane<br />
##Parallel through Point<br />
##Angle/Normal to Plane<br />
##Three points<br />
##Two Lines<br />
##Point and Line<br />
##Planar Curve<br />
##Normal to Curve<br />
##Tangent to Surface<br />
##Equation<br />
##Mean through points<br />
#Axis<br />
#Polyline<br />
#Circle<br />
#Corner<br />
#Connect Curve<br />
#Conic<br />
#Spline<br />
#Helix<br />
#Spiral<br />
<br />
===Constraints===<br />
#Distance<br />
#Length<br />
#Angle<br />
#Radius/Diameter<br />
#Semimajor axis<br />
#Semiminor axis<br />
#Symmetry<br />
#Midpoint<br />
#Equidistant point<br />
#Fix<br />
#Coincidence<br />
#Cocentricity<br />
#Tangency<br />
#Parallelism<br />
#Perpendicular<br />
#Horizontal<br />
#Vertical<br />
#Angle with axis<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability===</div>203.110.245.32https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=583Libpg : A parametrics/constraint library2008-06-13T00:28:21Z<p>203.110.245.32: /* libpg : A parametrics/ constraint library */</p>
<hr />
<div>{{DesignDocument}}<br />
<br />
= libpg : A parametrics/ constraint library =<br />
<br />
Proposed sytem for parametrics and constraint implementation<br />
by Dawn Thomas (homovulgaris)<br />
<br />
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)<br />
<br />
==Function==<br />
libpg adds the following provisions to BRL-CAD system<br />
<br />
# Creation & Modification of parameter-based geometry objects<br />
# Creation of constraints between geometry objects<br />
# Creation & Storage of Parametric Objects (non-geometric)<br />
# Modification of geometry objects in .g files to indicate parametric nature<br />
<br />
Part 1 would include building parametric objects based on existing non-parametric geometry objects as well as generation of purely parametric geometry. libpg<br />
acts as a library which sits above librt using the librt methods for creation and modification of geometry<br />
<br />
<br />
==Architecture==<br />
<br />
A constraint system can be looked upon as a system of variables, their associated domains and set of constraints/relationships between the variables.<br />
<br />
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.<br />
<br />
Implementation of the above constraint network in the BRL-CAD system, involves 3 fundamental aspects.<br />
<br />
# Domain extraction<br />
# Solution<br />
# Geometry updation<br />
<br />
Prerequisites for such a state is of course<br />
<br />
# "Handle" generation and storage<br />
# Updated geometry storage<br />
<br />
A typical constraint solution operation is shown below.<br />
<br />
==Object Architecture==<br />
<br />
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.<br />
[[Image:LibpgObjectArch.png|600px|Object Architecture Image]]<br />
<br />
===Parametric Geometric Objects===<br />
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.<br />
===Constraint Objects===<br />
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 )<br />
<br />
<br />
==Integration with librt==<br />
<br />
Two major aspects of integration with librt are<br />
# Database I/O<br />
# Declaration/ Extraction of parameters/variables from respective rt_*_internal structures<br />
<br />
Since most of the database input-output presently is completely handled by librt, it is expedient to use the same convention for writing the new non-geometric constraint object to the database. This is achieved through the pc_constraint_export and pc_constraint_import functions which are called by such functions as wdb_export or rt_db_put_internal via a new functab entry in table.c<br />
Or in more detail the steps taken to achieve these are<br />
<br />
# Definition of ID_CONSTRAINT (39) in raytrace.h ( corresponding increment to ID_MAXIMUM)<br />
# Creation of a corresponding entry to functab array in table.c<br />
# Addition of pc_constraint_export,pc_constraint_import and pc_constraint_ifree functions<br />
<br />
Regarding the declaration or extraction of parameters, the method of approach is to use a callback function rt_functab. Associated with each existing element<br />
we add a rt_*_params function which is called via the functab. This would declare the list of parameters it is built on as well as the list of implicit constraints on these parameters if any ( for example in the case of an ellipse<br />
there are 4 parameters: 1 point - center, 3 vectors-a,b,c and associated constraints ). This data is stored as a pc_pc_set (ParameterConstraint Set)<br />
This way, after the implementation of libpc we can remove most of the code from existing rt_*_prep functions which do such implicit constraint checking handling the same via libpc<br />
<br />
#Addition of rt_*_params to the RT_DECLARE_INTERFACE macro in table.c<br />
#Addition to the functab table in table.c<br />
#Definition of corresponding function is various primitives/*.c files<br />
<br />
'''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] ?'''<br />
<br />
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? )<br />
<br />
==Evaluation System==<br />
<br />
June 10th: The idea is to implement a constraint network using graph representation of boost c++ library. From the solvers point of view the constraint network would be composed of the following ( which are class definitions in pc_solver.h file)<br />
<br />
* Constraint Network: A Graph composed of vertices being parameters and edges being constraint relations. The difference from the normal graph is in the sense that an edge (or hyperedge ) maybe connecting more than two vertices.<br />
** Parameter Object: Vertex of the graph:<br />
*** Pointers to various constraints it is connected to<br />
** Constraint Object: Edge/Hyperedge of the graph - Relation between parameters<br />
*** Pointers to the parameters int the particular relation<br />
*** Relation : Basic representation of the relationship<br />
**** Relation Stack : The stack based representation of the relationship<br />
<br />
The action of the Solver object/method is the production of a Solution Class<br />
A Solution is basically an instantiation of parameters along with their possible values or an instantiation of the form<br />
( param1= value, param2=value and so on)<br />
In this case the value is basically a region of the domain the parameter could occupy.<br />
<br />
<br />
=== Treatment of domain of parameters=== <br />
<br />
# 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 )<br />
# Option B: Utilization of a Domain class which basically is dynamic array of individual domains ( by individual domain I imply a [min,max] region )<br />
<br />
For example <br />
consider parameter set p1,p2,p3<br />
The solution maybe<br />
#(p1, 0.5-1.5; p2, 0.2) : P3 can have any value if P2 =0.2 and P1 lies in the range [0.1,1.5]<br />
#(p1, 1.8; p2, 0.3-0.8; p3, 0.3-0.9) : P1=1.8, and P2 lies in the range [0.3,0.8] and P3 in the range [0.3,0.9]<br />
#(p1, 2.3; p2, 2.2; p3, 1.4) : Unique solution P1=2.3, P2=2.2, P3=1.4<br />
<br />
<br />
===Transfer of data from database to solver===<br />
Modus operandi:<br />
# Import data and create pc_pc_set using rt_*_params functions via rt_functab<br />
# Run a domain extractor on the constraint objects in pc_set<br />
# Generate the constraint network<br />
# Call Solver<br />
<br />
<br />
Initial draft/intent<br />
<br />
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.<br />
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.<br />
<br />
<br />
==Enumeration of Parameters and Constraints==<br />
''Various standard methods of parametrics and constraints available in CAD Programs ( CATIA as a case study )''<br />
===Parametrics===<br />
#Point<br />
##Coordinates<br />
##On Curve<br />
##On Plane<br />
##On Surface<br />
##Circle/Sphere Centre<br />
##Tangent on Curve<br />
##Between (2 points)<br />
##Extremum<br />
##Extremum Polar<br />
#Line<br />
##Point-Point<br />
##Point-Direction<br />
##Angle/Normal to the curve<br />
##Tangent to the Curve<br />
##Normal to the surface<br />
##Bisecting<br />
#Plane<br />
##Offset from plane<br />
##Parallel through Point<br />
##Angle/Normal to Plane<br />
##Three points<br />
##Two Lines<br />
##Point and Line<br />
##Planar Curve<br />
##Normal to Curve<br />
##Tangent to Surface<br />
##Equation<br />
##Mean through points<br />
#Axis<br />
#Polyline<br />
#Circle<br />
#Corner<br />
#Connect Curve<br />
#Conic<br />
#Spline<br />
#Helix<br />
#Spiral<br />
<br />
===Constraints===<br />
#Distance<br />
#Length<br />
#Angle<br />
#Radius/Diameter<br />
#Semimajor axis<br />
#Semiminor axis<br />
#Symmetry<br />
#Midpoint<br />
#Equidistant point<br />
#Fix<br />
#Coincidence<br />
#Cocentricity<br />
#Tangency<br />
#Parallelism<br />
#Perpendicular<br />
#Horizontal<br />
#Vertical<br />
#Angle with axis<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability===</div>203.110.245.32https://brlcad.org/w/index.php?title=Google_Summer_of_Code/2008&diff=565Google Summer of Code/20082008-05-31T11:20:37Z<p>203.110.245.32: /* Parametric Equations and Constraint Support */</p>
<hr />
<div>After a detailed [[Google_Summer_of_Code/Proposal_Evaluation|evaluation and review]] period, we requested and were approved to mentor four students for the 2008 Google Summer of Code. Our students were selected from among nearly two dozen applicants based on their potential as a new long-term developer, their ability to communicate effectively, the quality of their project proposal, their technical ability, and our ability to effectively mentor them.<br />
<br />
= Student selections =<br />
<br />
It was a competitive selection process with several great applicants that had to be turned away but in the end, our four selections were made. Thanks go out to all of our applicants, and I hope to see many of them stay involved in BRL-CAD development regardless of GSoC. That's one of the many perks of being an open source project -- the door is always open for new contributors. Thanks are also deserved to all our available mentors and backup mentors that did a great job of weighing the pros and cons of each proposal, interacting with the candidates, making the difficult decisions, and ultimately choosing an exciting mix of students and projects for GSoC 2008. That said and without further adieu, I'm happy to announce our four selected students and their accepted projects:<br />
<br />
==Timothy Van Ruitenbeek==<br />
===Implementing Solid of Revolution and Sweep Primitives===<br />
<br />
:Mentored by Daniel Roßberg, Timothy's project aims to implement two primitives that have been requested numerous times over the years: sweep and revolve. These two primitives provide a wide range of modeling benefits including the ability to express various complex shapes more intuitively and easily. Such shapes that will become readily possible to construct include lathe shapes, cables, blends, carved shapes, and much more.<br />
:*Design document for [[Revolve Primitive]]<br />
:*[[User:Pacman87|Development log]]<br />
<br />
==André Castelo Branco Gomes==<br />
===Global Illumination Renderer using Metropolis Light Transport and LIBRT===<br />
<br />
:Mentored by Erik Greenwald, André's project involves implementing a new global illumination renderer using BRL-CAD's existing LIBRT ray-trace library. This rendering technique provides highly realistic image synthesis (pretty pictures!) through a variant of the Monte-carlo method and bidirectional path tracing. This will make it much easier to generate beautiful detailed renderings of any BRL-CAD geometry without requiring polygonal tessellation.<br />
:*Design document for [[Metropolis Light Transport]]<br />
<br />
==Dawn Thomas==<br />
===Parametric Equations and Constraint Support===<br />
<br />
:Mentored by John Anderson, Dawn's project is a highly ambitious effort that aims to provide constraints and parametric equation support for BRL-CAD geometry. Parametric constraints allows geometry to be described in very powerful and expressive ways including constructing geometry that preserves tangency, stays aligned through complex transformations, maintains relative dimensions, resolves dependent articulations, and more.<br />
:*Design document for [[Libpg_:_A_parametrics/constraint_library|Libpg]]<br />
:*Development Log : [http://parametrics.wordpress.com/ Parametrics]<br />
<br />
==Manuel Antonio Fernandez Montecelo==<br />
===New GUI Framework for Modeling and Visualization===<br />
<br />
:Mentored by Bob Parker, Manuel's project is the start of a new graphical user interface (GUI) for visualizing, manipulating, and managing BRL-CAD geometry. This interface serves as a solid framework for improving BRL-CAD's usability by providing support for shaded displays, scene graph management, and more. This thin client is the start of a new user interface that will focus on usability, efficiency, scalability, and the human-computer interaction.<br />
<br />
:*Design document for [[OpenGL GUI Framework]]<br />
:*[[User:mafm|Development log]]<br />
<br />
= Getting started =<br />
<br />
Students participating with BRL-CAD in the 2008 GSoC have a '''[[Google_Summer_of_Code/Checklist|checklist]]''' of actions to attend to before getting started on their projects. They are also expected to be aware of what is '''[[Google_Summer_of_Code/Expectations|expected of them]]''' throughout the summer. <br />
<br />
= Additional Information =<br />
<br />
This year, more than 7000 applications were received from nearly 4000 students for the 175 participating organizations. Of those, only 1125 applications/students will be funded. Altogether, this represents a $5.6 million dollar (USD) investment by Google in open source software development. Way cool.<br />
<br />
You can see our [[Google_Summer_of_Code/Project_Ideas|Project Ideas]] page for a list of project suggestions that were suggested to be of particular interest to our mentors for 2008. There were several [http://brlcad.org/~sean/ideas.html other areas] of development that are of high-interest as well. Students were welcome to submit their own unique ideas as well and were encouraged to collaborate with our mentors on formulating those projects. Student applications for GSoC 2008 were accepted on Google's project website between March 24 and March 31 at http://code.google.com/soc/2008/</div>203.110.245.32