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 24: | Line 15: | ||
*Passion for the task being suggested | *Passion for the task being suggested | ||
*Buy-in from one of the existing developers | *Buy-in from one of the existing developers | ||
− | |||
− | |||
==OpenGL GUI Framework== | ==OpenGL GUI Framework== | ||
− | |||
− | |||
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. | 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. | ||
Line 42: | Line 29: | ||
*Strong knowledge of C++ | *Strong knowledge of C++ | ||
*Strong knowledge of object oriented design | *Strong knowledge of object oriented design | ||
− | |||
− | |||
Line 56: | Line 41: | ||
*Strong familiarity with object oriented API design | *Strong familiarity with object oriented API design | ||
*(optional) Familiarity with SWIG | *(optional) Familiarity with SWIG | ||
− | |||
− | |||
Line 64: | Line 47: | ||
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 71: | Line 54: | ||
*Usability and interface design experience | *Usability and interface design experience | ||
*(optional) Familiarity with C | *(optional) Familiarity with C | ||
− | |||
− | |||
==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 93: | Line 68: | ||
*(optional) Strong familiarity with implicit geometric representations | *(optional) Strong familiarity with implicit geometric representations | ||
− | + | ||
+ | ==STEP parser integration == | ||
+ | |||
+ | 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.'' | ||
+ | |||
+ | Requirements: | ||
+ | |||
+ | *Familiarity with C and/or C++ | ||
+ | *Ability to integrate with and update an existing code library | ||
+ | *Familiarity with writing a robust parser | ||
+ | *Ability to tolerate bloated ISO standards | ||
+ | |||
== CSG ray-trace optimizations == | == CSG ray-trace optimizations == | ||
Line 103: | Line 89: | ||
*Strong familiarity with C | *Strong familiarity with C | ||
*Strong familiarity with CSG | *Strong familiarity with CSG | ||
− | |||
− | |||
==Constraints and Parametrics== | ==Constraints and Parametrics== | ||
− | + | 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. | |
− | |||
− | 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 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
= 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 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 191: | Line 113: | ||
*Familiarity with C | *Familiarity with C | ||
*Strong ability to review and improve existing code | *Strong ability to review and improve existing code | ||
− | |||
− | |||
Line 203: | Line 123: | ||
*Familiarity with C or C++ | *Familiarity with C or C++ | ||
*Ability to understand and refactor existing code | *Ability to understand and refactor existing code | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 225: | Line 129: | ||
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): | 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): | ||
+ | *STEP (.step) | ||
*Collada (.dae) | *Collada (.dae) | ||
*X3D [importer] (.x3d) | *X3D [importer] (.x3d) | ||
Line 244: | Line 149: | ||
*Familiarity with C or C++ | *Familiarity with C or C++ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 280: | Line 167: | ||
*Familiarity with C | *Familiarity with C | ||
*Solid mathematical basis for the primitive being suggested | *Solid mathematical basis for the primitive being suggested | ||
− | |||
− | |||
Line 292: | Line 177: | ||
*Strong familiarity with C | *Strong familiarity with C | ||
*Ability to implement within an existing framework | *Ability to implement within an existing framework | ||
− | |||
− | |||
Line 307: | Line 190: | ||
*(optional)Familiarity with Drupal or Mediawiki customization and/or module development | *(optional)Familiarity with Drupal or Mediawiki customization and/or module development | ||
*Must integrate well with BRL-CAD's format, tools, and services | *Must integrate well with BRL-CAD's format, tools, and services | ||
− | |||
− | |||
− | |||
==Global illumination renderer== | ==Global illumination renderer== | ||
− | |||
− | |||
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. | 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. | ||
Line 323: | Line 201: | ||
*Solid math background | *Solid math background | ||
*Ability to learn and utilize existing C API | *Ability to learn and utilize existing C API | ||
− | |||
− | |||
==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 339: | Line 211: | ||
*Familiarity with C | *Familiarity with C | ||
*Ability to learn and extend an existing API | *Ability to learn and extend an existing API | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |