Editing Google Summer of Code/2009/Project Ideas
From BRL-CAD
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | + | 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]. | |
− | |||
− | |||
− | |||
− | |||
− | + | 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. | |
− | |||
− | A detailed articulate (i.e. excellent) proposal that has been discussed with us beforehand will generally trump | ||
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. | 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. | ||
− | + | = High Priority Projects = | |
− | |||
− | |||
== <AN IDEA OF YOUR OWN> == | == <AN IDEA OF YOUR OWN> == | ||
Line 64: | Line 56: | ||
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. | 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. | ||
− | The idea behind this task would be propose improvements to MGED's existing Tcl/Tk user interface implementation. Proposals could include usability improvements, 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.'' | + | 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.'' |
Requirements: | Requirements: | ||
Line 77: | Line 69: | ||
==CSG evaluation of Boundary Representations== | ==CSG evaluation of Boundary Representations== | ||
− | 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. | + | 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. 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.'' |
− | |||
− | |||
− | |||
− | |||
− | |||
− | 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.'' | ||
Requirements: | Requirements: | ||
Line 94: | Line 80: | ||
Difficulty: high | Difficulty: high | ||
+ | |||
== CSG ray-trace optimizations == | == CSG ray-trace optimizations == | ||
Line 109: | Line 96: | ||
==Constraints and Parametrics== | ==Constraints and Parametrics== | ||
− | This was a GSoC 2008 project. | + | This was a GSoC 2008 project. Talk to the developers before proposing this task to obtain project status. |
− | |||
− | |||
− | + | 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. | |
− | |||
− | |||
− | |||
− | |||
− | |||
Requirements: | Requirements: | ||
*Strong familiarity with C | *Strong familiarity with C | ||
− | |||
*Ability to implement within an existing framework | *Ability to implement within an existing framework | ||
Difficulty: high | Difficulty: high | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Bug Fix Buffet == | == Bug Fix Buffet == | ||
Line 177: | Line 125: | ||
Difficulty: variable | Difficulty: variable | ||
− | + | ||
+ | == Merge MGED and Archer == | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Requirements: | ||
+ | |||
+ | *Strong familiarity with Tcl/Tk or the ability to get up to speed with it very quickly | ||
+ | *Good familiarity with C | ||
+ | *Ability to read and comprehend other developer's code | ||
+ | |||
+ | Difficulty: medium | ||
+ | |||
+ | |||
= Additional Projects = | = Additional Projects = | ||
− | 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 projects listed above | + | 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. |
− | |||
==IGES importer/exporter enhancements== | ==IGES importer/exporter enhancements== | ||
Line 246: | Line 208: | ||
Difficulty: low | Difficulty: low | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 329: | Line 275: | ||
==Geometry database (i.e. ".g" file format) enhancements== | ==Geometry database (i.e. ".g" file format) enhancements== | ||
− | 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 | + | 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. 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. |
− | |||
− | |||
− | |||
− | 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. | ||
Requirements: | Requirements: | ||
Line 341: | Line 283: | ||
Difficulty: high | Difficulty: high | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |