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 while others are a little more tricky to compute.
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). There are numerous examples in our code where we compute centroids for other primtiives. The primitives that do not already have a centroid callback are itemized in following.
References:
Code:
- src/librt/primitives/table.c
- src/librt/primitives/[PRIMITIVE]/[PRIMITIVE].c
... centroid function for elliptical hyperboloids (EHY)
|
... centroid function for right hyperbolic cylinders (RHC)
|
... centroid function for gridded volumes (VOL)
|
... centroid function for N-faced polysolids (ARBN)
|
... centroid function for extruded sketches (EXTRUDE)
|
... centroid function for superellipsoids (SUPERELL)
|
... centroid function for solid polygonal meshes (NMG)
|
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. Note that this is an advanced task that might take you more than a couple hours if you don't have solid coding skills, but it's ultimately just a few lines of code. See other primitives that already implement a UV-mapping callback for reference.
References:
... UV-mapping for extruded bitmaps (EBM)
Code:
- src/librt/primitives/ebm/ebm.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
... UV-mapping for extruded sketches (EXTRUDE)
Code:
- src/librt/primitives/extrude/extrude.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
... UV-mapping for gridded volumes (VOL)
Code:
- src/librt/primitives/vol/vol.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
... UV-mapping for N-faced arbitrary polyhedrons (ARBN)
Code:
- src/librt/primitives/arbn/arbn.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
... UV-mapping for superellipsoids (SUPERELL)
Code:
- src/librt/primitives/superell/superell.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
... UV-mapping for triangle meshes (BOT)
Code:
- src/librt/primitives/bot/bot.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
... UV-mapping for solid polygonal meshes (NMG)
Code:
- src/librt/primitives/nmg/nmg.c
- src/librt/primitives/table.c
- include/rtgeom.h
|
|
Documentation and Training
Tasks related to creating/editing documents and helping others learn more about BRL-CAD
Add missing documentation (for any 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 basic documentation for JUST ONE of those commands in the Docbook XML format. The command documentation should provide a one-sentence description, a detailed paragraph description (200+ words), explanation of all available command-line options, and one or more examples on how to use the command.
Code:
- doc/docbook/system/man1/en/Makefile.am
- doc/docbook/system/man1/en/*.xml
|
Write a tutorial on compiling BRL-CAD with XCode on Mac OS X
BRL-CAD uses the CMake build system to generate outputs for a variety of platforms. It will output Makefiles, Microsoft Visual Studio build files, XCode project files, Eclipse build files and more.
This task involves generating an XCode project with our build and verifying that it successfully compiles all of BRL-CAD. Document the process on our wiki as a tutorial. Include screen shot images when referring to visual actions within XCode.
References:
|
Write a tutorial on compiling BRL-CAD with Eclipse on Linux
BRL-CAD uses the CMake build system to generate outputs for a variety of platforms. It will output Makefiles, Microsoft Visual Studio build files, XCode project files, Eclipse build files and more.
This task involves generating an Eclipse project with our build and verifying that it successfully compiles all of BRL-CAD. Document the process on our wiki as a tutorial. Include images/screen shots when referring to visual actions within Eclipse.
References:
|
Document MGED's 'saveview' command options
BRL-CAD's primary geometry editor (MGED) provides hundreds of commands. Two of those commands are the savewview and loadview commands that write current view settings out to a text file and read them back in. The saveview command provides -e -i -l and -o options, but they are not documented.
This task involves writing documentation for those missing options. Consult the source code to see what they do and add the corresponding sections into our Docbook XML doc just like we do in our other documentation files. Test compilation to make sure your XML syntax is correct.
References:
- src/libged/saveview.c
- doc/docbook/system/mann/en/*.xml
Code:
- doc/docbook/system/mann/en/saveview.xml
|
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. It should minimally include the command window, the graphics window, the raytrace control panel, the combination editor, the geometry tree view, and overview graphics window key bindings.
References:
Examples:
|
Convert 43 src/conv man pages to valid Docbook
BRL-CAD is in the process of converting its documentation in order to enable automatic generation of output in different formats (html, pdf, man) from a single source. We need to convert our existing UNIX man pages to the Docbook XML format. There is a doclifter conversion tool available to help automatically convert files, then just a little bit of cleanup is needed. This will find all of them:
find src/conv -name \*.1
The simplest way to confirm the files are successfully converted is to incorporate them into BRL-CAD's build logic (edit CMakeLists.txt) 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.
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 43 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). Add new files to the doc/docbook/system/man1/en directory (via svn add), edit the CMakeLists.txt file in that same directory, verify no errors by compiling, and make a patch.
References:
Code:
- src/conv/*.1
- doc/docbook/system/man1/en/CMakeLists.txt
- doc/docbook/system/man1/en/
|
Convert 38 src/fb man pages to valid Docbook
BRL-CAD is in the process of converting its documentation in order to enable automatic generation of output in different formats (html, pdf, man) from a single source. We need to convert our existing UNIX man pages to the Docbook XML format. There is a doclifter conversion tool available to help automatically convert files, then just a little bit of cleanup is needed. This will find all of them:
find src/fb -name \*.1
The simplest way to confirm the files are successfully converted is to incorporate them into BRL-CAD's build logic (edit CMakeLists.txt) 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.
This task involves using the doclifter tool to perform a rough conversion to Docbook of all man pages in the src/fb subdirectory of the BRL-CAD source tree (about 38 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). Add new files to the doc/docbook/system/man1/en directory (via svn add), edit the CMakeLists.txt file in that same directory, verify no errors by compiling, and make a patch.
References:
Code:
- src/fb/*.1
- doc/docbook/system/man1/en/CMakeLists.txt
- doc/docbook/system/man1/en/
|
Convert 24 other man pages to valid Docbook
BRL-CAD is in the process of converting its documentation in order to enable automatic generation of output in different formats (html, pdf, man) from a single source. We need to convert our existing UNIX man pages to the Docbook XML format. There is a doclifter conversion tool available to help automatically convert files, then just a little bit of cleanup is needed. This will find all of them:
find src/[glnrt]* -name \*.1
The simplest way to confirm the files are successfully converted is to incorporate them into BRL-CAD's build logic (edit CMakeLists.txt) 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.
This task involves using the doclifter tool to perform a rough conversion to Docbook of all man pages in the src/gtools, src/lgt, src/nirt, src/remrt, src/rt, src/rttherm, and src/tab subdirectories of the BRL-CAD source tree (about 24 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). Add new files to the doc/docbook/system/man1/en directory (via svn add), edit the CMakeLists.txt file in that same directory, verify no errors by compiling, and make a patch.
References:
Code:
- src/fb/*.1
- doc/docbook/system/man1/en/CMakeLists.txt
- doc/docbook/system/man1/en/
|
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. The sheet should minimally include the following commands:
mged, rt*, *-g, g-*, fb*, *fb, nirt, remrt, rtsrv, asc2g, g2asc, dbupgrade, pix*, *pix, *-*, brlman, benchmark
References:
|
Doxygen cleanup
BRL-CAD uses Doxygen for most API documentation but the comment blocks are not optimally set up for Doxygen output.
This task involves cleaning up the Doxygen comments in the library so that useful reports and API documentation automatically generated (correctly, completely, and cleanly). Verify/fix any Doxygen syntax. Verify/fix groups so that functions are organized neatly and all contained within a group. Provide patches that give clean (PDF) output from Doxygen.
References:
... doxygen cleanup for LIBBU
There are approximately 300 documented API function calls in LIBBU.
Code:
- include/bu.h
- src/libbu
- misc/Doxyfile
|
... doxygen cleanup for LIBBN
There are approximately 300 documented API function calls in LIBBN.
Code:
- include/bn.h
- include/plot3.h
- include/vmath.h
- src/libbn
- misc/Doxyfile
|
... doxygen cleanup for LIBWDB
There are approximately 100 documented API function calls in LIBWDB.
Code:
- include/wdb.h
- include/raytrace.h
- src/libwdb
- misc/Doxyfile
|
... doxygen cleanup for LIBRT
There are approximately 1000 documented API function calls in LIBRT.
Code:
- include/raytrace.h
- src/librt
- src/librt/primitives
- src/librt/comb
- src/librt/binunif
- misc/Doxyfile
|
|
Write a "BRL-CAD Ray Tracing Shaders" tutorial
BRL-CAD includes numerous shaders that let you specify different optical effects during ray tracing.
This task involves writing a brief tutorial that describes what shaders are and how one specifies them for geometry. How shaders are specified is already described in detail in the Introduction to MGED document.
Code:
- src/liboptical/sh_*.c (for available shader names and corresponding options)
References:
|
NURBS BibTeX reference file
BRL-CAD maintains a bibliography file that keeps track of published articles and reports pertaining to BRL-CAD, but it would be useful to have similar files that keep track of other topics. There are commonly two ways to create and maintain a .bib file. One way is manually (using any text editor) and the other is using a GUI such as JabRef. The rule of thumb is generally to use the text editor approach when building a .bib file of references that are pre-packaged (such as those often provided by publishers of journal articles) and to use a tool like JabRef when you have to create the entire entry from scratch.
This task involves creating a NURBS.bib file that documents BRL-CAD's various paper references contained in the bibliographics of the following papers (include these papers and what they reference):
Practical Ray Tracing of Trimmed NURBS Surfaces
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.7126
Direct and Fast Ray Tracing of NURBS Surfaces
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.7500
Watertight Trimmed NURBS
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.3590
The best route is probably assembly of pre-existing .bib entries from either the citeseerx website or from the sites of the journal actually publishing the article.
References:
Code:
|
Outreach and Research
Tasks related to community management, outreach/marketing, studying problems, and recommending solutions
Write solicitation for new website designer
The BRL-CAD website is in need of a design overhaul.
This task involves writing up a brief article soliciting new contributor(s) to work on designing a new website. The article needs to be detailed and specific to our particular website requirements (Drupal+Mediawiki+CSS) to ensure the contributor can design the appropriate stylesheet(s), updated graphics, and new layout. Provide a title, an image, a short summary (<200 words), and the detailed write-up (>400 words).
References:
|
Model a "B" using BRL-CAD
Create an uppercase letter "B" geometry model using BRL-CAD. You can use the mged or archer geometry editor tools or write a script. The model should be roughly 1000mm tall, about 500mm wide, and about 100mm deep. Create it using CSG or other methods, but it cannot be an imported model, polygonal mesh (BOT, NMG), or extruded bitmap (EBM).
It should be free of modeling errors (no overlaps, run "rtcheck" to verify). It should have interesting shader properties set (suggest stack+plastic+texture), default shader will not be accepted. Provide the .g geometry file and a 1024x1024 rendering at a "ae 35 25" view to show what it looks like.
References:
|
Model a "R" using BRL-CAD
Create an uppercase letter "R" geometry model using BRL-CAD. You can use the mged or archer geometry editor tools or write a script. The model should be roughly 1000mm tall, about 500mm wide, and about 100mm deep. Create it using CSG or other methods, but it cannot be an imported model, polygonal mesh (BOT, NMG), or extruded bitmap (EBM).
It should be free of modeling errors (no overlaps, run "rtcheck" to verify). It should have interesting shader properties set (suggest stack+plastic+texture), default shader will not be accepted. Provide the .g geometry file and a 1024x1024 rendering at a "ae 35 25" view to show what it looks like.
References:
|
Model a "L" using BRL-CAD
Create an uppercase letter "L" geometry model using BRL-CAD. You can use the mged or archer geometry editor tools or write a script. The model should be roughly 1000mm tall, about 500mm wide, and about 100mm deep. Create it using CSG or other methods, but it cannot be an imported model, polygonal mesh (BOT, NMG), or extruded bitmap (EBM).
It should be free of modeling errors (no overlaps, run "rtcheck" to verify). It should have interesting shader properties set (suggest stack+plastic+texture), default shader will not be accepted. Provide the .g geometry file and a 1024x1024 rendering at a "ae 35 25" view to show what it looks like.
References:
|
Model a "C" using BRL-CAD
Create an uppercase letter "C" geometry model using BRL-CAD. You can use the mged or archer geometry editor tools or write a script. The model should be roughly 1000mm tall, about 500mm wide, and about 100mm deep. Create it using CSG or other methods, but it cannot be an imported model, polygonal mesh (BOT, NMG), or extruded bitmap (EBM).
It should be free of modeling errors (no overlaps, run "rtcheck" to verify). It should have interesting shader properties set (suggest stack+plastic+texture), default shader will not be accepted. Provide the .g geometry file and a 1024x1024 rendering at a "ae 35 25" view to show what it looks like.
References:
|
Model a "A" using BRL-CAD
Create an uppercase letter "A" geometry model using BRL-CAD. You can use the mged or archer geometry editor tools or write a script. The model should be roughly 1000mm tall, about 500mm wide, and about 100mm deep. Create it using CSG or other methods, but it cannot be an imported model, polygonal mesh (BOT, NMG), or extruded bitmap (EBM).
It should be free of modeling errors (no overlaps, run "rtcheck" to verify). It should have interesting shader properties set (suggest stack+plastic+texture), default shader will not be accepted. Provide the .g geometry file and a 1024x1024 rendering at a "ae 35 25" view to show what it looks like.
References:
|
Model a "D" using BRL-CAD
Create an uppercase letter "D" geometry model using BRL-CAD. You can use the mged or archer geometry editor tools or write a script. The model should be roughly 1000mm tall, about 500mm wide, and about 100mm deep. Create it using CSG or other methods, but it cannot be an imported model, polygonal mesh (BOT, NMG), or extruded bitmap (EBM).
It should be free of modeling errors (no overlaps, run "rtcheck" to verify). It should have interesting shader properties set (suggest stack+plastic+texture), default shader will not be accepted. Provide the .g geometry file and a 1024x1024 rendering at a "ae 35 25" view to show what it looks like.
References:
|
Model new BRL-CAD Logo using BRL-CAD
The winner of the recent BRL-CAD Logo contest is a clean depiction of two interlocked components. Modeling the new Logo in BRL-CAD in CSG (without NURBS, without polygons) requires some careful arrangement, but can provide an attractive three dimensional rendering.
The output of this task would be a .g file of BRL-CAD logo. The two segments should overlap at the join, but this is your opportunity as an artist and 3D magician to come up with an interesting or faithful interpretation.
References:
|
Write BRL-CAD News article on .deb/.rpm builds
BRL-CAD's maintainer, Jordi Sayol, manages the .deb and .rpm builds. Interview the developer, obtain details on how the releases are produced, what platforms are supported, etc, and write up an article for our Community Publication Portal (CPP)
The output of this task is an article added to our CPP wiki page in a final production-quality review state.
References:
|
Write a BRL-CAD showcase article
BRL-CAD has several ongoing development activities developed by community members that showcase the power and applicability of BRL-CAD to various domains. For this task, you'd be expected to interview one or more individuals to obtain information and pictures about their project, write up a descriptive overview of their model, the goals of the project, and any interesting ancillary information that may be relevant. There are presently several candidate topics listed in our Community Publication Portal (CPP).
The output of this task is an article added to our CPP wiki page in a final draft review state.
References:
|
Design a "Commercial CAD Comparison" diagram
New users frequently ask how BRL-CAD compares to other major commercial CAD systems such as CATIA, Unigraphics/NX, Pro/ENGINEER, Solidworks, and AutoCAD. BRL-CAD has many of the same features and it would be very useful to visualize the feature overlap graphically with a diagram.
This task involves identifying core significant features of relevance and describing BRL-CAD along with the various major CAD vendors. The diagram should fit on one page.
References:
|
Investigate performance of setting thread affinity
BRL-CAD's raytrace library (LIBRT) is pervasively multithreaded using routines defined in our basic utility library (LIBBU) for detecting an using multiple CPUs/cores/threads. On Linux, BSD, or Mac OS X, you can set the affinity of a process to stay on a processor.
This task involves making minor modifications to the LIBBU parallel interface using sched_setaffinity and/or pthread_attr_setaffinity_np (or similar affinity mechanism depending on the platform) and then evaluating the performance impact using our BRL-CAD Benchmark suite ('benchmark' command).
Code:
- src/libbu/parallel.c
- src/libbu/semaphore.c
|
Determine why solids.sh fails on 64-bit
BRL-CAD has a regression test script called solids.sh that creates a bunch of primitives, renders an image of those primitives, and then compares that image to a reference image. On (most?) 64-bit platforms, the test is off by several RGB values for exactly 3 pixels.
This task involves figuring out why, exactly, this is occurring. It may be helpful to compare intermediate computation results from a 32-bit environment to see where the computations diverge, however slightly. Ultimately, the goal is to identify the cause and a recommended course of action to fix the divergence problem.
Code:
- regress/solids.sh
- src/librt
- src/liboptical
|
Investigate permuted vertex lists from g-iges + iges-g
BRL-CAD has a geometry exporter and importer for the International Graphics Exchange Standard (IGES) file format. If you run our g-iges exporter on some geometry, then run iges-g on that same geometry to import it back to BRL-CAD format, the geometry will have permuted vertex lists. Particularly for geometry already in polygonal format, such as our NMG or BoT geometry, this conversion should result in identical geometry but presently does not.
This task involves investigating why this occurs, reporting (in detail) why it occurs, and if obvious, making a recommendation on how to fix the problem.
Code:
|
Investigate GMP integration
BRL-CAD uses a fastf_t typedef for most all math operations that is usually a "double" floating point type. We would like to provide the option for resorting to exact arithmetic if possible by merely redefining fastf_t to a C++ type sufficiently overloaded to behave the same. You should be proficient with C++ operator overloading to take this task on.
This task involves testing compilation with a C++ class with overloaded operators such that vmath macro calls still work as well as a sampling of LIBBN API function calls without major changes to the original code. A perfect example case study would be creating the class then testing whether bn_dist_pt3_pt3() and bn_mat_determinant() compute correctly for values that cannot be exactly represented with floating point arithmetic.
References:
Code:
- include/vmath.h
- include/bn.h
|
Research status of compiling BRL-CAD on MINGW
BRL-CAD compiles on a number of platforms but is rarely compiled under mingw. A cygwin compilation was last successfuly performed a few years ago with relatively minor effort, but mingw hasn't been tested.
This task involves attempting to compile BRL-CAD under mingw (AFTER successfully compiling with MSVC). Follow the CMake documentation and edit our build system accordingly. Report on what fails and write up a tutorial on the BRL-CAD wiki.
References:
Code:
- CMakeLists.txt
- misc/CMake/*
|
Create an awesome screenshot
Everyone loves to see screenshots of software in action. We use screenshots in our marketing and outreach. See some of the examples below that we already have.
Create an awesome screenshot of either mged or archer. It should be graphically interesting, show wireframe and/or raytraced geometry and give some sense of capability.
References:
|
Quality Assurance
Tasks related to testing and ensuring code is of high quality
Fix single-precision floating point crash
By default, all of BRL-CAD compiles using double-precision floating point arithmetic. We provide a simple typedef, however, that converts almost the entire system over to single-precision floating point. This compilation mode was recently cleaned up and tested, but a bug was found. The problem is reproduced very simply by compiling in single precision mode and running our "rt" ray tracer tool.
To compile in single precision, edit the include/bn.h header file and change the fastf_t typedef from double to float. To reproduce the bug, compile BRL-CAD and write this out to a text file named star.view:
viewsize 2.500000000e+05;
eye_pt 2.102677960e+05 8.455500000e+04 2.934714650e+04;
viewrot -6.733560560e-01 6.130643360e-01 4.132114880e-01 0.000000000e+00
5.539599410e-01 4.823888300e-02 8.311441420e-01 0.000000000e+00
4.896120540e-01 7.885590550e-01 -3.720948210e-01 0.000000000e+00
0.000000000e+00 0.000000000e+00 0.000000000e+00 1.000000000e+00 ;
start 0;
end;
Then run rt feeding it that view script as input. This is an example how to run within the gdb debugger:
gdb path/to/bin/rt
...
(gdb) run -F/dev/X -M .cmake/share/db/star.g all < star.view
At this point, rt should crash due to an infinite recursion. A backtrace in the debugger will show lots and lots of calls to rt_shootray() and light_hit().
This task involves investigating and preventing the crash. Provide a patch that fixes the bug.
References:
Code:
- src/librt/shoot.c
- src/liboptical/sh_light.c
|
Fix closedb
BRL-CAD geometry editor application (mged) has several hundred commands including two very simple commands for opening and closing a geometry database file. While the user rarely ever needs to close the file, as all changes are always immediately saved, it can be of use to scripting applications. However, at some point in the recent past, the closedb command was horked. It's undoubtedly something very simple but we haven't bothered to look due to other priorities. You can fix it. If you run these simple steps within graphical mged, you should see how commands stop working after calling closedb:
mged> opendb test.g y
mged> make sph sph
mged> l sph
mged> closedb
mged> make sph sph
mged> opendb test.g
mged> l sph
mged> exit
Provide a patch that fixes the bug or tell us which SVN revision introduced the bug. Make sure you can reproduce the bug before claiming this task, which presumes you know how to download/install BRL-CAD from a source distribution.
Code:
|
Create geometry database with one of every primitive
BRL-CAD implements 40 different types of 2D, 3D, and non-geometric objects that get stored in a ".g" geometry database file. For numerous debugging and testing purposes, it'd be useful to have a database with all object types included. Our csgbrep procedural geometry database tool creates 21 of them. Our mged geometry editor application lets users create them manually using the "make" and "in" commands via the command-line interface.
This task involves running the csgbrep to create a starting set of objects and then creating the remaining ones manually. Provide a .g file that contains every possible object type.
References:
|
Create an utility library (LIBBU) API unit test
There are more than 300 library functions in our core LIBBU library. As a core library used by nearly every one of BRL-CAD's tools, testing those functions for correct behavior is important.
This task involves implementing a new unit test for any of LIBBU's source files that do not already have a unit test defined. The test should run all of the public functions and be hooked into our build system. We have lots of existing unit tests to follow as an example.
References:
- include/bu.h
- src/libbu/*.c
- src/libbu/tests/*.c
Code:
- src/libbu/tests/[TEST].c
- src/libbu/tests/CMakeLists.txt
... unit test for LIBBU argv.c
|
... unit test for LIBBU avs.c
|
... unit test for LIBBU backtrace.c
|
... unit test for LIBBU badmagic.c
|
... unit test for LIBBU bomb.c
|
|
Create numerics library (LIBBN) API unit test
There are more than 300 library functions in our core LIBBN library. As a core library used by nearly every one of BRL-CAD's tools, testing those functions for correct behavior is important.
This task involves implementing a new unit test for any of LIBBN's source files that do not already have a unit test defined. The test should run all of the public functions and be hooked into our build system. We have lots of existing unit tests to follow as an example.
References:
- include/bn.h
- include/plot3.h
- include/vmath.h
- src/libbn/*.c
- src/libbu/tests/*.c <-- note libbu, not libbn for examples
Code:
- src/libbn/tests/[TEST].c
- src/libbn/tests/CMakeLists.txt
... unit test for LIBBN list.c
|
... unit test for LIBBN axis.c
|
... unit test for LIBBN complex.c
|
... unit test for LIBBN qmath.c
|
... unit test for LIBBN rand.c
|
|
Create a COMPREHENSIVE unit test for bn_dist_pt3_pt3()
There are more than 300 library functions in our LIBBN numerics library. Creating a comprehensive unit test involves exhaustively exploring all possible inputs to the function, testing them for proper behavior, and characterizing the output in a PASS/FAIL fashion.
Unlike the other testing framework tasks, the goal of this task is comprehensiveness. The task must cover all possible inputs including NULL, -inf, +inf, NaN, real numbers, and other values in most if not all possible combinations.
Code:
- include/bn.h
- src/libbn/plane.c
- src/libbn/tests/CMakeLists.txt
- src/libbn/tests/bn_plane.c <-- you write this
|
Find, reliably reproduce, and report any bug in Archer
Archer is our new modeling interface and a soon to merge with our long-standing MGED geometry editor. It undoubtedly has bugs. It's your job to find one, but do so in a manner that is so obvious that one of the other devs will be able to instantly reproduce the bug given your specific instructions. Find a way to make archer crash, become unresponsive, or otherwise behave incorrectly. You will have to explore the tool with minimal documentation.
This task involves filing a bug report with verifiable and reproducible steps that clearly demonstrate the bug. It can't be a bug already reported or otherwise documented nor can it be merely behavior you don't like.
References:
|
Reproduce any 10 unconfirmed open bug reports
BRL-CAD presently has approximately 75 open bug reports of which 50 are unassigned. Read the comments and status to see if the bug has been confirmed/reproduced.
This task involves going through those reports and REPRODUCE at least 10 of the ones that have not been confirmed. When you can reproduce the issue being reported, you'll comment on the thread to state as much and attach any data you used to reproduce the crash.
References:
|
Fix documentation XML errors in doc/docbook/articles
Some of BRL-CAD's existing documentation has been converted to DocBook format, but not all of the new files pass strict XML validation. We want to make our existing pages conform strictly. The simplest way to find documents with errors is to add a CMake configuration flag when preparing to build BRL-CAD that enables a strict check when make is run. Adding this flag will cause a build failure if there's a syntax error:
-DBRLCAD_EXTRADOCS_VALIDATE=ON
Generally, the resulting error message will provide hints that can be used to identify and fix the problem. Also, once it is clear how to address one particular problem, it is likely that that problem will occur multiple times in different files. This will make the process faster once initial errors are solved.
This task involves preparing a BRL-CAD compilation environment with validation enabled, then cleaning up the DocBook XML files under the doc/docbook/articles directory (e.g., doc/docbook/articles/en/pipes.xml), fixing whatever errors arise and submitting a patch. You can build test your changes by compiling just a subset of the documentation. In your build directory (not source), you can run this:
# in your build directory
cd doc/docbook/articles
make
Once you're done, make and submit your patch:
svn diff ~/brlcad.svn/doc/docbook/articles > xmlfixes.patch
Keep track of how long this all takes you because we intend to add a lot more tasks like this one.
References:
Code:
- doc/docbook/articles/*/*.xml
|
User Interface
Tasks related to user experience research or user interface design and interaction
Design an MGED command spreadsheet
BRL-CAD's primary solid geometry modeling application is called MGED. MGED contains a comprehensive set of more than 700 commands for manipulating, viewing, and inspecting geometry. There is a need to more effectively manage those commands, characterize them all, and get a "big picture" of the command landscape so that usability may be addressed.
This task involves designing a spreadsheet that will be used to characterize all of MGED's commands.
References:
- An existing spreadsheet already being used for BRL-CAD (i.e., non-MGED) commands is available.
|
Create prototype 2D CAD drawing(s)
BRL-CAD provides limited services for drafting features including the production of 2D CAD drawings (blueprints).
This task involves designing a 2D CAD drawing prototype that effectively captures a set of design requirements and follows industry conventions. Basically, this requires identifying one or more style(s) of drawings that should be supported along with critical elements to be included on each drawing.
References:
|
Create prototype CAD GUI layout diagram
BRL-CAD's usability is notoriously complex and "expert friendly". MGED and Archer are the main geometry editors, with drastically different user interfaces.
This task involves evaluating the features provided by MGED and Archer, then designing a new GUI layout that encompasses their features while improving usability. Rationale for design decisions and layout should be provided.
References:
|
BRL-CAD's main graphical user interface, MGED, is heavily menu-driven but not exceptionally well organized. This task involves performing an exhaustive review of MGED's various menus, including temporary menus when in a given editing state, reorganizing them for logical groupings, and rewording them for clarity. It's necessary to learn the basics of the MGED interface in order to understand what the various options do.
For this task, you'll provide a description of the existing menus and mapping to a new organization including basic rationale behind any new groupings or rewording.
References:
|
Categorize all of BRL-CAD's commands into a spreadsheet
BRL-CAD is a suite of more than 400 processing tools, image tools, geometry converters, and more. There is an existing spreadsheet that characterizes all of the available commands in terms of inputs, outputs, and options, but there is insufficient characterization of BRL-CAD's commands as to how they logically group and work together.
This task involves building up a spreadsheet that lists all of our commands, describing a finite set of command categories, and characterizing all commands into those categories while filling in the spreadsheet with details for each command.
References:
- A spreadsheet template will be provided.
|
Upgrade Drupal website
A portion of the BRL-CAD website runs on Drupal, but it's out of date. Migrating to newer versions will require incrementally updating the website database per Drupal's upgrade instructions along with all of our modules. Access to a copy of our webserver files will be provided. Experience working on a command-line is a must, ideally with prior Drupal experience if you hope to complete this within a couple hours.
This task involves getting the Drupal portion of our website cleanly migrated to the latest version of Drupal. All installed modules should also be updated.
References:
|
Upgrade Mediawiki website
A portion of the BRL-CAD website runs on Mediawiki, but it's out of date. Migrating to newer versions will require incrementally updating the website database per Mediawiki's upgrade instructions along with all of our extensions. Access to a copy of our webserver files will be provided. Experience working on a command-line is a must, ideally with prior Mediawiki experience if you hope to complete this within a couple hours.
This task involves getting the Mediawiki portion of our website cleanly migrated to the latest version of Mediawiki. All installed extensions should also be updated.
References:
|
Upgrade Gallery website
A portion of the BRL-CAD website runs on Gallery, but it's out of date. Migrating to a newer version will require incrementally updating the website database per Gallery's upgrade instructions. Access to a copy of our webserver files will be provided. Experience working on a command-line is a must.
This task involves getting the Gallery portion of our website cleanly migrated to the latest version of Gallery. All images and view statistics should be preserved.
References:
|
Set up StatSVN
BRL-CAD's Subversion repository is the oldest open source repository on the planet and we love statistics. A decade ago, we used to run a little tool called StatCVS that gave pretty graphs of commit activity. When we converted to Subversion, a comparable tool didn't exist but now there are several and we want to try them out. We'll set you up with an account on our web server.
This task involves running the latest version of StatSVN on our repository, providing the output, and providing instructions for running it again so we can keep the output up to date. You may need to normalize the results if StatSVN has the same bug that StatCVS used to have if the line counts are incorrect, but hopefully not.
References:
|
Set up SvnPlot
BRL-CAD's Subversion repository is the oldest open source repository on the planet and we love statistics. A decade ago, we used to run a little tool called StatCVS that gave pretty graphs of commit activity. When we converted to Subversion, a comparable tool didn't exist but now there are several and we want to try them out. We'll set you up with an account on our web server.
This task involves running the latest version of SvnPlot on our repository, providing the output, and providing instructions for running it again so we can keep the output up to date.
References:
|
Convert Gallery to Piwigo
A portion of the BRL-CAD website runs on Gallery, but it's been difficult to maintain. We'd like to see what our gallery would look like in Piwigo. Access to a copy of our webserver files will be provided. Experience working on a command-line is a must.
This task involves getting the Gallery portion of our website cleanly migrated to Piwigo. All images should be preserved. Bonus points if you can preserve the image view counts.
References:
|
|