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, it creates 2 windows: a text-console command window and an interactive graphics window. If the user closes the text-console command window, they are left with the interactive graphics window. There is presently no way (correct us if we're wrong) to get the text-console back without restarting mged. A good way to test this is to run in classic mode and run the 'gui' command:

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, it creates 2 windows: a text-console command window and an interactive graphics window. If the user closes the text-console command window, they are left with the interactive graphics window. There is presently no way (correct us if we're wrong) to get the text-console back without restarting mged. A good way to test this is to run in classic mode and run the 'gui' command:

Revision as of 20:44, 25 November 2012

This is a list of succinct tasks that are expected to take most people less than two hours to complete. It's a great starting point for anyone interested in contributing to BRL-CAD.

The tasks are all roughly the same complexity with no prior BRL-CAD experience expected. A description is provided along with a list of references and files you'll probably need to edit. Can we make it any easier?

Getting Started

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.

We've made a really awesome virtual disk image that has everything you need included, preconfigured, and ready to be edited. Here's what you do:

Code

Tasks related to writing or refactoring code

All of the code tasks require making changes to BRL-CAD's source code. You will be expected to provide a patch file of all changes. Make sure you read your patch file before submitting it. Make sure your patch file will apply cleanly to an unmodified checkout of BRL-CAD:

Move 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. Note that this is a REALLY easy task, it is just cut-and-paste after all, so it just might take you more than a couple hours if you're inefficient with a text editor. Regardless, you must make sure you compile before and after to make sure you didn't introduce a typo because you're changing so many files.

This is a collection of tasks. Each task involves editing source code to move comments and verifying compilation wasn't broken in the process. See each entry below for details.

... move LIBBN comments

There are less than 150 API comments across 17 files in LIBBN that need to be moved. This will find most of them:

... move LIBWDB comments

ONLY move comments that have a corresponding WDB_EXPORT declaration in the include/wdb.h header AND stub in placeholder /** */ comments for any declarations in the header still lacking a comment block. ALSO, remove any 'F U N C T I O N' names that are spaced out from the comments.

Code:

include/wdb.h

src/libwdb/*.c

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. That's a fancy way of saying it crashes.

This task involves implementing a function (that will go into our LIBBU utility library) to 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 or implement a cross-platform solution. You'll implement a bu_sse_init() function that returns an error if SSE is not available at runtime.

Code:

include/bu.h

src/libbu/sse.c

Fix bounding box function for our polygonal mesh (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. You can use stl-g, obj-g, or any of our other *-g converters to import BoT geometry for testing.

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

Code:

src/librt/primitives/bot/bot.c

Make mged 'tables' command not call system()

BRL-CAD's geometry editor (MGED) provides hundreds of functions that users can call on the command line. One of our oldest commands writes data out to text files and calls the unix "sort" command to sort a list of items.. That's really bad.

This task involves replacing the three calls to system() with a call to quicksort() or any other simple in-memory sorting mechanism.

Code:

src/libged/tables.c

Separate LIBNURBS files into one class per file

BRL-CAD has a recently implemented a new library that isn't very well organized. The files for that library are a haphazard collection of classes and functions. It's a bit of a mess.

This task involves making sure there is no more than one struct or class per source file. Class/struct declarations should be in header files. Class/struct method and functions should be in source files. Headers should be fully self-sufficient and include proper #ifdef wrappers (see include/*.h for examples). Make sure new files are named to match their enclosing class/struct. Be sure to update the CMakeLists.txt build file too and test compilation.

Code:
src/libnurbs/*

Implement mutex locking for Windows

BRL-CAD implements support for running in parallel on computers with multiple CPUs or cores. However, there are lots of ways to run in parallel. BRL-CAD runs on Windows, but presently only in a single-threaded mode. To make it work in parallel, we need to define how threads acquire a mutex lock.

This task involves implementing the necessary logic to acquire and release a mutex or semaphore on Windows. You can use either, but probably want to call CreateMutex(). This requires a very minor source code modification to just one file, but make sure it works with a simple test program. Make your test program call bu_semaphore_init()+bu_semaphore_acquire()+bu_semahpore_release(), see include/bu.h for API docs.

Mark Walmsley: "Multi-Threaded Programming in C++", Springer, 2000 (although it has C++ in its title the basic functionality there is pure C)

include/bu.h

Code:

src/libbu/semaphore.c

Implement thread creation for Windows

BRL-CAD implements support for running in parallel on computers with multiple CPUs or cores. However, there are lots of ways to run in parallel. BRL-CAD runs on Windows, but presently only in a single-threaded mode. To make it work in parallel, we need to define how threads are created.

This task involves implementing the necessary logic to create a new thread in bu_parallel(). This requires a very minor source code modification to just one file, but make sure it works with a simple test program. Make your program call bu_parallel(), see include/bu.h for API docs.

Mark Walmsley: "Multi-Threaded Programming in C++", Springer, 2000 (although it has C++ in its title the basic functionality there is pure C)

include/bu.h

Code:

src/libbu/parallel.c

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 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. This task is a little tricky, so you'll need to be somewhat proficient with C if you want any chance of completing this within a couple hours.

Code:

include/ged.h

include/dm.h

src/libged/screengrab.h

src/libged/CMakeLists.txt

Implement a function to convert triangle meshes to solid polygon mesh

BRL-CAD implements numerous "primitive" 3D entity types. The Bag of Triangle (BoT) primitive implements simple triangle mesh geometry. Our N-manifold geometry (NMG) primitive implements solid polygonal mesh geometry. While we have a routine that converts an NMG to a BoT (mk_bot_from_nmg()), we do not have the reverse (mk_nmg_from_bot()).

This task implements the missing mk_nmg_from_bot() function so that the input triangle mesh is converted into the NMG data structures and stitched together appropriately.

References:

src/librt/primitives/nmg

src/librt/primitives/bot

Code:

src/libwdb/nmg.c

Close MGED when both 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 run, it creates 2 windows: a text-console command window and an interactive graphics window. When the user closes one of those windows, there is a bug. Closing the graphics window closes the command window.

This task involves fixing this behavior so that ONLY closing both windows terminates the process properly and that closing either window does not take the other along with it.

Code:

src/mged/mged.c

src/tclscripts/mged/openw.c

Add MGED key-binding to reopen the command window

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, it creates 2 windows: a text-console command window and an interactive graphics window. If the user closes the text-console command window, they are left with the interactive graphics window. There is presently no way (correct us if we're wrong) to get the text-console back without restarting mged. A good way to test this is to run in classic mode and run the 'gui' command:

This task involves adding some mechanism, perhaps a simple key binding, to the graphics window so that you can get the command window back on-demand.

Code:

src/mged/mged.c

src/tclscripts/mged/openw.c

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.

... UV-mapping for extruded bitmap objects (EBM)

... UV-mapping for extruded 2D sketch objects (EXTRUDE)

... UV-mapping for gridded volumes (VOL)

... UV-mapping for N-faced arbitrary polyhedrons (ARBN)

... UV-mapping for superellipsoids (SUPERELL)

... UV-mapping for triangle meshes (BOT)

... UV-mapping for solid polygonal meshes (NMG)

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 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 the surface area (units are mm^2). There are numerous examples in our code where we compute surface area for other primitives. The primitives that do not already have a centroid callback are itemized in following.

include/raytrace.h: See ft_surf_area callback defined in the rt_functab structure

Code:

src/librt/primitives/[PRIMITIVE]/[PRIMITIVE].c

... surface area function for elliptical hyperboloids (EHY)

... surface area function for right hyperbolic cylinders (RHC)

... surface area function for hyperboloids of one sheet (HYP)

... surface area function for polyhedron with 4 to 8 sides (ARB8)

... surface area function for N-faced polysolid (ARBN)

... surface area function for extruded bitmaps (EBM)

... surface area function for gridded volumes (VOL)

... surface area function for super ellipsoids (SUPERELL)

... surface area function for polygonal meshes (NMG)

... surface area function for triangle meshes (BOT)

... surface area function for NURBS objects (BREP)

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 while others are a little more difficult to compute.

This task involves writing a new callback function that takes an rt_db_internal object and calculates the volume (units are mm^3). There are numerous examples in our code where we compute volume for other primitives. The primitives that do not already have a volume callback are itemized in following.

... volume function for elliptical hyperboloids (EHY)

... volume function for hyperboloids of one sheet (HYP)

... volume function for superellipsoids (SUPERELL)

... volume function for extruded bitmaps (EBM)

... volume function for gridded volumes (VOL)

... volume function for triangle meshes (BOT)

... volume function for solid polygonal meshes (NMG)

... volume function for extruded sketches (EXTRUDE)

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.

This task involves writing a failed document for JUST ONE of those commands in the Docbook XML 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.

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

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 images/screen shots when referring to visual actions within XCode.

Write a tutorial on compiling BRL-CAD with Eclipse on Linux

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.

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 sytax 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.

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.

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.

... doxygen cleanup for LIBRT

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.

BibTeX reference files

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. Broadly speaking, there are two ways to create and maintain a .bib file - one is manually (using any text editor) and the other is 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. The output from each task would be a .bib file similar to BRL-CAD.bib in the doc directory.

Outreach and Research

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.

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 without using NURBS would require some careful arrangement, but would provide an attractive three dimensional rendering.

The output of this task would be a .asc file of BRL-CAD geometry (converted via g2asc) for inclusion in the db/ example directory. Optimally, the two segments would overlap at the join, but this is your opportunity as an artist and 3D magician to shine with your interpretation.

Write BRL-CAD News article on .deb/.rpm builds

BRL-CAD has a new maintainer, Jordi Sayol, for managing .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.

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.

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.

Investigate performance of setting thread affinity

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

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:

src/conv/iges

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.

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.

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.

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:

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, reproduce, confirm, and report any bug in Archer

Archer is our new modeling interface and a soon-to-be replacement for our long-standing MGED geometry editor. It undoubtedly has bugs. It's your job to find them, 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 instructions. Crashing bugs are best, but may require learning how to use 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.

Reproduce any 10 unconfirmed open bug reports

BRL-CAD presently has approximately 75 open bug reports of which 50 are unassigned.

This task involves going through those reports and REPRODUCE at least 10 of the ones that have not been confirmed. Read the comments and status to see if the bug has been confirmed/reproduced. 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.

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.

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.

Reorganize MGED menu

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.

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.

Template example title

This is a template for mentors adding new ideas. Brief background information not specific to the task is listed first. It's succinct.

This task involves ... the rest goes here. Remember, less than two hours expected for average or random contributor to do the work after reading this description. The resulting task should be directly measurable without subjective interpretation. Tell them exactly what they need to do. Be specific.