https://brlcad.org/w/api.php?action=feedcontributions&user=Homovulgaris&feedformat=atom
BRL-CAD - User contributions [en]
2020-03-31T23:04:53Z
User contributions
MediaWiki 1.32.2
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1500
User:Homovulgaris
2009-06-21T08:47:39Z
<p>Homovulgaris: /* GSoC 2009 Log */ 19th June update</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
* Enrolled in PostGraduate Program at Indian Institute of Management, Bangalore.<br />
* Bachelors in Architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoC 2009 Log ==<br />
<br />
=== 2009.06.20 ===<br />
* code added to cc command to add an empty rt_constraint object to the database<br />
<br />
=== 2009.06.18 ===<br />
* cc (create constraint) framework added<br />
<br />
=== 2009.06.17 ===<br />
* lscon command framework added to libged<br />
<br />
=== till 2009.06.17 ===<br />
* Expression grammar defined<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~230 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~75 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for the entire framework (~90 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives as well as the testing of the entire framework spread throughout the development process. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.) The estimate for testing is approximately at the rate of 1 day of work per week.<br />
<br />
===Schedule and Status===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint (ongoing)<br />
** edit constraint<br />
** display constraint (ongoing)<br />
* Finalizing Constraint grammar<br />
* Test of the creation and display<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
<br />
* libged commands<br />
** solve<br />
** select solution<br />
* Complete Solver work<br />
* Test the solve/ select solution use-cases<br />
* Further overall testing ** <br />
* librt rt_prep checks transition to libpc**<br />
<br />
** if ahead of schedule at mid-term analysis<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1496
User:Homovulgaris
2009-06-19T09:40:38Z
<p>Homovulgaris: /* Schedule */ adding Status</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
* Enrolled in PostGraduate Program at Indian Institute of Management, Bangalore.<br />
* Bachelors in Architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoC 2009 Log ==<br />
<br />
=== 2009.06.18 ===<br />
* cc (create constraint) framework added<br />
<br />
=== 2009.06.17 ===<br />
* lscon command framework added to libged<br />
<br />
=== till 2009.06.17 ===<br />
* Expression grammar defined<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~230 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~75 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for the entire framework (~90 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives as well as the testing of the entire framework spread throughout the development process. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.) The estimate for testing is approximately at the rate of 1 day of work per week.<br />
<br />
===Schedule and Status===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint (ongoing)<br />
** edit constraint<br />
** display constraint (ongoing)<br />
* Finalizing Constraint grammar<br />
* Test of the creation and display<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
<br />
* libged commands<br />
** solve<br />
** select solution<br />
* Complete Solver work<br />
* Test the solve/ select solution use-cases<br />
* Further overall testing ** <br />
* librt rt_prep checks transition to libpc**<br />
<br />
** if ahead of schedule at mid-term analysis<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1495
User:Homovulgaris
2009-06-19T09:38:16Z
<p>Homovulgaris: /* GSoC 2009 Log */ 18th June update</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
* Enrolled in PostGraduate Program at Indian Institute of Management, Bangalore.<br />
* Bachelors in Architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoC 2009 Log ==<br />
<br />
=== 2009.06.18 ===<br />
* cc (create constraint) framework added<br />
<br />
=== 2009.06.17 ===<br />
* lscon command framework added to libged<br />
<br />
=== till 2009.06.17 ===<br />
* Expression grammar defined<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~230 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~75 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for the entire framework (~90 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives as well as the testing of the entire framework spread throughout the development process. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.) The estimate for testing is approximately at the rate of 1 day of work per week.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** display constraint<br />
* Finalizing Constraint grammar<br />
* Test of the creation and display<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
<br />
* libged commands<br />
** solve<br />
** select solution<br />
* Complete Solver work<br />
* Test the solve/ select solution use-cases<br />
* Further overall testing ** <br />
* librt rt_prep checks transition to libpc**<br />
<br />
** if ahead of schedule at mid-term analysis<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1489
User:Homovulgaris
2009-06-18T14:15:27Z
<p>Homovulgaris: log added, bio updated</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
* Enrolled in PostGraduate Program at Indian Institute of Management, Bangalore.<br />
* Bachelors in Architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoC 2009 Log ==<br />
<br />
=== 2009.06.17 ===<br />
* lscon command framework added to libged<br />
<br />
=== till 2009.06.17 ===<br />
* Expression grammar defined<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~230 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~75 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for the entire framework (~90 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives as well as the testing of the entire framework spread throughout the development process. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.) The estimate for testing is approximately at the rate of 1 day of work per week.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** display constraint<br />
* Finalizing Constraint grammar<br />
* Test of the creation and display<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
<br />
* libged commands<br />
** solve<br />
** select solution<br />
* Complete Solver work<br />
* Test the solve/ select solution use-cases<br />
* Further overall testing ** <br />
* librt rt_prep checks transition to libpc**<br />
<br />
** if ahead of schedule at mid-term analysis<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1381
User:Homovulgaris
2009-04-08T22:57:19Z
<p>Homovulgaris: /* Schedule */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~230 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~75 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for the entire framework (~90 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives as well as the testing of the entire framework spread throughout the development process. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.) The estimate for testing is approximately at the rate of 1 day of work per week.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** display constraint<br />
* Finalizing Constraint grammar<br />
* Test of the creation and display<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
<br />
* libged commands<br />
** solve<br />
** select solution<br />
* Complete Solver work<br />
* Test the solve/ select solution use-cases<br />
* Further overall testing ** <br />
* librt rt_prep checks transition to libpc**<br />
<br />
** if ahead of schedule at mid-term analysis<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1380
User:Homovulgaris
2009-04-08T22:47:03Z
<p>Homovulgaris: /* Proposal */ time for libged integration increased by 65 %</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~230 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~75 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for the entire framework (~90 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives as well as the testing of the entire framework spread throughout the development process. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.) The estimate for testing is approximately at the rate of 1 day of work per week.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** solve<br />
** display constraint<br />
** select solution<br />
* Finalizing Constraint grammar<br />
* Initiate solver work<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
* Complete Solver work<br />
* Work on Implicit Constraints<br />
* Test Explicit Constraints / Final Test<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1379
User:Homovulgaris
2009-04-08T22:38:56Z
<p>Homovulgaris: /* Abstract */ scaling down</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
#Testing of the framework throughout<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~140 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~85 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for Implicit Constraints (~100 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.)<br />
<br />
'''5. Final Test: Testing the Overall Framework (~60 hours)'''<br />
<br />
With the wrapping up of Math Virtual Machine and grammar, this work is effectively the test of the entire framework and would involve purely construction of test cases. Since this is an iterative process involving incremental tests of each aspect finally culminating in the entire framework test at the end, the estimate of time is rather rough.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** solve<br />
** display constraint<br />
** select solution<br />
* Finalizing Constraint grammar<br />
* Initiate solver work<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
* Complete Solver work<br />
* Work on Implicit Constraints<br />
* Test Explicit Constraints / Final Test<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1326
User:Homovulgaris
2009-04-01T16:22:46Z
<p>Homovulgaris: Text shifted to Notes since priorities have been changed</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
# Writing implicit constraints for the primitives : Using libpc for the rt_prep checks.<br />
# Final Test: Testing explicit constraints which would involve checking the list of commands to be implemented by the proposal thereby resulting in a complete test of the framework.<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~140 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~85 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for Implicit Constraints (~100 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.)<br />
<br />
'''5. Final Test: Testing the Overall Framework (~60 hours)'''<br />
<br />
With the wrapping up of Math Virtual Machine and grammar, this work is effectively the test of the entire framework and would involve purely construction of test cases. Since this is an iterative process involving incremental tests of each aspect finally culminating in the entire framework test at the end, the estimate of time is rather rough.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** solve<br />
** display constraint<br />
** select solution<br />
* Finalizing Constraint grammar<br />
* Initiate solver work<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
* Complete Solver work<br />
* Work on Implicit Constraints<br />
* Test Explicit Constraints / Final Test<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
* In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1325
User:Homovulgaris
2009-04-01T16:19:15Z
<p>Homovulgaris: /* Other Notes */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
# Writing implicit constraints for the primitives : Using libpc for the rt_prep checks.<br />
# Final Test: Testing explicit constraints which would involve checking the list of commands to be implemented by the proposal thereby resulting in a complete test of the framework.<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~140 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~85 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for Implicit Constraints (~100 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.)<br />
<br />
'''5. Final Test: Testing the Overall Framework (~60 hours)'''<br />
<br />
With the wrapping up of Math Virtual Machine and grammar, this work is effectively the test of the entire framework and would involve purely construction of test cases. Since this is an iterative process involving incremental tests of each aspect finally culminating in the entire framework test at the end, the estimate of time is rather rough.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** solve<br />
** display constraint<br />
** select solution<br />
* Finalizing Constraint grammar<br />
* Initiate solver work<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
* Complete Solver work<br />
* Work on Implicit Constraints<br />
* Test Explicit Constraints / Final Test<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
* Some tinkering is also needed to make the existing code more modular.<br />
* There is also a "small" memory leak in the solver which needs to be taken care of.<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1324
User:Homovulgaris
2009-04-01T16:18:07Z
<p>Homovulgaris: /* Schedule */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
# Writing implicit constraints for the primitives : Using libpc for the rt_prep checks.<br />
# Final Test: Testing explicit constraints which would involve checking the list of commands to be implemented by the proposal thereby resulting in a complete test of the framework.<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~140 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~85 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for Implicit Constraints (~100 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.)<br />
<br />
'''5. Final Test: Testing the Overall Framework (~60 hours)'''<br />
<br />
With the wrapping up of Math Virtual Machine and grammar, this work is effectively the test of the entire framework and would involve purely construction of test cases. Since this is an iterative process involving incremental tests of each aspect finally culminating in the entire framework test at the end, the estimate of time is rather rough.<br />
<br />
===Schedule===<br />
<br />
'''Pre GSoC'''<br />
* Math VM/ Grammar completion<br />
* Documentation Overhaul<br />
* Do further groundwork on Solver<br />
* Finalize expected commands, argument set and output<br />
<br />
'''May 23 - July 6 (~ 6 weeks)'''<br />
<br />
* libged commands<br />
** create constraint<br />
** edit constraint<br />
** solve<br />
** display constraint<br />
** select solution<br />
* Finalizing Constraint grammar<br />
* Initiate solver work<br />
<br />
'''July 6 - August 10 (~ 5 weeks)'''<br />
* Complete Solver work<br />
* Work on Implicit Constraints<br />
* Test Explicit Constraints / Final Test<br />
<br />
'''Post GSoC'''<br />
* Add further commands to the ui<br />
* Improve solver(s)<br />
* Increase the number of "available/hard-coded" constraint types<br />
* Improve the solution display / selection system ?<br />
<br />
===Other Notes===<br />
There are many aspects of libpc which I have not taken into consideration in this proposal , for instance the integration with libged so that the whole system becomes accessible to the end user. But I believe the above mentioned aspects need to be taken care of first for any progress.<br />
Considering my last year experience, I still think this is probably a little more than what I should really aim for.<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=1323
User:Homovulgaris
2009-04-01T16:08:29Z
<p>Homovulgaris: /* Proposal */ change of priorities</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
== GSoc 2009 Proposal Draft ==<br />
<br />
===Abstract===<br />
<br />
Continuing with the libpc work from last gsoc, the proposal is for providing the following functionalities in mged/libged for the end-user<br />
<br />
# creation/modification of constraint objects<br />
# a solve command for solving a set of constraints / all the constraints in the loaded .g file<br />
# options for selection from a range of solutions if possible<br />
<br />
for achieving the same, the work falls under the following heads<br />
<br />
# An inclusive definition of constraint grammar on the basis of the existing Math grammar which can be easily extened later.<br />
#Integration with libged - framework for calls into librt and libpc for solution, storage and updation.<br />
# Writing a robust modular constraint solver<br />
# Writing implicit constraints for the primitives : Using libpc for the rt_prep checks.<br />
# Final Test: Testing explicit constraints which would involve checking the list of commands to be implemented by the proposal thereby resulting in a complete test of the framework.<br />
<br />
===Proposal===<br />
<br />
The status of libpc project as of now is as follows.<br />
<br />
# Abstraction Framework - Objects implemented : Parameters, Variables and Constraints, Constraint Network<br />
# Solution System - Generic solver testing all possible variable assignment combinations, Graph specific solver using boost graph library<br />
# Math Virtual Machine (work in progress) - expected to be complete with around 400 to 500 lines of code change at max.<br />
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized<br />
<br />
In the long run, I am sure that the rigor of the solver would be the major factor in terms of usability as well as performance. Even though I have been toying around with some generic constraint solvers as well as geometric ones, I haven't found one which could be easily integrated into brl-cad. The ideal approach would be to make the solver an independent module. This would not only support using multiple solvers by using the same "protocol or format", but also simplify the process of progress in terms of solver optimizations.<br />
<br />
Project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows.<br />
<br />
<br />
'''1. Constraint grammar (~90 hours)'''<br />
<br />
This would be dependent on the underlying Math grammar system. Testing out the grammar system would include correct parsing of expressions implying the constraints into the constraint objects.<br />
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables)<br />
<br />
'''2. Integration with libged/librt (~140 hours)'''<br />
<br />
The purpose is to create adequate commands for the creation and modification of constraint objects and their "solving". libged would interface with the user and the already existing code and its modification will provide database I/O. This work can be done along with the development of the constraint grammar work mentioned above since both are in a way interdepedent.<br />
<br />
<br />
'''3. Solution system (~85 hours)'''<br />
<br />
Undoubtedly the most important aspect of the constraint system. Two approaches can be taken for modularity of the solver from other parts of libpc. One way would be to use a server-client model possibly using inter-process communication or a simple file based transfer of data between the two. Alternatively it could be a part of the libpc library itself requiring a particular format of the constraint satisfaction problem. This could be passed on to the solver as string data or as a data structure. Of the various approaches towards solving geometrical constraints, I am slightly in favour of graph-constructive methods over the others (see #1) But eventually I think something like a Locus Intersection method (#4) which is a hybrid between the computational and search approaches would be ideal. One of the reasons I feel that the solver should be completely independent of the constraint satisfaction problem definition or representation is the fact that it is a field rapidly undergoing changes in terms of new approaches. The priority of course is for the creation of a basic overall framework that is user accessible rather than an extremely fine tuned solver. Depending on the rapidity with which libged progresses, more time can be alloted for this job over the other heads mentioned.<br />
<br />
'''4. Test Use-cases for Implicit Constraints (~100 hours)'''<br />
<br />
This involves using the libpc framework for doing the rt_prep checks for each of the geometry primitives. This work can be pursued independent of the work on the solution system , using the existing generic solver. Also in terms of implementation this would be a good start to finalize the common type of constraints grammar wise ( parallelism, perpendicularity etc.)<br />
<br />
'''5. Final Test: Testing the Overall Framework (~60 hours)'''<br />
<br />
With the wrapping up of Math Virtual Machine and grammar, this work is effectively the test of the entire framework and would involve purely construction of test cases. Since this is an iterative process involving incremental tests of each aspect finally culminating in the entire framework test at the end, the estimate of time is rather rough.<br />
<br />
===Schedule===<br />
<br />
May 23 - July 6 (~ 6 weeks)<br />
* Do further groundwork on Solver<br />
* Finalising Constraint grammar<br />
* Work on Implicit Constraints<br />
* Initial solver work<br />
July 6 - August 10 (~ 5 weeks)<br />
* Complete Solver work<br />
* Test Explicit Constraints<br />
<br />
===Other Notes===<br />
There are many aspects of libpc which I have not taken into consideration in this proposal , for instance the integration with libged so that the whole system becomes accessible to the end user. But I believe the above mentioned aspects need to be taken care of first for any progress.<br />
Considering my last year experience, I still think this is probably a little more than what I should really aim for.<br />
<br />
===References===<br />
[http://www.cs.purdue.edu/research/technical_reports/1993/TR%2093-054.pdf] A geometric Constraint Solver, W Bouma, I Fudos, C Hoffmann, J Cai, R Paige - Computer Aided Design, 1995<br />
<br />
<br />
[http://portal.acm.org/citation.cfm?id=502348.502362] A Modular Geometric Constraint Solver for User Interface Applications, Hiroshi Hosobe , ACM symposium on User interface software and technology, 2001<br />
<br />
<br />
[http://eprints.kfupm.edu.sa/65700/] Solving geometric constraint systems, GA Kramer, BB Qh - 1992]<br />
<br />
[http://dx.doi.org/] Solving spatial basic geometric constraint configurations with locus intersection, XS Gao, CM Hoffmann, WQ Yang - Computer-Aided Design, 2004 - Elsevier doi:10.1016/S0010-4485(03)00056-3</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpc&diff=1313
Libpc
2009-03-28T12:34:06Z
<p>Homovulgaris: /* Structure */</p>
<hr />
<div>{{DesignDocument}}<br />
==libpc: Introduction==<br />
==Objectives==<br />
<br />
<br />
The objectives encompassed by libpc are the following<br />
<br />
*'''Front-end'''<br />
#An Abstraction of Parameters over the present components of primitives<br />
#Representation of complex (see examples) constraints between Parameters<br />
#Framework for selection of Design/Alternative Configurations<br />
<br />
*'''Back-end'''<br />
#Fast Geometric Constraint Solution<br />
<br />
===Advantages===<br />
<br />
#Reduction of Modeling time in case of Iterative designs<br />
#Logic of Design represented in the geometry file itself<br />
#Capability for complex geometry generation<br />
<br />
==Constraint Satisfaction Process==<br />
==Possible Approaches in BRL-CAD==<br />
==Structure==<br />
<br />
libpc is composed of the following modules<br />
<br />
#Reprsentation of Parameters and Constraints in Storage<br />
#Representation of Parameters in Memory<br />
#Representation of Constraints in Memory / DataStructure<br />
## Associated MathGrammar and MathVM<br />
#Generation of 2 and 3 from 1<br />
#Solution System<br />
##Constraint Network Generation from 4<br />
##Constraint Satisfaction<br />
#Parameter and Geometry updation<br />
<br />
===Overall Hierarchy===<br />
===Libpc Hierarchy===<br />
===Object Hierarchy===<br />
<br />
==Use-case Scenarios==</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpc&diff=1312
Libpc
2009-03-28T12:09:48Z
<p>Homovulgaris: /* Objectives */</p>
<hr />
<div>{{DesignDocument}}<br />
==libpc: Introduction==<br />
==Objectives==<br />
<br />
<br />
The objectives encompassed by libpc are the following<br />
<br />
*'''Front-end'''<br />
#An Abstraction of Parameters over the present components of primitives<br />
#Representation of complex (see examples) constraints between Parameters<br />
#Framework for selection of Design/Alternative Configurations<br />
<br />
*'''Back-end'''<br />
#Fast Geometric Constraint Solution<br />
<br />
===Advantages===<br />
<br />
#Reduction of Modeling time in case of Iterative designs<br />
#Logic of Design represented in the geometry file itself<br />
#Capability for complex geometry generation<br />
<br />
==Constraint Satisfaction Process==<br />
==Possible Approaches in BRL-CAD==<br />
==Structure==<br />
===Overall Hierarchy===<br />
===Libpc Hierarchy===<br />
===Object Hierarchy===<br />
==Use-case Scenarios==</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Developer_Documents&diff=1292
Developer Documents
2009-03-25T08:22:48Z
<p>Homovulgaris: /* Development Projects */</p>
<hr />
<div>= Development Projects =<br />
<br />
* [[libpg : A parametrics/constraint library]] (old documentation)<br />
* [[libpc | libpc : Geometric Constraint Solving]]<br />
* [[Revolve Primitive]]<br />
* [[OpenGL GUI Framework]]<br />
* [[Metropolis_Light_Transport|Global Illumination using Metropolis Light Transport]]<br />
* [[Geometry Service]]<br />
* [[BRL-CAD's core C++ interface]]<br />
* [[A find Command for BRL-CAD geometry]]<br />
<br />
= Developer FAQ =<br />
<br />
== I'm interested in BRL-CAD development. How can I get involved? ==<br />
<br />
* Join the [http://irc.brlcad.org/ IRC channel] and/or the [http://lists.sourceforge.net/lists/listinfo/brlcad-devel developer mailing list]<br />
* Read the [https://brlcad.svn.sourceforge.net/viewvc/*checkout*/brlcad/brlcad/trunk/HACKING developer's guide]<br />
* Start [http://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804 submitting patches]<br />
<br />
== I'm trying to add a new file to the repository and I get an error on commit about mime types. What should I do? ==<br />
<br />
You should set the mime type. See [[mime-types]] for more information.<br />
<br />
= Developer Examples =<br />
<br />
* [[Example_db_walk_tree|Using db_walk_tree()]]</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpc&diff=1291
Libpc
2009-03-25T08:22:27Z
<p>Homovulgaris: Basic Structure</p>
<hr />
<div>{{DesignDocument}}<br />
==libpc: Introduction==<br />
==Objectives==<br />
==Constraint Satisfaction Process==<br />
==Possible Approaches in BRL-CAD==<br />
==Structure==<br />
===Overall Hierarchy===<br />
===Libpc Hierarchy===<br />
===Object Hierarchy===<br />
==Use-case Scenarios==</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Google_Summer_of_Code/2009/Project_Ideas&diff=1272
Google Summer of Code/2009/Project Ideas
2009-03-16T10:54:32Z
<p>Homovulgaris: /* Constraints and Parametrics */ Short Introduction added</p>
<hr />
<div>The list of possible projects below should serve as a good starting point for new developers that would like to get involved in working on BRL-CAD. The ideas below range from the very hard and math intense to the very easy, feel free to scale the scope of the project up or down as needed. The suggested project ideas below are merely starting points. In addition to those below, you may also want to consider some of [http://brlcad.org/~sean/ideas.html these ideas].<br />
<br />
A detailed articulate (i.e. excellent) proposal that has been discussed with us beforehand will generally trump the priorities. Please do [http://brlcad.org/d/contact contact us] if you have any questions, corrections, comments, or ideas of your own that you'd like to suggest.<br />
<br />
Be sure to read up on our [[Google Summer of Code|application process]] for getting started with your proposal submission if you have not done so already. <br />
<br />
<br />
= High Priority Projects =<br />
<br />
== <AN IDEA OF YOUR OWN> ==<br />
<br />
Do you have an idea of your own? Let us know and maybe we'll like it too. We're very open to new ideas, areas of academic research, industry applications, and any other ways that may help get you hooked on BRL-CAD development. Just remember that BRL-CAD is a solid modeling CAD suite so keep that in mind when scoping your project. The idea needs to fit in with our project goals, it needs to be specific, and it needs to be detailed.<br />
<br />
Requirements:<br />
<br />
*Passion for the task being suggested<br />
*Buy-in from one of the existing developers<br />
<br />
Difficulty: variable<br />
<br />
<br />
==OpenGL GUI Framework==<br />
<br />
This was a GSoC 2008 project. Talk to the developers before proposing this task to obtain project status.<br />
<br />
BRL-CAD includes a graphical solid modeler named MGED as well as an experimental refactoring named Archer, both written in Tcl/Tk. While MGED is extensively powerful in its modeling capabilities and is in production use, new users and developers usually expect something rather different. They expect and want an interface that doesn't require extensive training and expert knowledge before they can use it. A redesign of the modeling interface is under way and this project idea focuses on one piece of that effort, the front-end display.<br />
<br />
This project is necessarily a '''continuation and extension''' of the graphical application framework started in GSoC 2008 (not something completely new). Rather than reimplementing existing functionality, the framework needs to be an extendible plug-in-based client-server system that will utilize existing binaries and editing functionality available in BRL-CAD. More to the point, this task entails creating solidifying the GUI interactions and command framework. ''This is a high-priority topic.''<br />
<br />
See http://brlcad.org/design/gui/ioe_proto_final.mov for some background on an ''interaction'' prototype that was developed in relation to the new GUI.<br />
<br />
Requirements:<br />
<br />
*Strong knowledge of C++<br />
*Strong knowledge of object oriented design<br />
<br />
Difficulty: high<br />
<br />
<br />
==Object-oriented geometry engine API==<br />
<br />
BRL-CAD includes four libraries that provide the basis for our core geometry engine: libbu, libbn, librt, and libwdb. These libraries provide a C API to various geometry processing and ray-tracing capabilities. The focus of this idea is to provide an object-oriented API in either C++ or Java (or both, SWIG?) for those capabilities. The library should be designed such that it provides features similar to those found in other commercial geometry engines such as the ACIS or Granite engines, but designed with BRL-CAD's existing capabilities in mind. The API design should leverage as much of our C libraries as possible for the implementation approach. See our 'jbrlcad' module for an example (initial) structuring. ''This is a high-priority topic.''<br />
<br />
Requirements:<br />
<br />
*Strong familiarity with C<br />
*Strong familiarity with C++ or Java (or both)<br />
*Strong familiarity with object oriented API design<br />
*(optional) Familiarity with SWIG<br />
<br />
Difficulty: high<br />
<br />
<br />
== MGED User Interface Improvements ==<br />
<br />
Most users discovering BRL-CAD for the first time are usually introduced to MGED first. MGED, however, has always been considered an "expert interface" that requires substantial investment of time and effort to learn and use effectively. There are many enhancements to the interface that would improve usability and discoverability.<br />
<br />
The idea behind this task would be propose improvements to MGED's existing Tcl/Tk user interface implementation. Proposals could include usability improvements, platform-specific release integration (e.g., get AquaTk working), improving discoverability of features, refactoring the existing implementation, and more. The approach can be minimal, drastic, or incremental, but should be appropriately scoped and include detail. ''This is a high-priority topic.''<br />
<br />
Requirements:<br />
<br />
*Strong knowledge of Tcl/Tk<br />
*Usability and interface design experience<br />
*(optional) Familiarity with C<br />
<br />
Difficulty: low<br />
<br />
<br />
==CSG evaluation of Boundary Representations==<br />
<br />
One of the current primary BRL-CAD development efforts is the complete integration of hybrid model support. BRL-CAD leverages the Rhino openNURBS library to provide fundamental BREP support but there is still much work to be done to evaluate BREPs.<br />
<br />
These guys implemented something very similar although their implementation was not robust: http://www.cs.unc.edu/~geom/CSG/boole.html<br />
These guys followed that work and implemented a robust solution, but killed performance: http://www.cs.unc.edu/~geom/ESOLID/<br />
You will need to be very careful about tolerances and tolerance tracking without resorting to fixed-precision arithmetic.<br />
<br />
This task basically involves implementing BREP-on-BREP CSG evaluation routines (resulting in a new evaluated BREP object). If you get done fast enough, you could also work on implementing the routines that generate a BREP for all of our implicit primitives which would bring us one step closer towards providing complete dual-representation support. ''This is a high-priority topic.''<br />
<br />
Requirements:<br />
<br />
*Familiarity with C/C++<br />
*Strong math skills<br />
*Familiarity with CSG operations<br />
*Familiarity with BREP/n-Manifold spline surface geometry<br />
*(optional) Strong familiarity with implicit geometric representations<br />
<br />
Difficulty: high<br />
<br />
== CSG ray-trace optimizations ==<br />
<br />
BRL-CAD has one of the best high-performance CSG boolean evaluation engines anywhere, but we're always looking for ways to improve performance and accuracy. This task could consist of refactoring the LIBRT ray-trace library to fix a bug related to negative object segment detection (high-priority). This task could consist of implementing a high-performance generic CSG tree processing library providing transformations, tree contraction, null object detection, various traversals, cycle detection, etc and hooking that into LIBRT. Yet another approach could be to apply the same real-time ray-trace optimizations of exploiting cache coherency, branch minimization, data vectorization, accelerated spacial partitioning, and other optimization techniques. ''This is a high-priority topic.''<br />
<br />
Requirements:<br />
<br />
*Strong familiarity with C<br />
*Strong familiarity with CSG<br />
<br />
Difficulty: high<br />
<br />
<br />
==Constraints and Parametrics==<br />
<br />
This was a GSoC 2008 project. For more information about libpc(parametrics and constraints library) please check [[libpg : A parametrics/constraint library|libpc Developer Doc]] as well as the [http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libpc/ libpc source]. The work is effectively long-term considering the amount of work required. Talk to the developers before proposing this task to obtain project status.<br />
<br />
BRL-CAD does not presently provide the means to specify values that are undetermined or otherwise dependent calculations. That is to say that there is no support for constraints and parametrics such that a modeler can define a sphere such that the sphere's radius necessarily maintains tangency with a given planar surface. This task would focus on implementing basic support for this feature in the BRL-CAD geometry format. Parametric representation of Geometry (and constraints) provides a good foundation for various aspects of Design computation, Geometry Generative Algorithms, and A more logically connected model not to mention significant reduction in Modeling time (since the process of modeling during an actual design cycle is inherently iterative).<br />
<br />
Primary work would be in terms of constructing Constraint Solvers. Geometrical constraints in our context can be broadly classified into<br />
*Implicit : Constraints implicit in the definition of a primitive : Tangency or perpendicularity of Vectors, Equality of scalars etc.<br />
*Explicit : Constraints explicitly expressed between two or more primitives.<br />
One of the intricate parts of the work is the actual integration of libpc with librt.<br />
Associated work going on with libpc involves the creation of a Math Virtual Machine for parsing and evaluating (math) expressions which would be used for stating the constraints, along with the grammar.<br />
As of now [http://www.boost.org/ Boost] libraries are being used for various functionalities.<br />
<br />
Requirements:<br />
<br />
*Strong familiarity with C<br />
*Strong familiarity with C++ (check pcMath* source code)<br />
*Ability to implement within an existing framework<br />
<br />
Difficulty: high<br />
<br />
== Merge MGED and Archer ==<br />
<br />
BRL-CAD contains two GUI modeling interfaces called MGED and Archer. MGED is BRL-CAD's comprehensive solid modeling editor that has been around for more than two decades. It's predominantly written in a mix of C and Tcl/Tk. Archer is a new interface that has been developed as a much cleaner re-implementation of MGED. Archer is predominantly Incr Tcl/Tk while calling the same C library as MGED. We would like to merge those two efforts into one, retaining the extensive feature set of MGED while leveraging Archer's much more modular plugin-based design and more appealing GUI.<br />
<br />
This project would involve adding major functionality missing from Archer that MGED provides and putting the finishing touches on Archer. There will need to be some minor bridge work to clean up the shared LIBGED interface that both codes utilize. There will need to be a lot of production quality release testing to make sure features aren't broken or lost during the merge.<br />
<br />
Requirements:<br />
<br />
*Strong familiarity with Tcl/Tk or the ability to get up to speed with it very quickly<br />
*Good familiarity with C<br />
*Ability to read and comprehend other developer's code<br />
<br />
Difficulty: medium<br />
<br />
<br />
== Bug Fix Buffet ==<br />
<br />
BRL-CAD is a massive code base with more than a million lines of code. When you have that many lines, bugs are pretty much guaranteed. That said, code quality is of paramount importance for the long-term longevity of a code. <br />
<br />
https://sourceforge.net/tracker2/?group_id=105292&atid=640802<br />
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/BUGS<br />
<br />
This project is obviously pretty easy to explain. Propose a set of bugs that you would like to work on fixing. They can be hard or easy, many or few. Given the general nature of this task, be sure to be as specific as possible in your proposal.<br />
<br />
Requirements:<br />
<br />
*Methodical approach, deductive reasoning, and strong problem solving skills<br />
*Able to read and debug large amounts of other people's code<br />
*(optional) Familiarity with a debugger (if you don't know how to use a debugger, you will by the time you finish this)<br />
<br />
Difficulty: variable<br />
<br />
<br />
= Additional Projects =<br />
<br />
These projects will generally require a very well thought out proposal and a fair bit of discussion beforehand to be considered over one of the higher-priority (and harder) projects listed above. This isn't meant to be discouraging, though. A great proposal from a student that is passionate about their idea is a major consideration factor. <br />
<br />
==IGES importer/exporter enhancements==<br />
<br />
IGES is one of the most prevalent CAD geometry file formats used to exchange geometry data between CAD systems. BRL-CAD inludes extensive support for IGES, but only up to version 5.0 whereas the current/final version of IGES was 5.3 and there are non-final versions beyond that. This task would make the changes necessary to the existing IGES importer and exporter to fully support the latest IGES standard, possibly modifying the converter to simultaneously support multiple formats.<br />
<br />
Requirements:<br />
<br />
*Familiarity with C<br />
*Strong ability to review and improve existing code<br />
<br />
Difficulty: low<br />
<br />
<br />
==Universal geometry converter API==<br />
<br />
With more than 30 geometry importers and exporters, including several that are of paramount importance to CAD communities such as IGES and DXF, BRL-CAD contains a multitude of converters that can be chained together to go to and from various formats. This task would involve refactoring the existing converters into a clean "universal" geometry converter and API that could read and write from any of the supported formats as run-time plugins. If you have more time, you can always start work on a new converter too.<br />
<br />
Requirements:<br />
<br />
*Familiarity with C or C++<br />
*Ability to understand and refactor existing code<br />
<br />
Difficulty: low<br />
<br />
<br />
==STEP converter ==<br />
<br />
Several BRL-CAD developers are working on implementing a full STEP converter. This task is a big effort given the complexity of the STEP standard (ISO 10303). This task focuses on helping with that effort by working on one of the fundamental components to the STEP converter, getting an EXPRESS parser working. This would most likely entail updating and integrating the NIST STEP AP 21 parser or developing/using a similar EXPRESS parser. The NIST sources as well as copies of the STEP standard can be provided. If that is ends up being too easy, the next step is jumping in on AP 203 and AP 214 hooks. ''This is a high-priority topic.''<br />
<br />
Requirements:<br />
<br />
*Familiarity with C and/or C++<br />
*Ability to integrate with and update an existing code library<br />
*Familiarity with writing a robust parser<br />
*Ability to tolerate bloated ISO standards<br />
<br />
Difficulty: medium<br />
<br />
<br />
==New geometry converter==<br />
<br />
Though we have more than 30 geometry importers and exporters, there are plenty that we don't have support for and existing converters that could use improvements. Some examples of converters we would like to see implemented include (in rough priority/interest order):<br />
<br />
*Collada (.dae)<br />
*X3D [importer] (.x3d)<br />
*Alias Wavefront [importer] (.obj)<br />
*Rhino (.3dm)<br />
*AutoCAD drawings (.dwg)<br />
*G-Code (.nc)<br />
*Solidworks (.sat, .sldprt, .sldasm)<br />
*Parasolid/UGS (.x_b, .x_t)<br />
*POV-RAY (.pov)<br />
*Blender (.blend)<br />
*Universal 3D (.u3d)<br />
*Polygon [exporter] (.ply)<br />
*Sketchup (.skp, .skb)<br />
*VRML [importer] (.vrml)<br />
*3D Studio Max (.3ds)<br />
<br />
Requirements:<br />
<br />
*Familiarity with C or C++<br />
<br />
Difficulty: low<br />
<br />
<br />
==Implicit to Explicit boundary representation support==<br />
<br />
Throughout BRL-CAD's numerous supported primitive geometry types (see http://brlcad.org/gallery/s/diagrams/primitives.png.html for examples), they are implemented using an implicit geometric representation. This means, for example, that for a sphere with a given radius, we store and manipulate it ''as a sphere with a given radius'' and not as collection of triangles/polygons, not as some sort of spline surface, not as a voxelized data set, etc.<br />
<br />
Look in src/librt/primitives for the code to all of the primitives. The *_brep.cpp files in ell, nmg, sph, and tor include the work performed to date. <br />
<br />
This project requires implementing a routine for many/most/all of our primitives that generates a NURBS/BREP spline surface representation of that primitive shape. There are a few primitives that are already complete due to previous developments, but there are still many primitives that have yet to have the routine implemented.<br />
<br />
Requirements:<br />
<br />
*Familiarity with C/C++<br />
*Solid mathematical foundations are required<br />
<br />
Difficulty: medium<br />
<br />
<br />
==New primitive==<br />
<br />
BRL-CAD provides more than 30 different primitives but there are a few we don't have that would be highly desirable to have implemented. The goal of this task is to fully implement support for one of them:<br />
<br />
*Sweep<br />
*Revolution<br />
*Birail/Skin<br />
*Annotation<br />
*Blend/Fillet/Chamfer<br />
*Dynamic Scripted<br />
*Compound Procedural<br />
<br />
Requirements:<br />
<br />
*Familiarity with C<br />
*Solid mathematical basis for the primitive being suggested<br />
<br />
Difficulty: high<br />
<br />
<br />
==Annotations==<br />
<br />
This task is pretty simple on the surface: implement annotations. This effectively amounts to implementing a new primitive in BRL-CAD that can be associated with other objects for providing annotation information. Annotations would allow the modeler to leave notes and draw simple diagrams around geometry during the modeling process where the annotations are either fixed with respect to the view or align with the object(s) they refer to (if any). There are design considerations as to whether you can ray-trace an annotation as well as how to most effectively display them. It would be awesome if users could interactively edit their annotations through the GUI.<br />
<br />
Requirements:<br />
<br />
*Strong familiarity with C<br />
*Ability to implement within an existing framework<br />
<br />
Dificulty: medium<br />
<br />
<br />
==Web-based solid geometry model repository==<br />
<br />
This task focuses on creating a web interface to a geometry repository where the community can store and exchange geometric models in any of the supported BRL-CAD formats. The website could be written such that it integrates with an existing content management system (e.g. Drupal extension), wiki (e.g. Mediawiki extension), or could be custom with the appropriate design plan. The site would need to provide a relatively easy means for users to upload models and have those models be indexed, categorized, searched, converted, and downloaded through the website interface.<br />
<br />
This tends to be a very popular submission. Make sure you relate your idea specifically to BRL-CAD, our tools and services, and how you are not ignoring what we already do. It needs to be a well-integrated service if you're going to propose it.<br />
<br />
Requirements:<br />
<br />
*Strong web development skills<br />
*(optional)Familiarity with Drupal or Mediawiki customization and/or module development<br />
*Must integrate well with BRL-CAD's format, tools, and services<br />
<br />
Difficulty: low<br />
<br />
<br />
==Global illumination renderer==<br />
<br />
This was a GSoC 2008 project. Talk to the developers before proposing this task to obtain project status.<br />
<br />
Our LIBRT library provides advanced solid modeling ray-trace facilities. This idea is to use the LIBRT library and implement a global illumination renderer such as a bidirectional path tracer (e.g. metropolis light transport) or radiosity renderer.<br />
<br />
Requirements:<br />
<br />
*Strong familiarity with C<br />
*Familiarity with global illumination rendering<br />
*Solid math background<br />
*Ability to learn and utilize existing C API<br />
<br />
Difficulty: low<br />
<br />
<br />
==Geometry database (i.e. ".g" file format) enhancements==<br />
<br />
Our ".g" file format is a binary geometry file format that provides a robust, efficient, and flexible object storage framework. There are, however, many features that would be really useful to have in the database layer that are not presently implemented.<br />
<br />
See http://brlcad.org/OLD/newdb/newdb.html to get started on some the low-level details about our .g file format. See the source code for the definitive status.<br />
<br />
The idea behind this task would be to propose a set of enhancements, whether they be backwards-compatible with our current "v5" geometry file format or whether it be the development of a new "v6" file format. The sorts of enhancements needed include time-stamping of geometry database objects, support for constraints and parametric equations as intrinsic object properties, objects with versioning and construction histories, intrinsic support for surrogation, dynamic geometry, automatic space compression, deleted object recovery, performance enhancements, and more. There's plenty of room for new features and improvements, so be specific in your scope and goals. <br />
<br />
Requirements:<br />
<br />
*Familiarity with C<br />
*Ability to learn and extend an existing API<br />
<br />
Difficulty: high<br />
<br />
<br />
==Fixed-precision compile-time interface==<br />
<br />
BRL-CAD uses floating point computation pervasively with extensive efforts taken to account for various floating point types and floating point instability. For the purposes of regression testing and the validation and verification of routines, it is highly desirable to have the ability to guarantee calculations to a given precision.<br />
<br />
Basically, this task entails implementing a GMP C++ interface as our fastf_t type as a compile-time option. The task will require refactoring a cleaning up a lot of the code throughout BRL-CAD so that fastf_t's are pervasive to a given ray trace evaluation. It will also require developing C++ operators to override behavior for [], +, -, *, and various others. BRL-CAD already includes a regression testing suite that can be used to <br />
<br />
See the "benchmark" tool in a BRL-CAD install to get started as well as include/*.h and src/libbn and src/librt for libraries you'll have to work with. The main 'rt' raytrace binary is in src/rt/.<br />
<br />
Requirements:<br />
<br />
*Familiarity with C/C++<br />
<br />
Difficulty: low</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Google_Summer_of_Code/2009&diff=1249
Google Summer of Code/2009
2009-03-15T09:31:35Z
<p>Homovulgaris: Link corrected</p>
<hr />
<div>We are not yet accepted into the 2009 Google Summer of Code. Until we are, this information is purely anticipatory and speculative. Contact us if you have any questions.<br />
<br />
= Getting started =<br />
<br />
Students participating with BRL-CAD in the 2009 GSoC have a '''[[Google_Summer_of_Code/Checklist|checklist]]''' of actions that they should perform before getting started on their projects. Students 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 />
You can see our [[Google_Summer_of_Code/Project_Ideas|Project Ideas]] page for a list of project suggestions that are suggested to be of particular interest. There are several [http://brlcad.org/~sean/ideas.html other areas] of development that are of high-interest as well. Students are welcome to submit their own ideas as well and are encouraged to collaborate with the developers on formulating new projects. Student applications for GSoC will be accepted on Google's project website between March 23 and April 3. See http://socghop.appspot.com/ for more information.</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Talk:Libpg_:_A_parametrics/constraint_library&diff=1162
Talk:Libpg : A parametrics/constraint library
2008-12-16T08:15:57Z
<p>Homovulgaris: </p>
<hr />
<div>[[User:Sean|Sean]] 01:19, 16 December 2008 (EST) says: Hrm. Don't know if you'll see this, Dawn.. but remind me -- what software did you render the architecture diagram with?<br />
<br />
That was a proprietary cheat :) Office 2007 ( Powerpoint ) and then exported to png. I am really looking forward to Omnigraffle though .. Its illustrations look divine.</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Google_Summer_of_Code/2008&diff=682
Google Summer of Code/2008
2008-08-08T18:21:10Z
<p>Homovulgaris: /* 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 />
:*Development blog at http://andrecastelo.wordpress.com<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 />
:*"Developer" Log : [http://www.ohloh.net/accounts/dawn/messages.rss] ( Mostly "pertinent" updates to what the developer is upto )<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>
Homovulgaris
https://brlcad.org/w/index.php?title=A_Survey_of_Implicit_Constraints_in_Primitives&diff=674
A Survey of Implicit Constraints in Primitives
2008-08-05T19:55:52Z
<p>Homovulgaris: /* Implict Constraints by Primitive */</p>
<hr />
<div>{{DesignDocument}}<br />
==Types of Implicit Parameters==<br />
At the level of constraint networks, calculations are done in terms of Variables or indpendent real values / floating point numbers. But in the construction of geometry these are clustered together in terms of implicit parameters. Typical implicit parameters are<br />
# '''Vectors''' - A 3 dimensional vector is a 3-tuple which is used to hold direction as well as magnitude. In BRL-CAD primitives, they may represent<br />
## Radius vectors ( Center of a sphere)<br />
## Direction vectors (Direction of a plane)<br />
<br />
==Types of Implicit Constraints==<br />
An enumeration of the set of contraints observed in the primitives below<br />
<br />
# '''Modulus Comparison''' : Comparison of the modulus of a vector to a real number ( 0 for non-negativity ) or the modulus of another vector<br />
# '''Perpendicularity of Vectors'''<br />
==Implict Constraints by Primitive==<br />
===ell (Ellipse)===<br />
<br />
Ellipse is built using the Center (radius vector V) and 3 Vectors (A, B, C st. |A| = radius)<br />
2 types: Non-negativity/Modulus comparison, Perpendicularity<br />
Constraints:<br />
# |A| > 0<br />
# |B| > 0<br />
# |C| > 0<br />
# A.B = 0<br />
# B.C = 0<br />
# C.A = 0<br />
<br />
===rec (Right elliptical cylinder)===<br />
<br />
3 types: Non-negativity/Modulus comparison, Perpendicularity, Vector equality<br />
<br />
Constraints:<br />
# |H| > 0<br />
# |A| > 0<br />
# |B| > 0<br />
# A = C<br />
# B = D<br />
# A.B = 0<br />
# H.A = 0<br />
# H.B = 0<br />
<br />
===rhc (Right hyperbolic cylinder)===<br />
<br />
3 types: Non-negativity/Modulus comparison, Perpendicularity<br />
<br />
Constraints:<br />
# |H| > 0<br />
# |B| > 0<br />
# |R| > 0<br />
# H.B = 0<br />
<br />
===rpc (Right parabolic cylinder)===<br />
<br />
2 types: Non-negativity/Modulus comparison, Perpendicularity<br />
<br />
Constraints:<br />
# |H| > 0<br />
# |B| > 0<br />
# |R| > 0<br />
# H.B = 0<br />
<br />
===sph (Sphere)===<br />
<br />
Sphere is a particular case of the ellipse<br />
<br />
Constraints:<br />
2 types: Modulus comparison, Perpendicularity<br />
# |A| > 0<br />
# |B| > 0<br />
# |C| > 0<br />
# |A| = |B|<br />
# |A| = |C| <br />
# |B| = |C|<br />
# A.B = 0<br />
# B.C = 0<br />
# C.A = 0<br />
<br />
===tgc (Truncated General Cone)===<br />
<br />
Constraints:<br />
5 types: Modulus comparison, Logical Combination, Perpendicularity, Non-planarity, Parallelism<br />
<br />
# |H| > 0<br />
# |A| & |B| not zero together<br />
# |B| & |D| not zero togehter<br />
# |A|*|B| and |C|*|D| not zero together<br />
# H is nonplanar to AB plane<br />
# A.B = 0<br />
# C.D = 0<br />
# A || C ( A is parallel to C )<br />
<br />
===tor (Torus)===<br />
Tor is built using the following input fields<br />
V V from origin to center<br />
H Radius Vector, Normal to plane of torus. |H| = R2<br />
A, B perpindicular, to CENTER of torus. |A|==|B|==R1<br />
F5, F6 perpindicular, for inner edge (unused)<br />
F7, F8 perpindicular, for outer edge (unused)<br />
<br />
Constraints:<br />
2 types: Modulus comparison, Perpendicularity<br />
# |A| = |B|<br />
# A.B = 0<br />
# B.H = 0<br />
# H.A = 0<br />
# |H| > 0<br />
# |H| < |A|</div>
Homovulgaris
https://brlcad.org/w/index.php?title=A_Survey_of_Implicit_Constraints_in_Primitives&diff=673
A Survey of Implicit Constraints in Primitives
2008-08-05T19:40:34Z
<p>Homovulgaris: /* Implict Constraints by Primitive */</p>
<hr />
<div>{{DesignDocument}}<br />
==Types of Implicit Parameters==<br />
At the level of constraint networks, calculations are done in terms of Variables or indpendent real values / floating point numbers. But in the construction of geometry these are clustered together in terms of implicit parameters. Typical implicit parameters are<br />
# '''Vectors''' - A 3 dimensional vector is a 3-tuple which is used to hold direction as well as magnitude. In BRL-CAD primitives, they may represent<br />
## Radius vectors ( Center of a sphere)<br />
## Direction vectors (Direction of a plane)<br />
<br />
==Types of Implicit Constraints==<br />
An enumeration of the set of contraints observed in the primitives below<br />
<br />
# '''Modulus Comparison''' : Comparison of the modulus of a vector to a real number ( 0 for non-negativity ) or the modulus of another vector<br />
# '''Perpendicularity of Vectors'''<br />
==Implict Constraints by Primitive==<br />
===ell (Ellipse)===<br />
<br />
Ellipse is built using the Center (radius vector V) and 3 Vectors (A, B, C st. |A| = radius)<br />
2 types: Non-negativity/Modulus comparison, Perpendicularity<br />
Constraints:<br />
# |A| > 0<br />
# |B| > 0<br />
# |C| > 0<br />
# A.B = 0<br />
# B.C = 0<br />
# C.A = 0<br />
<br />
===sph (Sphere)===<br />
<br />
Sphere is a particular case of the ellipse<br />
<br />
Constraints:<br />
2 types: Modulus comparison, Perpendicularity<br />
# |A| > 0<br />
# |B| > 0<br />
# |C| > 0<br />
# |A| = |B|<br />
# |A| = |C| <br />
# |B| = |C|<br />
# A.B = 0<br />
# B.C = 0<br />
# C.A = 0<br />
<br />
===tgc (Truncated General Cone)===<br />
<br />
Constraints:<br />
5 types: Modulus comparison, Logical Combination, Perpendicularity, Non-planarity, Parallelism<br />
<br />
# |H| > 0<br />
# |A| & |B| not zero together<br />
# |B| & |D| not zero togehter<br />
# |A|*|B| and |C|*|D| not zero together<br />
# H is nonplanar to AB plane<br />
# A.B = 0<br />
# C.D = 0<br />
# A || C ( A is parallel to C )<br />
<br />
===tor (Torus)===<br />
Tor is built using the following input fields<br />
V V from origin to center<br />
H Radius Vector, Normal to plane of torus. |H| = R2<br />
A, B perpindicular, to CENTER of torus. |A|==|B|==R1<br />
F5, F6 perpindicular, for inner edge (unused)<br />
F7, F8 perpindicular, for outer edge (unused)<br />
<br />
Constraints:<br />
2 types: Modulus comparison, Perpendicularity<br />
# |A| = |B|<br />
# A.B = 0<br />
# B.H = 0<br />
# H.A = 0<br />
# |H| > 0<br />
# |H| < |A|</div>
Homovulgaris
https://brlcad.org/w/index.php?title=A_Survey_of_Implicit_Constraints_in_Primitives&diff=665
A Survey of Implicit Constraints in Primitives
2008-08-05T10:36:45Z
<p>Homovulgaris: ell, sph, tor</p>
<hr />
<div>{{DesignDocument}}<br />
==Types of Implicit Parameters==<br />
At the level of constraint networks, calculations are done in terms of Variables or indpendent real values / floating point numbers. But in the construction of geometry these are clustered together in terms of implicit parameters. Typical implicit parameters are<br />
# '''Vectors''' - A 3 dimensional vector is a 3-tuple which is used to hold direction as well as magnitude. In BRL-CAD primitives, they may represent<br />
## Radius vectors ( Center of a sphere)<br />
## Direction vectors (Direction of a plane)<br />
<br />
==Types of Implicit Constraints==<br />
An enumeration of the set of contraints observed in the primitives below<br />
<br />
# '''Modulus Comparison''' : Comparison of the modulus of a vector to a real number ( 0 for non-negativity ) or the modulus of another vector<br />
# '''Perpendicularity of Vectors'''<br />
==Implict Constraints by Primitive==<br />
===ell (Ellipse)===<br />
<br />
Ellipse is built using the Center (radius vector V) and 3 Vectors (A, B, C st. |A| = radius)<br />
2 types: Non-negativity/Modulus comparison, Perpendicularity<br />
Constraints:<br />
# |A| > 0<br />
# |B| > 0<br />
# |C| > 0<br />
# A.B = 0<br />
# B.C = 0<br />
# C.A = 0<br />
<br />
===sph (Sphere)===<br />
<br />
Sphere is a particular case of the ellipse<br />
<br />
Constraints:<br />
2 types: Modulus comparison, Perpendicularity<br />
# |A| > 0<br />
# |B| > 0<br />
# |C| > 0<br />
# |A|, |B|, |C| approximately equal<br />
# A.B = 0<br />
# B.C = 0<br />
# C.A = 0<br />
<br />
===tor (Torus)===<br />
Tor is built using the following input fields<br />
V V from origin to center<br />
H Radius Vector, Normal to plane of torus. |H| = R2<br />
A, B perpindicular, to CENTER of torus. |A|==|B|==R1<br />
F5, F6 perpindicular, for inner edge (unused)<br />
F7, F8 perpindicular, for outer edge (unused)<br />
<br />
Constraints:<br />
2 types: Modulus comparison, Perpendicularity<br />
# |A| = |B|<br />
# A.B = 0<br />
# B.H = 0<br />
# H.A = 0<br />
# 0 < |H| < |A|</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=664
Libpg : A parametrics/constraint library
2008-08-05T10:04:17Z
<p>Homovulgaris: /* Function */ Adding link to the Implicit Constraints in BRL-CAD primitves</p>
<hr />
<div>{{DesignDocument}}<br />
==libpc: Parametrics and Constraints==<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 />
To efectively implement constraints, the library would first implement constraint functionality which currently exists in terms of implicit constraints ( Non negative radius, Perpendicular vectors etc. ) To see a list of implicit constraints in the various BRL-CAD primitives See [[A Survey of Implicit Constraints in Primitives]]<br />
<br />
==Constraints and CSPs==<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. 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 (with self) constraints. Otherwise, one has to visualize hypergraphs which contain hyperedges which is basically a line connecting multiple vertices for example. Also note that there could arise a situation where constraints depend on constraints ( edges connected to edges in the above discussion ) and hence such hypergraphs don't fit neatly into the bipartite graph structure.<br />
<br />
For a short review of Constraints, and Constraint Satisfaction Problems as well as links to resources on Constraints in general and geometrical constraints in particular, please see [[Constraint Satisfaction]]<br />
<br />
==Library architecture==<br />
<br />
LibPC is composed of two sections which are functionally implemented using 4 modules as represented in the diagram below.<br />
<br />
The modules respectively are ( in the order of operation during a read-out solution process)<br />
<br />
# '''Reader/Import''' which reads from the .g file and generates C-based internal structs<br />
# '''Constraint Network Generator/ Constraint Variable System Generator''' which takes the above structs and produces the respective Variable and Constraint (pcVariable.h and pcConstraint.h) class objects and their graph/hypergraph representation<br />
# '''Solver''' which takes the above Constraint Network as an input and generates a solution / multiple solutions or in effect a Solution object<br />
<br />
# '''Geometry Updater''' which uses the above solution and takes care of the rest such as<br />
* suggest user to select a value in case of multiple solutions for narrowing down the solution range<br />
* update the various parameters of all '''associated geometry'''<br />
* write the data onto the .g file<br />
<br />
== Implementation Details==<br />
<br />
For effective integration with librt system as well as rest of existing brl-cad architecture, the Reader as well as Geometry Updater is entirely in C using standard datastructures. At the same time to make use of the functionality offered by various graph algorithms of boost as well as the power of object oriented programming model in constraint solution, the Constraint Network generator as well as solver is entirely coded in C++. Extensive use of Boost library is expected, in particular<br />
<br />
# constrained_value system : for representing implicit constraints using a predicate system<br />
# Boost Graph Library : for graph based representation of the constraints. '''Since BGL does not have support for Hypergraphs, the author plans to implement hypergraphs independently while adhering to Boost standards ( probable addition to boost itself)'''<br />
# Boos Spirit Library : for the parser based generation of constraint objects from expressions.<br />
Spirit is an object-oriented recursive-descent parser generator framework implemented using template meta-programming techniques. Expression templates allow us to approximate the syntax of Extended Backus-Normal Form (EBNF) completely in C++. Spirit details available at [http://www.boost.org/doc/libs/1_35_0/libs/spirit/index.html boost.org]<br />
<br />
-- Content below is undergoing modification --<br />
<br />
==Constraint 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 />
:''[I think the naming convention should be as consistent as possible with the names used in the MGED user interface. For example, when a sphere is edited in MGED, the parameters available are V (the center), and 3 radius vectors (A, B, and C). Similarly, an RCC or TRC has all the parameters of a TGC. Note also that all objects in a BRL-CAD database file are accessed by unique names. A convention for producing unique names for the constraint objects is needed. Depending on how these constraint objects are accessed by a user, the names of the constraint objects might not ever need to exposed to the user. Objects in the database can be "hidden" so that they do not normally appear in listings] - JRA''<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<br />
primary importance in terms of constraint based calculations. Considering the standard methods of<br />
parametrization ( see Enumeration below ) I think the implementation of an analytic solving system <br />
would be easier. Though for the solution of more complex equation as well as majority of constraints,<br />
libpg will have to provide support for numerical solutions.</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=630
Libpg : A parametrics/constraint library
2008-07-10T07:19:20Z
<p>Homovulgaris: /* Implementation Details */ Spirit introduction added</p>
<hr />
<div>{{DesignDocument}}<br />
==libpc: Parametrics and Constraints==<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 />
==Constraints and CSPs==<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. 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 (with self) constraints. Otherwise, one has to visualize hypergraphs which contain hyperedges which is basically a line connecting multiple vertices for example. Also note that there could arise a situation where constraints depend on constraints ( edges connected to edges in the above discussion ) and hence such hypergraphs don't fit neatly into the bipartite graph structure.<br />
<br />
For a short review of Constraints, and Constraint Satisfaction Problems as well as links to resources on Constraints in general and geometrical constraints in particular, please see [[Constraint Satisfaction]]<br />
<br />
==Library architecture==<br />
<br />
LibPC is composed of two sections which are functionally implemented using 4 modules as represented in the diagram below.<br />
<br />
The modules respectively are ( in the order of operation during a read-out solution process)<br />
<br />
# '''Reader/Import''' which reads from the .g file and generates C-based internal structs<br />
# '''Constraint Network Generator/ Constraint Variable System Generator''' which takes the above structs and produces the respective Variable and Constraint (pcVariable.h and pcConstraint.h) class objects and their graph/hypergraph representation<br />
# '''Solver''' which takes the above Constraint Network as an input and generates a solution / multiple solutions or in effect a Solution object<br />
<br />
# '''Geometry Updater''' which uses the above solution and takes care of the rest such as<br />
* suggest user to select a value in case of multiple solutions for narrowing down the solution range<br />
* update the various parameters of all '''associated geometry'''<br />
* write the data onto the .g file<br />
<br />
== Implementation Details==<br />
<br />
For effective integration with librt system as well as rest of existing brl-cad architecture, the Reader as well as Geometry Updater is entirely in C using standard datastructures. At the same time to make use of the functionality offered by various graph algorithms of boost as well as the power of object oriented programming model in constraint solution, the Constraint Network generator as well as solver is entirely coded in C++. Extensive use of Boost library is expected, in particular<br />
<br />
# constrained_value system : for representing implicit constraints using a predicate system<br />
# Boost Graph Library : for graph based representation of the constraints. '''Since BGL does not have support for Hypergraphs, the author plans to implement hypergraphs independently while adhering to Boost standards ( probable addition to boost itself)'''<br />
# Boos Spirit Library : for the parser based generation of constraint objects from expressions.<br />
Spirit is an object-oriented recursive-descent parser generator framework implemented using template meta-programming techniques. Expression templates allow us to approximate the syntax of Extended Backus-Normal Form (EBNF) completely in C++. Spirit details available at [http://www.boost.org/doc/libs/1_35_0/libs/spirit/index.html boost.org]<br />
<br />
-- Content below is undergoing modification --<br />
<br />
==Constraint 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 />
:''[I think the naming convention should be as consistent as possible with the names used in the MGED user interface. For example, when a sphere is edited in MGED, the parameters available are V (the center), and 3 radius vectors (A, B, and C). Similarly, an RCC or TRC has all the parameters of a TGC. Note also that all objects in a BRL-CAD database file are accessed by unique names. A convention for producing unique names for the constraint objects is needed. Depending on how these constraint objects are accessed by a user, the names of the constraint objects might not ever need to exposed to the user. Objects in the database can be "hidden" so that they do not normally appear in listings] - JRA''<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<br />
primary importance in terms of constraint based calculations. Considering the standard methods of<br />
parametrization ( see Enumeration below ) I think the implementation of an analytic solving system <br />
would be easier. Though for the solution of more complex equation as well as majority of constraints,<br />
libpg will have to provide support for numerical solutions.</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=629
Libpg : A parametrics/constraint library
2008-07-10T07:14:48Z
<p>Homovulgaris: /* Evaluation System */ format modification</p>
<hr />
<div>{{DesignDocument}}<br />
==libpc: Parametrics and Constraints==<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 />
==Constraints and CSPs==<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. 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 (with self) constraints. Otherwise, one has to visualize hypergraphs which contain hyperedges which is basically a line connecting multiple vertices for example. Also note that there could arise a situation where constraints depend on constraints ( edges connected to edges in the above discussion ) and hence such hypergraphs don't fit neatly into the bipartite graph structure.<br />
<br />
For a short review of Constraints, and Constraint Satisfaction Problems as well as links to resources on Constraints in general and geometrical constraints in particular, please see [[Constraint Satisfaction]]<br />
<br />
==Library architecture==<br />
<br />
LibPC is composed of two sections which are functionally implemented using 4 modules as represented in the diagram below.<br />
<br />
The modules respectively are ( in the order of operation during a read-out solution process)<br />
<br />
# '''Reader/Import''' which reads from the .g file and generates C-based internal structs<br />
# '''Constraint Network Generator/ Constraint Variable System Generator''' which takes the above structs and produces the respective Variable and Constraint (pcVariable.h and pcConstraint.h) class objects and their graph/hypergraph representation<br />
# '''Solver''' which takes the above Constraint Network as an input and generates a solution / multiple solutions or in effect a Solution object<br />
<br />
# '''Geometry Updater''' which uses the above solution and takes care of the rest such as<br />
* suggest user to select a value in case of multiple solutions for narrowing down the solution range<br />
* update the various parameters of all '''associated geometry'''<br />
* write the data onto the .g file<br />
<br />
== Implementation Details==<br />
<br />
For effective integration with librt system as well as rest of existing brl-cad architecture, the Reader as well as Geometry Updater is entirely in C using standard datastructures. At the same time to make use of the functionality offered by various graph algorithms of boost as well as the power of object oriented programming model in constraint solution, the Constraint Network generator as well as solver is entirely coded in C++. Extensive use of Boost library is expected, in particular<br />
<br />
# constrained_value system for representing implicit constraints using a predicate system<br />
# Boost Graph Library : for graph based representation of the constraints. '''Since BGL does not have support for Hypergraphs, the author plans to implement hypergraphs independently while adhering to Boost standards ( probable addition to boost itself)'''<br />
<br />
<br />
-- Content below is undergoing modification --<br />
<br />
<br />
==Constraint 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 />
:''[I think the naming convention should be as consistent as possible with the names used in the MGED user interface. For example, when a sphere is edited in MGED, the parameters available are V (the center), and 3 radius vectors (A, B, and C). Similarly, an RCC or TRC has all the parameters of a TGC. Note also that all objects in a BRL-CAD database file are accessed by unique names. A convention for producing unique names for the constraint objects is needed. Depending on how these constraint objects are accessed by a user, the names of the constraint objects might not ever need to exposed to the user. Objects in the database can be "hidden" so that they do not normally appear in listings] - JRA''<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<br />
primary importance in terms of constraint based calculations. Considering the standard methods of<br />
parametrization ( see Enumeration below ) I think the implementation of an analytic solving system <br />
would be easier. Though for the solution of more complex equation as well as majority of constraints,<br />
libpg will have to provide support for numerical solutions.</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=477
Libpg : A parametrics/constraint library
2008-05-19T20:20:36Z
<p>Homovulgaris: /* Architecture */</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 />
===Evaluation System===<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>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=476
Libpg : A parametrics/constraint library
2008-05-19T20:19:32Z
<p>Homovulgaris: /* Architecture */</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 />
1. Domain extraction<br />
2. Solution<br />
3. Geometry updation<br />
<br />
Prerequisites for such a state is of course<br />
<br />
1."Handle" generation and storage<br />
2. 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 />
===Evaluation System===<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>
Homovulgaris
https://brlcad.org/w/index.php?title=User:Homovulgaris&diff=442
User:Homovulgaris
2008-04-28T18:57:04Z
<p>Homovulgaris: New page: __NOTOC__ == Dawn Thomas == 22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur. * [http://dawtho.googlepages.com: Homepage] * [http://homovu...</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
== Dawn Thomas ==<br />
<br />
22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur.<br />
<br />
* [http://dawtho.googlepages.com: Homepage]<br />
* [http://homovulgaris.blogspot.com: Blog]</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=257
Libpg : A parametrics/constraint library
2008-03-29T22:35:27Z
<p>Homovulgaris: /* Extensibility */</p>
<hr />
<div>= 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 />
[[Image:LibpgAppArch.png|left|600px| Typical Application Architecture]]<br />
The above mentioned functionalities can be clearly expressed as the following capabilities which libpg provides any application<br />
<br />
#Input/Output<br />
##Reader<br />
##Writer<br />
#Geometry Translation<br />
#Instantiation/Construction<br />
#Analytic Evaluation<br />
#Numeric Evaluation<br />
<br />
Reader and Writer are the respective set of functions which deal with reading and writing information from and onto the .g database constraint files, command input etc.<br />
Geometry translation is a primarily a feature for interoperability of libpg package with other CAD geometry systems. Using this method we can follow an independent system of geometry type within libpg if necessary and the Geometry Translation function effectively translates any type of geometry into the libpg standard. libpg standard can be the .g standard of geometry type itself. Using the data thus translated or read from the database , Instantiation and construction of objects is undertaken.<br />
<br />
A system of '''Object overlay''' is very efficient in the production of parametric geometry objects. Basically for every non-parametric geometry object which is used in the generation of a parametric geometry object we create an equivalent parametric geometric object and use it as an overlay. In this way we will have a comprehensive list of all geometry used in parametrization and would simplify procedure calling.<br />
<br />
Once the existing objects are thus instantiated in the cache / display ( which would solve the problem of timestamping in a sense ) equation evaluation is done for generation of new geometry objects. As shown below in the object structure the various details required for the creation of a new parametric object are<br />
<br />
#Parent Set<br />
#Parameter Set<br />
<br />
Evaluation system is further detailed out 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 />
===Evaluation System===<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>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=256
Libpg : A parametrics/constraint library
2008-03-29T22:34:25Z
<p>Homovulgaris: /* Parametrics */</p>
<hr />
<div>= 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 />
[[Image:LibpgAppArch.png|left|600px| Typical Application Architecture]]<br />
The above mentioned functionalities can be clearly expressed as the following capabilities which libpg provides any application<br />
<br />
#Input/Output<br />
##Reader<br />
##Writer<br />
#Geometry Translation<br />
#Instantiation/Construction<br />
#Analytic Evaluation<br />
#Numeric Evaluation<br />
<br />
Reader and Writer are the respective set of functions which deal with reading and writing information from and onto the .g database constraint files, command input etc.<br />
Geometry translation is a primarily a feature for interoperability of libpg package with other CAD geometry systems. Using this method we can follow an independent system of geometry type within libpg if necessary and the Geometry Translation function effectively translates any type of geometry into the libpg standard. libpg standard can be the .g standard of geometry type itself. Using the data thus translated or read from the database , Instantiation and construction of objects is undertaken.<br />
<br />
A system of '''Object overlay''' is very efficient in the production of parametric geometry objects. Basically for every non-parametric geometry object which is used in the generation of a parametric geometry object we create an equivalent parametric geometric object and use it as an overlay. In this way we will have a comprehensive list of all geometry used in parametrization and would simplify procedure calling.<br />
<br />
Once the existing objects are thus instantiated in the cache / display ( which would solve the problem of timestamping in a sense ) equation evaluation is done for generation of new geometry objects. As shown below in the object structure the various details required for the creation of a new parametric object are<br />
<br />
#Parent Set<br />
#Parameter Set<br />
<br />
Evaluation system is further detailed out 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 />
===Evaluation System===<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>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=255
Libpg : A parametrics/constraint library
2008-03-29T22:30:10Z
<p>Homovulgaris: /* Constraints */</p>
<hr />
<div>= 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 />
[[Image:LibpgAppArch.png|left|600px| Typical Application Architecture]]<br />
The above mentioned functionalities can be clearly expressed as the following capabilities which libpg provides any application<br />
<br />
#Input/Output<br />
##Reader<br />
##Writer<br />
#Geometry Translation<br />
#Instantiation/Construction<br />
#Analytic Evaluation<br />
#Numeric Evaluation<br />
<br />
Reader and Writer are the respective set of functions which deal with reading and writing information from and onto the .g database constraint files, command input etc.<br />
Geometry translation is a primarily a feature for interoperability of libpg package with other CAD geometry systems. Using this method we can follow an independent system of geometry type within libpg if necessary and the Geometry Translation function effectively translates any type of geometry into the libpg standard. libpg standard can be the .g standard of geometry type itself. Using the data thus translated or read from the database , Instantiation and construction of objects is undertaken.<br />
<br />
A system of '''Object overlay''' is very efficient in the production of parametric geometry objects. Basically for every non-parametric geometry object which is used in the generation of a parametric geometry object we create an equivalent parametric geometric object and use it as an overlay. In this way we will have a comprehensive list of all geometry used in parametrization and would simplify procedure calling.<br />
<br />
Once the existing objects are thus instantiated in the cache / display ( which would solve the problem of timestamping in a sense ) equation evaluation is done for generation of new geometry objects. As shown below in the object structure the various details required for the creation of a new parametric object are<br />
<br />
#Parent Set<br />
#Parameter Set<br />
<br />
Evaluation system is further detailed out 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 />
===Evaluation System===<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 />
#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 />
<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>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=254
Libpg : A parametrics/constraint library
2008-03-29T22:25:48Z
<p>Homovulgaris: /* Parametrics */</p>
<hr />
<div>= 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 />
[[Image:LibpgAppArch.png|left|600px| Typical Application Architecture]]<br />
The above mentioned functionalities can be clearly expressed as the following capabilities which libpg provides any application<br />
<br />
#Input/Output<br />
##Reader<br />
##Writer<br />
#Geometry Translation<br />
#Instantiation/Construction<br />
#Analytic Evaluation<br />
#Numeric Evaluation<br />
<br />
Reader and Writer are the respective set of functions which deal with reading and writing information from and onto the .g database constraint files, command input etc.<br />
Geometry translation is a primarily a feature for interoperability of libpg package with other CAD geometry systems. Using this method we can follow an independent system of geometry type within libpg if necessary and the Geometry Translation function effectively translates any type of geometry into the libpg standard. libpg standard can be the .g standard of geometry type itself. Using the data thus translated or read from the database , Instantiation and construction of objects is undertaken.<br />
<br />
A system of '''Object overlay''' is very efficient in the production of parametric geometry objects. Basically for every non-parametric geometry object which is used in the generation of a parametric geometry object we create an equivalent parametric geometric object and use it as an overlay. In this way we will have a comprehensive list of all geometry used in parametrization and would simplify procedure calling.<br />
<br />
Once the existing objects are thus instantiated in the cache / display ( which would solve the problem of timestamping in a sense ) equation evaluation is done for generation of new geometry objects. As shown below in the object structure the various details required for the creation of a new parametric object are<br />
<br />
#Parent Set<br />
#Parameter Set<br />
<br />
Evaluation system is further detailed out 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 />
===Evaluation System===<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 />
#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 />
<br />
===Constraints===<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=253
Libpg : A parametrics/constraint library
2008-03-29T22:17:10Z
<p>Homovulgaris: </p>
<hr />
<div>= 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 />
[[Image:LibpgAppArch.png|left|600px| Typical Application Architecture]]<br />
The above mentioned functionalities can be clearly expressed as the following capabilities which libpg provides any application<br />
<br />
#Input/Output<br />
##Reader<br />
##Writer<br />
#Geometry Translation<br />
#Instantiation/Construction<br />
#Analytic Evaluation<br />
#Numeric Evaluation<br />
<br />
Reader and Writer are the respective set of functions which deal with reading and writing information from and onto the .g database constraint files, command input etc.<br />
Geometry translation is a primarily a feature for interoperability of libpg package with other CAD geometry systems. Using this method we can follow an independent system of geometry type within libpg if necessary and the Geometry Translation function effectively translates any type of geometry into the libpg standard. libpg standard can be the .g standard of geometry type itself. Using the data thus translated or read from the database , Instantiation and construction of objects is undertaken.<br />
<br />
A system of '''Object overlay''' is very efficient in the production of parametric geometry objects. Basically for every non-parametric geometry object which is used in the generation of a parametric geometry object we create an equivalent parametric geometric object and use it as an overlay. In this way we will have a comprehensive list of all geometry used in parametrization and would simplify procedure calling.<br />
<br />
Once the existing objects are thus instantiated in the cache / display ( which would solve the problem of timestamping in a sense ) equation evaluation is done for generation of new geometry objects. As shown below in the object structure the various details required for the creation of a new parametric object are<br />
<br />
#Parent Set<br />
#Parameter Set<br />
<br />
Evaluation system is further detailed out 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 />
===Evaluation System===<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 />
##<br />
===Constraints===<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=252
Libpg : A parametrics/constraint library
2008-03-29T21:30:13Z
<p>Homovulgaris: /* Architecture */</p>
<hr />
<div>= 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 />
[[Image:LibpgAppArch.png|left|600px| Typical Application Architecture]]<br />
The above mentioned functionalities can be clearly expressed as the following capabilities which libpg provides any application<br />
<br />
#Input/Output<br />
##Reader<br />
##Writer<br />
#Geometry Translation<br />
#Instantiation/Construction<br />
#Analytic Evaluation<br />
#Numeric Evaluation<br />
<br />
Reader and Writer are the respective set of functions which deal with reading and writing information from and onto the .g database constraint files, command input etc.<br />
Geometry translation is a primarily a feature for interoperability of libpg package with other CAD geometry systems. Using this method we can follow an independent system of geometry type within libpg if necessary and the Geometry Translation function effectively translates any type of geometry into the libpg standard. libpg standard can be the .g standard of geometry type itself. Using the data thus translated or read from the database , Instantiation and construction of objects is undertaken.<br />
<br />
A system of '''Object overlay''' is very efficient in the production of parametric geometry objects. Basically for every non-parametric geometry object which is used in the generation of a parametric geometry object we create an equivalent parametric geometric object and use it as an overlay. In this way we will have a comprehensive list of all geometry used in parametrization and would simplify procedure calling.<br />
<br />
Once the existing objects are thus instantiated in the cache / display ( which would solve the problem of timestamping in a sense ) equation evaluation is done for generation of new geometry objects. As shown below in the object structure the various details required for the creation of a new parametric object are<br />
<br />
#Parent Set<br />
#Parameter Set<br />
<br />
Evaluation system is further detailed out 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 />
<br />
[[Image:LibpgObjectArch.png|600px|Object Architecture Image]]<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability</div>
Homovulgaris
https://brlcad.org/w/index.php?title=File:LibpgAppArch.png&diff=251
File:LibpgAppArch.png
2008-03-29T21:25:46Z
<p>Homovulgaris: Libpg Typical Application Architecture proposed</p>
<hr />
<div>Libpg Typical Application Architecture proposed</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=250
Libpg : A parametrics/constraint library
2008-03-28T21:22:46Z
<p>Homovulgaris: </p>
<hr />
<div>= 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 />
Image to be uploaded<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 />
<br />
[[Image:LibpgObjectArch.png|600px|Object Architecture Image]]<br />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability</div>
Homovulgaris
https://brlcad.org/w/index.php?title=File:LibpgObjectArch.png&diff=249
File:LibpgObjectArch.png
2008-03-28T21:18:25Z
<p>Homovulgaris: LibPG Object Architecture (proposed)</p>
<hr />
<div>LibPG Object Architecture (proposed)</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=248
Libpg : A parametrics/constraint library
2008-03-28T20:21:01Z
<p>Homovulgaris: /* libpg : A parametrics/ constraint library */ Under construction</p>
<hr />
<div>= 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 />
Image to be uploaded<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 />
<br />
==Notes==<br />
<br />
===Object Overlay===<br />
===Extensibility===<br />
===Interoperability</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Libpg_:_A_parametrics/constraint_library&diff=246
Libpg : A parametrics/constraint library
2008-03-25T20:10:27Z
<p>Homovulgaris: Start</p>
<hr />
<div>= libpg : A parametrics/ constraint library =<br />
<br />
Proposed sytem for parametrics and constraint implementation<br />
by Dawn Thomas (homovulgaris)</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Developer_Documents&diff=245
Developer Documents
2008-03-25T20:06:37Z
<p>Homovulgaris: New page: = Developer Documents = A collection of various Developer Documents on new features/projects within brl-cad system. == Features/Projects == * [[libpg : A parametrics/constraint library]...</p>
<hr />
<div>= Developer Documents =<br />
<br />
A collection of various Developer Documents on new features/projects within brl-cad system.<br />
<br />
== Features/Projects ==<br />
<br />
* [[libpg : A parametrics/constraint library]]</div>
Homovulgaris
https://brlcad.org/w/index.php?title=Main_page&diff=244
Main page
2008-03-25T20:02:38Z
<p>Homovulgaris: /* Projects */</p>
<hr />
<div>__NOTOC__<br />
<br />
= BRL-CAD Wiki =<br />
<br />
Welcome to the BRL-CAD Wiki! A wiki is a type of site that allows visitors to directly contribute to the content of a website. The intention of the BRL-CAD Wiki is to get ''everyone'' in the community working together on providing the information that the everyone needs. The wiki is intended as a place for any documentation, tutorials, support, examples, and other pieces of information that may be of use to others. All are welcome to contribute and anyone may edit most of the wiki pages. With everyone's help, we can make this a tremendous resource for the CAD community.<br />
<br />
Don't be shy with your contributions. Give editing a try and be proud of your contributions! If you make a mistake, they're very easy to undo and you don't even need to have an account created. If you do create an account, however, you will be credited with the contribution in the page's history. <br />
<br />
So be '''bold''' and ''have at it''!<br />
<br />
== Getting started ==<br />
<br />
* [[FAQ]]<br />
* [[Documentation]]<br />
* [[MGED Commands]]<br />
* [[BRL-CAD Commands]]<br />
* [[Support]]<br />
<br />
== Projects == <br />
* [[Google Summer of Code]]<br />
* [[Developer Documents]]<br />
<br />
== Tutorials ==<br />
* [[SGI_Cube]]<br />
<br />
If you are unsure on how to edit or add new pages, see the [[Help:Contents|Help]]. Consult the [http://meta.wikimedia.org/wiki/Help User's Guide] for information on using a wiki, particularly the section on [http://meta.wikimedia.org/wiki/Help:Editing editing] pages.</div>
Homovulgaris