Editing User:Homovulgaris
From BRL-CAD
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 4: | Line 4: | ||
== Dawn Thomas == | == Dawn Thomas == | ||
− | + | 22 year old undergraduate student of architecture at Indian Institute of Technology, Kharagpur. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== GSoc 2009 Proposal Draft == | == GSoc 2009 Proposal Draft == | ||
Line 25: | Line 10: | ||
===Abstract=== | ===Abstract=== | ||
− | Continuing with the libpc work from last gsoc | + | Continuing with the libpc work from last gsoc under the following heads |
− | |||
− | |||
− | |||
− | |||
− | for | + | # Writing a robust modular constraint solver(s) |
+ | # Complete definition of constraint grammar on the basis of the existing Math grammar. | ||
+ | # Writing implicit constraints for the primitives : Using libpc for the rt_prep checks. | ||
+ | # Testing explicit constraints. | ||
− | |||
− | |||
− | |||
− | |||
===Proposal=== | ===Proposal=== | ||
Line 47: | Line 27: | ||
# Basic constraint I/O in librt - will need changes till constraint grammar is finalized | # Basic constraint I/O in librt - will need changes till constraint grammar is finalized | ||
− | + | 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. | |
+ | I believe a good project definition for the approximately 480 coding hours of gsoc ( May 23rd to August 10th) is as follows. | ||
− | '''1. Constraint grammar (~ | + | '''1. Solution system (~170 hours)''' |
+ | |||
+ | 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. | ||
+ | |||
+ | '''2. Constraint grammar (~100 hours)''' | ||
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. | 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. | ||
For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables) | For instance ( " tangential(ell1, sph1)" being parsed into the correct constraint objects containing evaluating functions in terms of the variables) | ||
− | ''' | + | '''3. Test Use-cases for Implicit Constraints (~80 hours)''' |
− | + | 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.) | |
+ | '''4. Test Use-cases for Explicit Constraints (~130 hours)''' | ||
− | + | 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. | |
− | + | In addition the following also need to be done. | |
− | + | * Some tinkering is also needed to make the existing code more modular. | |
+ | * There is also a "small" memory leak in the solver which needs to be taken care of. | ||
− | + | In the meantime, I will try to wrap up the documentation which needs a major overhaul and | |
+ | more importantly finish off with the MathVM completion which I have started in March. | ||
− | ===Schedule | + | ===Schedule=== |
− | + | May 23 - July 6 (~ 6 weeks) | |
− | |||
− | |||
* Do further groundwork on Solver | * Do further groundwork on Solver | ||
− | * | + | * Finalising Constraint grammar |
− | + | * Work on Implicit Constraints | |
− | + | * Initial solver work | |
− | + | July 6 - August 10 (~ 5 weeks) | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | * | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
* Complete Solver work | * Complete Solver work | ||
− | * Test | + | * Test Explicit Constraints |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Other Notes=== | ===Other Notes=== | ||
− | + | 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. | |
− | + | Considering my last year experience, I still think this is probably a little more than what I should really aim for. | |
− | |||
− | |||
===References=== | ===References=== |