Contributor Quickies

  • Page
  • Discussion
  • Edit
  • History

The list of possible quick projects that can be a good starting point for new contributors that would like to get involved in working on BRL-CAD. Each project is roughly sorted by difficulty as EASY, MEDIUM, or HARD and categorized by type of work. The tasks range from the very hard and math intense to tedious and VERY easy. Also listed are requirements and a rough estimate of time needed to complete the task. Note that the requirements are not prerequisites but skills that are necessary to complete the task. The time estimate only presumes you have a few (ideal) hours a day.

Please do contact us (via IRC or brlcad-devel mailing list) if you have any questions, corrections, comments, or ideas of your own that you'd like to suggest. Get started by Compiling!

Contents

  • 1 Code
    • 1.1 VERY EASY: Implement a primitive centroid function
    • 1.2 VERY EASY: Implement a primitive surface area function
    • 1.3 VERY EASY: Move LIBBN comments from source to header files
    • 1.4 EASY: Implement a primitive volume function
    • 1.5 EASY: Convert BU_SETJUMP/BU_UNSETJUMP blocks into try/catch layout
    • 1.6 EASY: Move LIBRT comments from source to header files
    • 1.7 EASY: Fix 'analyze' command output formatting
    • 1.8 EASY: Camera 360: A script to capture images while rotating the view around a scene
    • 1.9 EASY: Close MGED when both its windows are closed
    • 1.10 EASY: Implement parallel support for Windows
    • 1.11 MEDIUM: Decouple LIBDM from LIBGED
    • 1.12 MEDIUM: Separate out LIBNMG from LIBRT
    • 1.13 HARD: implement runtime detection of SSE
    • 1.14 HARD: Integrate hi/lo geometry wireframe modifications
    • 1.15 HARD: Fix Bounding Box function for BoT primitive
    • 1.16 HARD: Implement a primitive UV-mapping callback
  • 2 Documentation
    • 2.1 EASY: Add missing documentation (for JUST ONE command)
    • 2.2 EASY: Write "MGED Interface" reference document
    • 2.3 MEDIUM: Convert src/conv man pages to valid Docbook
    • 2.4 MEDIUM: Write a "BRL-CAD Commands Quick Reference" document
    • 2.5 HARD: Write a "Technical Overview of BRL-CAD" document
    • 2.6 HARD: Add missing documentation (for ALL missing)
  • 3 Outreach
    • 3.1 EASY: Write solicitation for new website designer
    • 3.2 EASY: Model new BRL-CAD Logo using BRL-CAD
    • 3.3 EASY: Write BRL-CAD News article on .deb/.rpm builds
    • 3.4 MEDIUM: Write a BRL-CAD model showcase article
    • 3.5 MEDIUM: Design a "Commercial CAD Comparison" diagram
  • 4 Quality Assurance
    • 4.1 EASY: Develop an N-Manifold Geometry (NMG) testing framework
    • 4.2 MEDIUM: Create comprehensive utility library (LIBBU) API unit tests
    • 4.3 MEDIUM: Create comprehensive numerics library (LIBBN) API unit tests
    • 4.4 MEDIUM: Create a comprehensive unit test for bn_dist_pt3_pt3()
    • 4.5 EASY: Find, reproduce, confirm, and report any bug in Archer
  • 5 Research
    • 5.1 EASY: Investigate performance of setting thread affinity
    • 5.2 MEDIUM: Determine why solids.sh fails on 64-bit
    • 5.3 MEDIUM: Investigate permuted vertex lists from g-iges + iges-g
    • 5.4 HARD: Investigate GMP integration
    • 5.5 HARD: Investigate the status of our command spreadsheet
  • 6 Training
    • 6.1 VERY EASY: LIBBU Doxygen cleanup
    • 6.2 EASY: LIBBN Doxygen cleanup
    • 6.3 EASY: LIBWDB Doxygen cleanup
    • 6.4 MEDIUM: LIBRT Doxygen cleanup
    • 6.5 MEDIUM: "Introduction to BRL-CAD Tutorial"
    • 6.6 MEDIUM: Write a "BRL-CAD Ray Tracing Shaders" tutorial
  • 7 Translation
    • 7.1 VERY EASY: Translate "BRL-CAD Overview" document
    • 7.2 EASY: Translate a chapter from the Introduction to MGED to Portuguese
    • 7.3 EASY: Translate a chapter from the Introduction to MGED to Mandarin
    • 7.4 EASY: Translate a chapter from the Introduction to MGED to Hindi
    • 7.5 EASY: Translate a chapter from the Introduction to MGED
    • 7.6 EASY: Translate our HACKING developer guide
    • 7.7 MEDIUM: Translate "Principles of Effective Modeling"
  • 8 User Interface
    • 8.1 EASY: Design an MGED command spreadsheet
    • 8.2 EASY: Create prototype 2D CAD drawing(s)
    • 8.3 MEDIUM: Create prototype CAD GUI layout diagram
    • 8.4 MEDIUM: Reorganize MGED menu
    • 8.5 HARD: Categorize all of BRL-CAD's commands into a spreadsheet

[edit] Code


Tasks related to writing or refactoring code

[edit] VERY EASY: Implement a primitive centroid function

BRL-CAD provides more than two dozen types of geometry "primitives" such as ellipsoids, boxes, and cones. Every primitive is described by a collection of callback functions, for example rt_ell_bbox() returns the bounding box dimensions for an ellipsoid. Wikipedia, Wolfram Mathworld, and various other math sites (and research papers) around the web include the equations for most of our basic primitives.

This task involves writing a new callback function that takes an rt_db_internal object and calculates its centroid (as a point_t 3D point). Any of the primitives that do not already have a centroid callback are fair game.

Time: <1 day

References:

  • en.wikipedia.org/wiki/Centroid
  • mathworld.wolfram.com/

Code:

  • src/librt/primitives/*/*.c

Requirements:

  • Basic familiarity with C
  • Basic familiarity with a text editor
  • Ability to compile BRL-CAD successfully

[edit] VERY EASY: Implement a primitive surface area function

BRL-CAD provides more than two dozen types of geometry "primitives" such as ellipsoids, boxes, and cones. Every primitive is described by a collection of callback functions, for example rt_ell_bbox() returns the bounding box dimensions for an ellipsoid. Wikipedia, Wolfram Mathworld, and various other math sites (and research papers) around the web include the equations for most of our basic primitives.

This task involves writing a new callback function that takes an rt_db_internal object and calculates the surface area (units are mm^2). Any of the primitives that do not already have a surface area callback are fair game.

Time: <1 day

References:

  • en.wikipedia.org/wiki/Surface_area
  • mathworld.wolfram.com/

Code:

  • src/librt/primitives/*/*.c

Requirements:

  • Basic familiarity with C
  • Basic familiarity with a text editor
  • Ability to compile BRL-CAD successfully

[edit] VERY EASY: Move LIBBN comments from source to header files

BRL-CAD uses Doxygen source code comments to document the API. The comments need to be moved from .c source code files to the corresponding .h API header file. There are approximately 300 public API functions across 30 files in LIBBN.

This task involves editing source code to move comments, cleaning up comment formatting, and verifying Doxygen output.

Time: <1 day

Code:

  • include/bn.h
  • src/libbn/*.c

Requirements:

  • Rudimentary familiarity with C
  • Basic familiarity with a text editor (copy-paste)

[edit] EASY: Implement a primitive volume function

BRL-CAD provides more than two dozen types of geometry "primitives" such as ellipsoids, boxes, and cones. Every primitive is described by a collection of callback functions, for example rt_ell_bbox() returns the bounding box dimensions for an ellipsoid. Wikipedia, Wolfram Mathworld, and various other math sites (and research papers) around the web include the equations for most of our basic primitives.

This task involves writing a new callback function that takes an rt_db_internal object and calculates the volume (units are mm^3). Any of the primitives that do not already have a volume callback are fair game.

Time: <1 days

References:

  • en.wikipedia.org/wiki/Volume
  • mathworld.wolfram.com/

Code:

  • src/librt/primitives/*/*.c

Requirements:

  • Basic familiarity with C
  • Basic familiarity with a text editor
  • Ability to compile BRL-CAD successfully

[edit] EASY: Convert BU_SETJUMP/BU_UNSETJUMP blocks into try/catch layout

BRL-CAD's basic utility library (LIBBU) provides a set of macros, BU_SETJUMP and BU_UNSETJUMP, that are used for exception handling.

This task involves restructuring the logic where those macros are used so that they are all consistently in a more familiar "try/catch" ordering. Most are merely in "catch/try" order and need to be reversed, some are in an unstructured layout. There are approximately 50 places that need to be updated.

Time: < 2 days

Code:

  • include/bu.h
  • src/**/*.c

Requirements:

  • Basic familiarity with C
  • Basic familiarity with a text editor
  • Ability to compile BRL-CAD successfully

[edit] EASY: Move LIBRT comments from source to header files

BRL-CAD uses Doxygen source code comments to document the API. The comments need to be moved from .c source code files to the corresponding .h API header file. There are approximately 1000 public API functions across 200 files in LIBRT.

This task involves editing source code to move comments, cleaning up comment formatting, and verifying Doxygen output.

Time: <4 days

Code:

  • include/raytrace.h
  • include/nmg.h
  • include/db.h
  • include/db5.h
  • src/librt/*.c
  • src/librt/comb/*.c
  • src/librt/binunif/*.c
  • src/librt/primitives/**/*.c

Requirements:

  • Rudimentary familiarity with C
  • Basic familiarity with a text editor (copy-paste)

[edit] EASY: Fix 'analyze' command output formatting

BRL-CAD has an interactive geometry editor called MGED. MGED has several hundred commands including an "analyze" command that reports basic statistics such as bounding box size for a given geometry object. Over time, the output format of the analyze command has become misaligned and disorganized with messy printing.

This task involves cleaning up the basic printf-style printing so that columns line up neatly and the ornamental ascii table lines are properly aligned. The table lines should be rewritten to automatically expand as needed for the content being printed so it doesn't become a repeat maintenance burden in the future.

Time: <2 days

Code:

  • src/libged/analyze.c

Requirements:

  • Familiarity with C
  • Ability to compile and run MGED

[edit] EASY: Camera 360: A script to capture images while rotating the view around a scene

BRL-CAD allows the viewing angle for a scene to be set through a number of parameters. These are the azimuth, elevation, twist and also the amount of zoom for the scene. To render a scene a user first sets the view in MGED and then saves the view parameters in a BASH script. This script contains a call to the BRL-CAD ray tracing tool rt. The appropriate settings to its command line flags are written such that the images are rendered from the view set by the user in MGED.

The command for invoking rt may be called multiple times in a loop, each time carrying out a small change in the scene such as translating some geometry to achieve basic animation.

This task involves developing a bash script that changes the parameters to rt in every loop iteration such that the view camera revolves around the origin of the scene at a particular distance from it , in the XY plane. The camera should change the view in small increments such that the images are captured in small angular increments. This would allow a video to be created with the effect of walking around a model while inspecting it from all sides.

Note: that an equivalent effect could also be achieved by keeping the view steady but revolving the model gradually by 360 degrees instead.

Time: ~ 3 days

Code:

  • src/**/*.c

Requirements:

  • Familiarity with C and BASH scripting
  • Ability to compile and run MGED

[edit] EASY: Close MGED when both its windows are closed

BRL-CAD has an interactive geometry editor called MGED. It's often the starting point for beginners and allows creation and manipulation of models using commands. When MGED is invoked, then it creates 2 windows :

  • A command window
  • An OpenGL graphics window.

A user types command in the command window and views the results in the graphics window. However when the application is closed then it has a non-intuitive behavior in the sense that even if both the windows are manually closed, the MGED process is not terminated. Thus the proper way of closing it is through the exit command in the MGED command window.

This task involves fixing this behavior such that closing both the windows terminates the process properly.

Time: ~ 4 days

Code:

  • src/mged/mged.c

Requirements:

  • Familiarity with C
  • Ability to compile and run MGED

[edit] EASY: Implement parallel support for Windows

BRL-CAD works pervasively on symmetric multiprocessing (SMP) systems, i.e. computers with multiple CPUs or cores. However, support for SMP is implemented for each distinct platform. BRL-CAD runs on Windows, but presently only in a single-threaded mode.

This task involves implementing the hooks necessary to make BRL-CAD work in parallel on Windows. This can be achieved with relatively minor source code modifications to two files.

Time: <2 days

Code:

  • src/libbu/parallel.c
  • src/libbu/semaphore.c

Requirements:

  • Familiarity with C source code
  • Familiarity with compiling on Windows

[edit] MEDIUM: Decouple LIBDM from LIBGED

BRL-CAD has a 3D display manager library (LIBDM) and a geometry editor command library (LIBGED). For clean encapsulation and library management, it's desirable to keep library dependencies to a minimum. LIBGED presently makes direct calls to LIBDM for a "screengrab" command. Properly fixed, it should be possible to remove the LIBDM linkage from LIBGED's build file and the command still work as expected.

This task involves breaking the dependency of LIBGED on LIBDM by making LIBGED not directly call any LIBDM functions. To do this, LIBGED will likely need to introduce a callback mechanism in the "ged" struct so that the screengrab command can capture an image without directly calling a LIBDM function.

Time: <3 days

Code:

  • include/ged.h
  • include/dm.h
  • src/libged/screengrab.h
  • src/libged/CMakeLists.txt

Requirements:

  • Familiarity with C source code
  • Familiarity with C function callbacks

[edit] MEDIUM: Separate out LIBNMG from LIBRT

BRL-CAD has an N-Manifold Geometry (NMG) library embedded within our ray tracing (RT) library. The NMG source code is already isolated and separate but not cleanly and not into its own library.

This task involves moving the NMG source code into its own library directory and making the appropriate build system modifications so that it compiles the new library cleanly. There may be minor source code refactorings necessary to decouple the NMG code from LIBRT, but nothing major is expected.

Time: <3 days

Code:

  • include/raytrace.h
  • include/nmg.h
  • src/librt
  • src/librt/primitives/nmg

Requirements:

  • Familiarity with C source code
  • Basic familiarity with autoconf/automake/libtool build system

[edit] HARD: implement runtime detection of SSE

BRL-CAD will optionally leverage SSE instructions for some operations but SSE-support is set at compile-time. If you attempt to perform SSE instructions on non-SSE hardware, it'll basically halt the application with an illegal instruction exception.

This task involves implementing a new libbu function that reports whether SSE support is available at runtime. The most prevalent method for doing this is demonstrated by the Mesa folks where you set up an exception handler for SIGILL and attempt an SSE instruction. That's obviously a non-solution for Windows platforms, but is better than nothing and more useful than a Windows-only solution. Even better if you can handle both.

Time: <2 days

Code:

  • include/bu.h
  • src/libbu

Requirements:

  • Familiarity with C source code
  • Access to non-SSE hardware or hardware where SSE can be disabled (for testing)

[edit] HARD: Integrate hi/lo geometry wireframe modifications

BRL-CAD presently draws wireframes of geometry with a fixed level of detail. A contributor implemented support for "high" and "low" detail wireframes but their changes were to a very old version that could not be simply applied to the current source code.

This task involves identifying their source code changes (easy), isolating them (relatively easy), applying them to the current source code (maybe tricky, maybe not), documenting the new feature (trivial), and making sure everything works.

Time: <4 days

Code:

  • modified source tarball will be provided
  • src/librt/primitives/**/*.c (the *_tess() functions)

Requirements:

  • Familiarity reading and writing C source code
  • Basic familiarity with BRL-CAD's MGED

[edit] HARD: Fix Bounding Box function for BoT primitive

BRL-CAD provides functions for its geometric primitives that define a bounding box - a box that completely encloses the volume described by the primitive. Ideally, these boxes are as small as possible while still enclosing the primitive. Currently the routine for BoTs is incorrect.

This task involves studying the current code for the function rt_bot_bbox and determining what is causing the current inaccuracies (the bb command is a good way to visualize primitive bounding boxes) and making changes to produce a more optimal bounding box. The raytracing prep code in rt_bot_prep does prepare a better bounding box, so that is one place to check.

Time: <4 days

Code:

  • src/librt/primitives/bot/bot.c (the rt_bot_bbox function)

Requirements:

  • Familiarity reading and writing C source code
  • Basic familiarity with BRL-CAD's MGED

[edit] HARD: Implement a primitive UV-mapping callback

BRL-CAD provides more than two dozen types of geometry "primitives" such as ellipsoids, boxes, and cones. Every primitive is described by a collection of callback functions, for example rt_ell_bbox() returns the bounding box dimensions for an ellipsoid. One of those functions describes a UV mapping of the object's surface, which is used for things like texture and bump mapping. An example of this is rt_ell_uv() in the src/librt/primitives/ell/ell.c source file for an ellipsoid. Several of our more complex primitive types (such as BoT, NMG, and BREP/NURBS) do not presently implement a UV-mapping function leading to unexpected runtime behavior.

This task involves implementing a UV-mapping callback for any of the primitives that do not already have a functional UV-callback defined.

Time: <3 days

Code:

  • src/librt/primitives/*/*.c
  • src/librt/primitives/table.c
  • include/rtgeom.h

References:

  • en.wikipedia.org/wiki/UV_mapping

Requirements:

  • Familiarity writing C source code
  • Basic familiarity with UV-mapping

[edit] Documentation


Tasks related to creating/editing documents

[edit] EASY: Add missing documentation (for JUST ONE command)

BRL-CAD is an extensive system with more than 400 commands and more than a million pages of documentation, but there are approximately 120 commands that are entirely undocumented:

a-d archer asc2g asc2pix bot-bldxf bottest brep_cube brep_simple brickwall btclsh burst bw-a bw-d bwish c-d chan_add clutter contours d-a damdf dauto dauto2 d-bw dconv ddisp d-f dfft d-i dmod double-asc dpeak dsel dsp_add dstat d-u dwin euclid_format euclid_unformat fbgammamod f-d fence fhor f-i g-adrt g-euclid1 g-jack globe g-off i-a i-d i-f ihist imod istat jack-g kurt lowp molecule nmgmodel nmg-sgp off-g pipe pipetest pix2g pix3filter pixcount pixelswap pixembed pixfields pixfieldsep pixflip-fb pixpaste pix-spm pix-yuv plstat pyramid rawbot remapid rlesortmap rletovcr room rtcell rtexample rtfrac rtrad rtsil rtsrv script-tab sketch solshoot sphflake spltest spm-fb ssampview syn tea tea_nmg testfree texturescale torii ttcp tube txyz-pl u-a u-bw u-d u-f umod ustat vcrtorle vegitation wall wdb_example xbmtorle xyz-pl yuv-pix

This task involves writing a failed document for JUST ONE of those commands in the Docbook format. The command documentation should provide a one-sentence description, a detailed paragraph description, explanation of all available command-line options, and one or more examples on how to use the command.

Time: < 2 days

Code:

  • doc/docbook/system/man1/en/Makefile.am
  • doc/docbook/system/man1/en/*.xml

Requirements:

  • Basic familiarity with using a text editor
  • Basic familiarity writing in a tagged format (Docbook format is very similar to html) -- many examples provided
  • Ability to figure out how to use the command you're documenting (most are very simple)

[edit] EASY: Write "MGED Interface" reference document

BRL-CAD's primary geometry editor is called MGED. MGED's documentation is extensive but incomplete without a concise 1 or 2 page document that details MGED's interface.

This task involves writing an interface reference document that gives a brief descriptive overview of the key bindings, mouse bindings, and primary GUI elements. The shift grips reference should be incorporated, albeit much more concisely and organized.

Time: <2 days

References:

  • brlcad.org/wiki/Documentation
  • brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf
  • brlcad.org/w/images/8/8c/Shift_Grips_Quick_Reference_Guide.pdf
  • www.audioease.com/Pages/Altiverb/features/2small.jpg

Requirements:

  • Familiarity with word processing software
  • Basic familiarity with MGED

[edit] MEDIUM: Convert src/conv man pages to valid Docbook

BRL-CAD is in the process of converting its documentation into Docbook 4.5 format, in order to enable automatic generation of output in different formats (html, pdf, man) from a single source. This conversion includes existing UNIX man pages.

This task involves using the doclifter tool to perform a rough conversion to Docbook of all man pages in the src/conv subdirectory of the BRL-CAD source tree (about 40 files), then performing whatever manual corrections are needed to the autogenerated xml files to make them valid Docbook (some conversions have already been done and can serve as guides). The simplest way to confirm the files are successfully converted is to incorporate them into BRL-CAD's build logic for Docbook man pages and view the output using brlman and an html viewer. It is recommended to use the Emacs editor with the nxml mode in order to more easily identify and fix errors, but this is not a requirement.

Time: <4 days

References:

  • Current Docbook man pages: brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/docbook/system/
  • Docbook documentation: www.docbook.org/tdg/en/html/docbook.html
  • Doclifter conversion tool: www.catb.org/~esr/doclifter/
  • Emacs editor: www.gnu.org/software/emacs/emacs.html
  • nxml Emacs mode: www.thaiopensource.com/nxml-mode/

Requirements:

  • Basic ability to understand and work with xml files
  • Computer environment that can build BRL-CAD docs (xsltproc, autotools) and ability to set up BRL-CAD for building.

[edit] MEDIUM: Write a "BRL-CAD Commands Quick Reference" document

There is already a command quick reference for BRL-CAD's MGED geometry editing tool, but there is not a similar document for BRL-CAD's 400+ command-line commands.

This task involves writing a quick reference document similar to the MGED quick reference but for BRL-CAD commands.

Time: <3 days

References:

  • brlcad.org/wiki/Documentation
  • brlcad.org/w/images/5/52/MGED_Quick_Reference_Card.pdf

Requirements:

  • Familiarity with layout software
  • Basic familiarity with BRL-CAD

[edit] HARD: Write a "Technical Overview of BRL-CAD" document

This task involves describing everything in BRL-CAD succinctly yet comprehensively. Survey of all the major features, methodologies, and tools implemented in BRL-CAD with coverage on code maturity, library encapsulation, and tool aggregation. The document should be less than 10 pages, possibly only 1 or 2 pages, but cover multiple layers of information concisely.

Time: <4 days

References:

  • brlcad.org/d/about
  • brlcad.org/wiki/Overview

Requirements:

  • In-depth familiarity with BRL-CAD


[edit] HARD: Add missing documentation (for ALL missing)

BRL-CAD i

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.