GCI Tasks

Contents

Close MGED when both windows are closed[edit]

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

Create an ISST screenshot or animation[edit]

Everyone loves to see screenshots and animations of software in action. We use both in our marketing and outreach. See some of the examples below that we already have.

Create an awesome screenshot and/or animation of our 'isst' tool in action. It's an interactive geometry viewer interface.  It should be graphically interesting and give some sense of capability.  You should import a visually complex and interesting model with LOTS of polygons and detail.

References:

Note that we have several screenshot tasks.  Note you may have to go through some or our basic MGED tutorials (see docs section on our website) just to be able to display geometry.  Finally, give others a chance if you already completed one of the other screenshot tasks. ;)

Write a BRL-CAD to RAW converter[edit]

Use the ASCII mode of the STL converter as template and change it's output format to RAW.

Template: src/conv/stl/g-stl.c

File to create: src/conv/raw/g-raw.c

Improve geometry database loading behavior[edit]

We have a nice simple little demo application that shows how to open a geometry database file:

That's all good and well, but notice the rt_dirbuild() call in that example.  That opens the ".g" file.  We want to be able to run rt_dirbuild() twice, but it presently spews loads of messages about duplicate geometry.

Your task is to fix that problem so that we can run rt_dirbuild() (or db_dirbuild()) multiple a times without a problem.  Don't just suppress the warnings... ;)

 

Create a utility library (LIBBU) API unit test ... for parse.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bu.h
  • src/libbu/parse.c
  • src/libbu/tests/*.c

Code:

  • src/libbu/tests/bu_parse.c
  • src/libbu/tests/CMakeLists.txt

Write a manual page for MGED's "brep" command[edit]

BRL-CAD's MGED geometry editor provides hundreds of commands.  One of those commands for manipulating and visualizing geometry is the "brep" command.

This task involves writing a manual page for that command in the Docbook XML format.  There are lots of examples to follow.

References:

  • doc/docbook/system/mann/en/*.xml
  • http://brlcad.org/wiki/Documentation (contains intro to mged and cheat sheets)
  • bin/mged  (you'll need to run this to use the "brep" command)
  • bin/csgbrep  (will create a slew of 'brep'/nurbs objects for the "brep" command)

Code:

  • doc/docbook/system/mann/en/brep.xml  (you write this)
  • doc/docbook/system/mann/en/CMakeLists.txt  (you edit this)

Running "make" in a build directory will compile your documentation into html and man page format so you can validate the syntax and formatting.  See http://brlcad.org/wiki/Compiling for help.

 

Implement thread affinity for BSD[edit]

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 many different platforms, you can set the affinity of a process to stay on a processor.  This potentially results in a significant performance boost due to data coherency.

This task involves making modifications to the LIBBU affinity interface using sched_setaffinity() or similar platform-specific mechanism that works on BSD for setting thread affinity.  This is a continuation of another successful GCI task, so that code can serve as a reference:

You will need to add proper function checks to our top-level CMakeLists.txt file to check for sched_setaffinity() availability.

When you're done, evaluate the performance impact using our BRL-CAD Benchmark suite ('benchmark' command) before and after (not within a VM).

This task is specific to BSD.

Submit your work as a single patch file with all file changes included.  See http://brlcad.org/wiki/Deuces for help getting started.

Create a utility library (LIBBU) API unit test ... for malloc.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bu.h
  • src/libbu/malloc.c
  • src/libbu/tests/*.c

Code:

  • src/libbu/tests/bu_malloc.c
  • src/libbu/tests/CMakeLists.txt

Compile BRL-CAD on Windows using the Borland Embarcadero Compiler[edit]

BRL-CAD builds pervasively on a number of different operating systems, hardware, and compilers.  We actively seek out new compilation environments and like to get them working as best as we can.  We regularly build with Microsoft Visual Studio (the professional one you have to pay for), GCC, and a number of other compilers.  One we have not tested is the Borland Embarcadero Compiler (only available for Windows)

This task involves attempting to compile BRL-CAD using the Borland Compiler.  You'll need to download our source code, CMake, and ICC.  Compile BRL-CAD using Embarcadero and keep notes of everything you do along the way.  You'll report back any failures and otherwise document all the steps you take.  Submit a complete build log and your notes documenting everything you did.  Join IRC to discuss your progress and let us help.

Bonus points if you make any fixes that get it working.

Resources:

Fix closedb[edit]

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:

  • src/mged/mged.c

Crash MGED reliably (#3)[edit]

BRL-CAD's primary geometry editing tool is called 'mged'.  What's more frustrating than software crashes?  We put a lot of emphasis on developing quality software so see if you can find a problem.

Find a way to crash mged reliably.  You must compile our latest Subversion sources, run mged, and keep track of steps taken that cause a crash.  If you can provide a stack trace, even better.  You must submit specific conditions and steps that will reliably and reproducibly cause a crash.

It must be a bug that is NOT already documented in our BUGS or Sourceforge bug tracker nor be a bu_bomb() graceful termination.  It might help to become minimally familiar with how to run mged as the interface is not at all newbie-friendly.

References

Crash Archer reliably (#2)[edit]

BRL-CAD's experimental geometry editing tool is code-named 'archer'.  What's more frustrating than software crashes?  We put a lot of emphasis on developing quality software so see if you can find a problem.

Find a way to crash archer reliably.  You must compile our latest Subversion sources, run archer, and keep track of steps taken that cause a crash.  If you can provide a stack trace, even better.  You must submit specific conditions and steps that will reliably and reproducibly cause a crash.

It must be a bug that is NOT already documented in our BUGS or Sourceforge bug tracker nor be a bu_bomb() graceful termination.  It might help to become minimally familiar with how to run archer as the interface is not entirely newbie-friendly.

References

Write the man page for tgf-g[edit]

Write the manual page for the tgf-g INTAVAL to BRL-CAD converter.

src/conv/intaval

Refactor unit tests for libpkg[edit]

Libpkg is a library responsible for networking and file transfer used throughout BRL-CAD. Unit tests have been implemented to ensure correct functionality. They need to be refactored to respect BRL-CAD standards.

For this task you will need to modify several C files and hook them into CMake. The unit tests need to be corrected so they return 0 only if all tests are passed and non - zero otherwise.

The pkg_close() unit test needs to have a comment regarding error cases removed. Any misspelling should be corrected as well.

Check references for example on how to hook unit tests into CMake and where can you find the libpkg unit tests and more examples.

Check code for where you need to put the tests and build logic.

References

  • Unit-tests
  • src/libbu/tests, src/libbn/tests - unit tests examples

Code

  • src/libpkg/tests 
  • src/libpkg/tests/CMakeLists.txt
  • src/libpkg/CMakeLists.txt

 

Investigate permuted vertex lists from g-iges + iges-g[edit]

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

Test and update our simulation / animation tutorial[edit]

We have a tutorial on performing a simulation: http://brlcad.org/wiki/Mged_simulation

This task involves going through that tutorial step-by-step to make sure it's accurate and updating any steps that are incorrect.  The tutorial includes three GIF animations that will need to be regenerated.

Report what all is in error, update the wiki with improved/correct information, and provide your updated animation videos here on the GCI site.

Note that you will need to either use our VM image or compile BRL-CAD with Bullet and some other dependencies installed in order to run the simulation system.

 

Generate a code coverage report (lcov+gcov)[edit]

This task involves setting up and generating an lcov code coverage analysis on BRL-CAD.  After learning how to use the tool, discuss with the developers what portion of the code will be most useful to analyze, or scan these:

  • "benchmark"
  • "make test"
  • "make regress"

Submit the results.

Categorize all of BRL-CAD's commands into a spreadsheet[edit]

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.

Add a primitive surface area function ... for elliptical hyperboloids (EHY)[edit]

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.

References:

Code:

  • src/librt/primitives/ehy/ehy.c

Reproduce any 10 unconfirmed open bug reports[edit]

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:

Create a utility library (LIBBU) API unit test ... for list.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bu.h
  • src/libbu/list.c
  • src/libbu/tests/*.c

Code:

  • src/libbu/tests/bu_list.c
  • src/libbu/tests/CMakeLists.txt

Add missing documentation (for any ONE command)[edit]

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

Implement a primitive UV-mapping callback ... for extruded bitmap objects (EBM)[edit]

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: http://en.wikipedia.org/wiki/UV_mapping src/librt/primitives/ebm/ebm.c, read the rt_*_uv() function

Create a Metaball Model and Diagram[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  We'd like to have each primitive modeled with diagramming arrows and labels.

This task involves creating a metaball and modeling the corresponding arrows/segments for all parameters.  Scalars should be dashed lines, vectors should be arrows.  Here's an example:

Make something like that for the metaball, but with different material properties.  That example put objects into a box for a particular visual effect.  See if you can get a better effect without the exterior box (you'll have to change shader properties).  Include at least 3 points in your metaball, two within proximity and one not.  Making it similar to our logo would be cool.

Submit your .g file and a ray traced rendering/diagram of the model.  This command run within mged may help:

rt -s1024 -A0.75 -c {set ambSamples=128} 

Model BRL-CAD logo in BRL-CAD (alan two)[edit]

The BRL-CAD Logo depicts two interlocked nodes. 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 that we can use for a number of purposes..

The output of this task will be a .g file of BRL-CAD logo and a rendered image. The two segments you model MUST be two or more regions, ideally hinged together (you can have center pins or not, you decide).  This is your opportunity as an artist and 3D magician to come up with an interesting yet faithful interpretation.

References:

Note that there are other logo modeling tasks and yours must start from scratch and be completely original.  If we get a hint that yours was based off of or used measurements from some other model, you will be barred.

 

This command run within MGED should help give you an interesting render:

rt -A0.75 -s1024 -c {set ambSamples=256}

Add a primitive surface area function ... for hyperboloids of one sheet (HYP)[edit]

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.

References:

Code:

  • src/librt/primitives/hyp/hyp.c

Implement a primitive centroid function ... for gridded volumes (VOL)[edit]

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: http://en.wikipedia.org/wiki/Centroid http://mathworld.wolfram.com/ include/raytrace.h: See ft_centroid callback defined in the rt_functab structure Code: src/librt/primitives/table.c src/librt/primitives/vol/vol.c

Create a Volumetric Solid Model and Diagram[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  We'd like to have each primitive modeled with diagramming arrows and labels.

This task involves creating a volumetric solid (VOL) and modeling the corresponding arrows/segments for all parameters.  Scalars should be dashed lines, vectors should be arrows.  Here's an example:

Make something like that for the VOL, but with different material properties.  That example put objects into a box for a particular visual effect.  See if you can get a better effect without the exterior box (you'll have to change shader properties).  You'll need to provide a data set for the VOL.  Use the "in" command to see what parameters are taken, and see http://brlcad.org/wiki/EBM which is the same process needed for describing one VOL slice.

Submit your .g file and a ray traced rendering/diagram of the model.  This command run within mged may help:

rt -s1024 -A0.75 -c {set ambSamples=128} 

Create a numerics library (LIBBN) API unit test ... for wavelet.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bn.h
  • src/libbn/wavelet.c
  • src/libbu/tests/*.c
  • src/libbn/tests/*.c

Code:

  • src/libbn/tests/bn_wavelet.c
  • src/libbn/tests/CMakeLists.txt

Create a Displacement Map Model and Diagram[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  We'd like to have each primitive modeled with diagramming arrows and labels.

This task involves creating a displacement map (DSP) -- aka a height field -- and modeling the corresponding arrows/segments for all parameters.  Scalars should be dashed lines, vectors should be arrows.  Here's an example:

Make something like that for the torus, but with different material properties.  That example put objects into a box for a particular visual effect.  See if you can get a better effect without the exterior box (you'll have to change shader properties).  You'll need to provide a data set for the DSP, see http://brlcad.org/wiki/DSP

Submit your .g file and a ray traced rendering/diagram of the model.  This command run within mged may help:

rt -s1024 -A0.75 -c {set ambSamples=128} 

Create NURBS regression test[edit]

BRL-CAD includes a lot of integration and regression tests where we run one of our high-level applications in a script to make sure they work and keep working.  NURBS is a boundary representation geometry format that we use for describing geometry.  We want to make sure we don't introduce changes that break our existing code.  One of our existing tools, csgbrep, will be helpful in this regard.

This task involves creating a regression test that exercises our NURBS support.  Write a script in whatever language suits you that runs our csgbrep tool.  That will create a .g file with primitives in implicit and NURBS form.  Make the script ray trace each object and compare it to the NURBS version to make sure they match.  There are lots of existing example scripts to follow.

References:

  • regress/bots.sh
  • regress/*.sh
  • bin/csgbrep

Submit your new testing script.  Be sure to include proper return value testing to make sure every command run completes as expected.

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

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:

Crash Archer reliably (#3)[edit]

BRL-CAD's experimental geometry editing tool is code-named 'archer'.  What's more frustrating than software crashes?  We put a lot of emphasis on developing quality software so see if you can find a problem.

Find a way to crash archer reliably.  You must compile our latest Subversion sources, run archer, and keep track of steps taken that cause a crash.  If you can provide a stack trace, even better.  You must submit specific conditions and steps that will reliably and reproducibly cause a crash.

It must be a bug that is NOT already documented in our BUGS or Sourceforge bug tracker nor be a bu_bomb() graceful termination.  It might help to become minimally familiar with how to run archer as the interface is not entirely newbie-friendly.

References

Add MGED key-binding to reopen the command window[edit]

 

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: sushi:~ morrison$ mged -c test.g BRL-CAD Release 7.22.0 Geometry Editor (MGED)     Fri, 24 Aug 2012 00:02:42 -0400, Compilation 6     morrison@sushi.local:/usr/brlcad/rel-7.22.0 attach (nu|X|ogl)[nu]? mged> gui 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

Document MGED's 'saveview' command options[edit]

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

Procedurally model a caffeine molecule[edit]

Model a caffeine molecule in BRL-CAD.  Model it procedurally using a script (if you don't know how to do that, just keep a log of all your mged commands).

Your model should define one or more regions and be free of modeling errors such as overlaps.  Submit a .g file, your script, and a 1024x1024 rendering.

References:

Implement a primitive UV-mapping callback ... for extruded sketches (EXTRUDE)[edit]

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: http://en.wikipedia.org/wiki/UV_mapping src/librt/primitives/extrude/extrude.c, read the rt_*_uv() function

Profile NURBS prep performance[edit]

BRL-CAD implements support for rendering of NURBS representation geometry.  If you import a solid 3DM or STEP format model into BRL-CAD, it will import as BREP/NURBS geometry.  Opening that geometry in BRL-CAD's MGED editor will tell you what objects are available and our 'rt' tool will raytrace it.  When geometry is ray traced, it first goes through a "prep" phase and then it starts shooting rays.  Our prep phase is entirely unoptimized so we'd like to know where all the time is presently being spent during prep..

This task involves importing some NURBS geometry into BRL-CAD and ray tracing that geometry with a profiler watching our prep performance.  Any profiler will do, including gprof, but a performance monitor like oprofile or the Mac "Instruments" application (or Shark) are preferred.

Learning how to use a profiler is beyond the scope of this task, so it make take you considerably longer to provide us with useful information if you've never run a profiler before.

To capture prep performance, you will need to import some fairly complex geometry.  You should be able to search google with "filetype:3dm" or "filetype:step" or find something on grabcad.com to import

Running "tops" within mged will tell you what geometry is available for rendering.

Running "rt -o file.png -s32" on the system command line (not inside mged) should minimize the ray overhead or you can specifically isolate the prep phase we care about.  Prep is the time between when rt is run where it opens a window until the first pixels are fired and pixels start filling in.

 

Write up Wiki page tutorial on our Volumetric Primitive[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  Several of the more complex primitives have a wiki page describing them in more detail with an example on how to create them.

This task involves writing up a page on the VOL primitive.  Figure out how to use it (see the "in" command), create an example input data set, and write up a wiki page on exactly what steps are needed similar to our other wiki pages:

Show how to create a VOL with at least two layers/slices.  Include images like the other examples.  Put the write-up at http://brlcad.org/wiki/VOL

 

Create numerics library (LIBBN) API unit test ... for qmath.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement the unit test in any language you like, but you'll have to bind the functions you're testing if not in C.

References:

  • include/bn.h
  • include/plot3.h
  • include/vmath.h
  • src/libbn/qmath.c
  • src/libbu/tests/*.c
  • src/libbn/tests/*.c

Code:

  • src/libbn/tests/bn_qmath.c
  • src/libbn/tests/CMakeLists.txt

Fix Visual Studio Express compilation errors[edit]

We had a GCI task to attempt compilation of BRL-CAD on Visual Studio Express, a compilation environment we'd not yet tested:

This task involves fixing the issues listed in the build log as compilation errors.  If you cannot fix all of them but work on it for hours, submit what you have completed.  A quick look through the log, though, indicates that there really are just a couple "new" issues that will take some research to properly fix.

Make sure you use our latest svn sources so that you have up-to-date error messages.  You'll submit your work as a single patch file containing all files that were modified (SVN will do this for you).  See http://brlcad.org/wiki/Deuces for help getting started.

 

Recreate the OpenGL "Gears" Demo[edit]

Model the OpenGL Gears demo in BRL-CAD.  A manual example gear is demonstrated and discussed some here:

Note that the three OpenGL gear teeth are even more simple than that example.  You're welcome to create the more complex teeth or keep them simple but you should have the gear ratios approximately accurate.

Your model should define three regions (one for each gear) and be free of modeling errors such as overlaps.  Submit a .g file, your script, and a 1024x1024 rendering.

References:

  • http://brlcad.org/wiki/Documentation (see the MGED tutorial and cheat sheets)
  • rt -s1024 -A0.75 -c {set ambSamples=128}  (will make a nice rendering)
  • rtcheck  and/or  gqa  (NO overlaps)

Continue investigating GMP integration[edit]

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 work on.  This task is a continuation of a prior GCI task (read it in full!):

http://www.google-melange.com/gci/task/view/google/gci2012/7946218

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.

Building on the previous GCI task work, take it to the next step.  Try setting a vector to 1/3, 1/3, 1/3 and 0.1, 0.1, 0.1 and get proper values to print.  Change the V3ARGS() macro if needed.  If that all works, try to get bn_dist_pt3_pt3() to work.  Report and discuss your progress.

Fix single-precision floating point crash[edit]

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:

  • man gdb
  • brlman rt

Code:

  • src/librt/shoot.c
  • src/liboptical/sh_light.c

Model an hourglass in BRL-CAD[edit]

Model an hourglass in BRL-CAD.  You must even model individual grains of "sand" (they can be bigger or other shapes).  It may help to write a script.

Your model should define one or more regions and be free of modeling errors such as overlaps.  Submit your .g file and a 1024x1024 rendering.

References:

Crash our raytracer application reliably[edit]

BRL-CAD's primary rendering tool is code-named 'rt'.  What's more frustrating than software crashes?  We put a lot of emphasis on developing quality software so see if you can find a problem.

Find a way to crash rt reliably.  You must compile our latest Subversion sources, run rt, and keep track of steps taken that cause a crash.  If you can provide a stack trace, even better.  You must submit specific conditions and steps that will reliably and reproducibly cause a crash.

It must be a bug that is NOT already documented in our BUGS or Sourceforge bug tracker nor be a bu_bomb() graceful termination.  It might help to become minimally familiar with how to run rt as the interface it is a command-line tool, but there is a manual page (run brlman rt or man rt within mged).

References

 

Create a numerics library (LIBBN) API unit test ... for mat.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bn.h
  • src/libbn/mat.c
  • src/libbu/tests/*.c
  • src/libbn/tests/*.c

Code:

  • src/libbn/tests/bu_mat.c
  • src/libbn/tests/CMakeLists.txt

Crash Archer reliably[edit]

BRL-CAD's experimental geometry editing tool is code-named 'archer'.  What's more frustrating than software crashes?  We put a lot of emphasis on developing quality software so see if you can find a problem.

Find a way to crash archer reliably.  You must compile our latest Subversion sources, run archer, and keep track of steps taken that cause a crash.  If you can provide a stack trace, even better.  You must submit specific conditions and steps that will reliably and reproducibly cause a crash.

It must be a bug that is NOT already documented in our BUGS or Sourceforge bug tracker nor be a bu_bomb() graceful termination.  It might help to become minimally familiar with how to run archer as the interface is not entirely newbie-friendly.

References

 

Create numerics library (LIBBN) API unit test ... for axis.c[edit]

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 (if not written in C). We have lots of existing unit tests to follow as an example.

You can implement the unit test in any language you like, but you'll have to bind the functions you're testing if not in C.

References:

  • include/bn.h
  • include/plot3.h
  • include/vmath.h
  • src/libbn/axis.c
  • src/libbu/tests/*.c
  • src/libbn/tests/*.c

Code:

  • src/libbn/tests/bn_axis.c
  • src/libbn/tests/CMakeLists.txt

Fix 20+ LLVM clang static analysis defects (#3)[edit]

This task involves running the LLVM Clang static analysis tool that reports defects in source code:

svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad cd brlcad mkdir .build cd .build CC=clang CXX=clang++ scan-build cmake .. -DBRLCAD_BUNDLED_LIBS=ON cd src/other make -j9 cd ../../ scan-build make (may be able to use -j flag here as well, haven't tried yet)

scan-build: 3147 bugs found. scan-build: Run 'scan-view /tmp/scan-build-2012-11-29-4' to examine bug reports.

scan-view /tmp/scan-build-2012-11-29-4

Once you run the static analysis, fix 20 or more of the defects listed.  Submit your changes as a single patch file, make sure to test compilation, and re-run the static analysis to make sure they're really fixed.  See http://brlcad.org/wiki/Deuces for help getting started.

It's often easier and faster to fix entire files or types of defects at once.  If you do this and find yourself spending more than a few hours, let us know and we'll consider creating additional follow-up tasks.

Find, reliably reproduce, and report any bug in Archer[edit]

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:

Implement bounding box function for our polygonal mesh (BoT) primitive[edit]

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.

Implementing a bounding box on a polygonal mesh is REALLY easy.  Just iterate over all the vertices and keep growing the box extents to encompass new points.

Code:

  • src/librt/primitives/bot/bot.c

Create a utility library (LIBBU) API unit test ... for hash.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bu.h
  • src/libbu/hash.c
  • src/libbu/tests/*.c

Code:

  • src/libbu/tests/bu_hash.c
  • src/libbu/tests/CMakeLists.txt

Create a ray-trace library (LIBRT) API unit test ... for inmem databases[edit]

It looks like there is a memory leak in the inmem database handling.  Write a test which repeatedly opens and closes inmem databases and checks the memory consumption while doing this.

Create a numerics library (LIBBN) API unit test ... for qmath.c[edit]

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 (if written in C). We have lots of existing unit tests to follow as an example.

You can implement this task in any language you like, but you'll have to bind all of the functions you test.

References:

  • include/bn.h
  • src/libbn/qmath.c
  • src/libbu/tests/*.c
  • src/libbn/tests/*.c

Code:

  • src/libbn/tests/bu_qmath.c
  • src/libbn/tests/CMakeLists.txt

Procedurally model a gemstone (e.g., a diamond)[edit]

Model a diamond in BRL-CAD.  Model it procedurally using a script (if you don't know how to do that, just keep a log of all your mged commands).  Your gemstone tool should produce a standard "cut" pattern.

Your model should define one or more regions and be free of modeling errors such as overlaps.  Submit a .g file, your script, and a 1024x1024 rendering.

References:

Fix 20+ LLVM clang static analysis defects (#2)[edit]

This task involves running the LLVM Clang static analysis tool that reports defects in source code:

svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad cd brlcad mkdir .build cd .build CC=clang CXX=clang++ scan-build cmake .. -DBRLCAD_BUNDLED_LIBS=ON cd src/other make -j9 cd ../../ scan-build make (may be able to use -j flag here as well, haven't tried yet)

scan-build: 3147 bugs found. scan-build: Run 'scan-view /tmp/scan-build-2012-11-29-4' to examine bug reports.

scan-view /tmp/scan-build-2012-11-29-4

Once you run the static analysis, fix 20 or more of the defects listed.  Submit your changes as a single patch file, make sure to test compilation, and re-run the static analysis to make sure they're really fixed.  See http://brlcad.org/wiki/Deuces for help getting started.

It's often easier and faster to fix entire files or types of defects at once.  If you do this and find yourself spending more than a few hours, let us know and we'll consider creating additional follow-up tasks.

Crash MGED reliably (#2)[edit]

BRL-CAD's primary geometry editing tool is called 'mged'.  What's more frustrating than software crashes?  We put a lot of emphasis on developing quality software so see if you can find a problem.

Find a way to crash mged reliably.  You must compile our latest Subversion sources, run mged, and keep track of steps taken that cause a crash.  If you can provide a stack trace, even better.  You must submit specific conditions and steps that will reliably and reproducibly cause a crash.

It must be a bug that is NOT already documented in our BUGS or Sourceforge bug tracker nor be a bu_bomb() graceful termination.  It might help to become minimally familiar with how to run mged as the interface is not at all newbie-friendly.

References

Write article on BRL-CAD's code hardening efforts[edit]

We've been working for several years on "code hardening", improving the quality of BRL-CAD's source code through a variety of best practices and code cleanup efforts.

This task has you write an article that succinctly summarizes all of our efforts.  You'll need to become familiar with our HACKING file as well as read up on our various hardening efforts. You're welcome to ask our devs questions over IRC for more information too.

Include at least one picture.  Article should be 300-900 words long and be fully proof-read before submitting (check for grammar and spelling mistakes, please).

Resources:

 

Create a Pipe Model and Diagram[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  We'd like to have each primitive modeled with diagramming arrows and labels.

This task involves creating a pipe (PIPE) and modeling the corresponding arrows/segments for all parameters.  Scalars should be dashed lines, vectors should be arrows.  Here's an example:

Make something like that for the PIPE, but with different material properties.  That example put objects into a box for a particular visual effect.  See if you can get a better effect without the exterior box (you'll have to change shader properties).  Make your pipe have at least one bend and two straight segments.

Submit your .g file and a ray traced rendering/diagram of the model.  This command run within mged may help:

rt -s1024 -A0.75 -c {set ambSamples=128} 

Generate a code coverage report (lcov+gcov)[edit]

This task involves setting up and generating an lcov code coverage analysis on BRL-CAD.  After learning how to use the tool, discuss with the developers what portion of the code will be most useful to analyze.  Some possible report suggestions include:

  • "benchmark"
  • "make test"
  • "make regress"

 

Write the man page for raw-g[edit]

Write the manual page for the raw-g RAW to BRL-CAD converter.

src/conv/raw

Create step-g integration/regression test[edit]

BRL-CAD includes a lot of integration and regression tests where we run one of our high-level applications in a script to make sure they work and keep working.  STEP is a geometry file format.  We have a step-g geometry importer.

This task involves creating a test for our step-g importer.  You'll need to make or find a small usable, license-compatible, input STEP file.  You'll create a test in whatever language you like that runs step-g and verifies that the import completed successfully.  There are lots of examples to follow.

References:

  • regress/bots.sh
  • regress/*.sh

Submit your new regression test script. Be sure to properly check the return code of all commands run to make sure every command completes successfully.

Procedurally model a gear[edit]

Model a gear in BRL-CAD.  Model it procedurally using a script.  Your program should accept parameters for defining the size of the gear, number of teeth, and teeth size.  A manual example gear is demonstrated and discussed some here:

Your model should define one or more regions and be free of modeling errors such as overlaps.  Submit a .g file, your script, and a 1024x1024 rendering.

References:

Fix Visual Studio Express compilation warnings[edit]

We had a GCI task to attempt compilation of BRL-CAD on Visual Studio Express, a compilation environment we'd not yet tested:

This task involves fixing a portion of the compilation warnings.  If you cannot fix all of them but work on it for hours, submit what you have completed.  You should fix at least 10% of the warnings reported, but talk with us on IRC throughout your progress so we can gauge the level of effort.

Make sure you use our latest svn sources so that you have up-to-date warning messages.  You'll submit your work as a single patch file containing all files that were modified (SVN will do this for you).

Note that we have a SEPARATE task to fix the errors, so this task just focuses on the warnings: http://www.google-melange.com/gci/task/view/google/gci2012/8009222

Create a Solid of Revolution Model and Diagram[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  We'd like to have each primitive modeled with diagramming arrows and labels.

This task involves creating a solid of revolution (REVOLVE) and modeling the corresponding arrows/segments for all parameters.  Scalars should be dashed lines, vectors should be arrows.  Here's an example:

Make something like that for the REVOLVE, but with different material properties.  That example put objects into a box for a particular visual effect.  See if you can get a better effect without the exterior box (you'll have to change shader properties).  Note that you'll need to create a 2D sketch to be revolved which you can create via dxf import, manually with our sketch editor, or via http://brlcad.org/wiki/Sketch

Submit your .g file and a ray traced rendering/diagram of the model.  This command run within mged may help:

rt -s1024 -A0.75 -c {set ambSamples=128} 

Implement thread affinity for Windows[edit]

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 many different platforms, you can set the affinity of a process to stay on a processor.  This potentially results in a significant performance boost due to data coherency.

This task involves making modifications to the LIBBU affinity interface using SetThreadAffiniityMask() or somesimilar platform-specific mechanism that works on Windows for setting thread affinity.  This is a continuation of another successful GCI task, so that code can serve as a reference:

You will need to add proper function checks to our top-level CMakeLists.txt file to check for SetThreadAffinityMask() availability.

When you're done, evaluate the performance impact using our BRL-CAD Benchmark suite ('benchmark' command) before and after (not within a VM).

This task is specific to Windows.

Submit your work as a single patch file with all file changes included.  See http://brlcad.org/wiki/Deuces for help getting started.

Integrate and test centroid function for Extruded Bitmaps (EBM)[edit]

This is an extension of a previous GCI task:

This task involves taking the patch from that task, applying it, and verifying that it calculates the centroid correctly.  Hook it into the MGED 'analyze' command and demonstrate that it calculates centroid correctly by comparing a calculated result with a known result.  Also verify via the gqa command with at least three different parameterizations.

BRL-CAD has a geometry editor called MGED.  MGED has a command called "analyze" that will report various calculations on primitives including plane equations, surface area, volume, centroids, etc.  The "gqa/g_qa" command will also calculate volume and centroids.  See the manual page to both for more information (e.g., brlman gqa), but you'll use those to to verify the centroid.

To get the analyze command to work, you may need to edit that command and have it call the primitive's volume function.  There are several examples to follow.

Code:

  • src/libged/analyze.c

Provide a patch for any changes you make to analyze and any changes/corrections to the original GCI patch.  Also provide output from gqa, analyze, and any manual testing that shows the results are correct.

Integrate and verify triangle mesh (BOT) surface area function[edit]

This is a follow-on task to http://www.google-melange.com/gci/task/view/google/gci2012/7968224

It's a two-part task:

1) Ensure that the function that was implemented in that task is properly hooked into our MGED analyze command.  MGED is BRL-CAD's geometry editor.  The analyze command reports a slew of information about primitive objects including aspects like surface area, volume, centroid, and more.  This probably amounts to adding just one or two lines and there are lots of examples to follow.

2) Verify and validate that the surface area is correct by creating an BOT with specific known dimensions and demonstrating that the analyze command reports that value.  The "in" command will interactively create an ARB8 (a box) for you and the "facetize" command will turn it into a BOT for you.

You'll probably end up running mged and modifying this code:

src/libged/analyze.c

Submit you changes as a single patch file, see http://brlcad.org/wiki/Patches for help.  Also submit output from the analyze command (text) showing that it worked.

Integrate and test volume function for Hyperboloids of One Sheet (HYP)[edit]

This is an extension of a previous GCI task:

This task involves taking the patch from that task, applying it, and verifying that it calculates the volume correctly.  Hook it into the MGED 'analyze' command and demonstrate that it calculates volume correctly by comparing a calculated result with a known result.  Also verify via the gqa command with at least three different parameterizations.

BRL-CAD has a geometry editor called MGED.  MGED has a command called "analyze" that will report various calculations on primitives including plane equations, surface area, volume, centroids, etc.  The "gqa/g_qa" command will also calculate volume and centroids.  See the manual page to both for more information (e.g., brlman gqa), but you'll use those to to verify the volume.

To get the analyze command to work, you may need to edit that command and have it call the primitive's volume function.  There are several examples to follow.

Code:

  • src/libged/analyze.c

Provide a patch for any changes you make to analyze and any changes/corrections to the original GCI patch.  Also provide output from gqa, analyze, and any manual testing that shows the results are correct.

Extend existing "BRL-CAD Ray Tracing Shaders" tutorial with a texture example (Windows)[edit]

This is a follow-on to a previously completed GCI task:

http://www.google-melange.com/gci/task/view/google/gci2012/7994216

Your task is to review, extend, and "finish" the tutorial.  First, make sure it's accurate and clear, correcting any issues you find.  Next, add another sphere rendering in section 6 after the dark blue sphere one explaining that we made it glass and most of the light is passing through, so it needs to be rendered on a lighter background (rt -W).  Then, change the other two renderings in section 7 to also be on a white background.

Finally, add one more section to give a stack shader example that applies a texture.  Textures are raw data files that must be in our "pix" format.  They can be in external files, but better is to import them into the geometry file.  We provide several pix files in an install, so we can use one of those as an example to work with.  Find and use the m35.pix image.

In the tutorial, you'll import the image with something like this (maybe exactly this, but "help bo" to be sure): bo -i u c m35.pix /path/to/m35.pix

You'll then be able to reference the "m35.pix" object as the texture, apply a stack shader with  plastic.

You may run into problems, so be prepared to talk about them and incorporate a clean path into the tutorial (and perhaps talk about common pitfalls/misunderstandings).

Write a wiki tutorial on how to create a polygonal mesh (NMG) manually[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  Several of the more complex primitives have a wiki page describing them in more detail with an example on how to create them.

This task involves writing up a page on the NMG polygonal mesh primitive.  Figure out how to use it (not a simple task, will require some trial and error), create an example input, and write up a wiki page on exactly what steps are needed similar to our other wiki pages:

Note the "facetize" command in mged will convert an existing object into NMG format.  The get/put commands should help from there like the sketch tutorial.

Show how to create an NMG cube or wedge or similar simple shape.  Include images like the other examples.  Put the write-up at http://brlcad.org/wiki/NMG

 

 

Integrate and test volume function for Hyperbolic Cylinders (RHC)[edit]

This is an extension of a previous GCI task:

This task involves taking the patch from that task, applying it, and verifying that it calculates the volume correctly.  Hook it into the MGED 'analyze' command and demonstrate that it calculates volume correctly by comparing a calculated result with a known result.  Also verify via the gqa command with at least three different parameterizations.

BRL-CAD has a geometry editor called MGED.  MGED has a command called "analyze" that will report various calculations on primitives including plane equations, surface area, volume, centroids, etc.  The "gqa/g_qa" command will also calculate volume and centroids.  See the manual page to both for more information (e.g., brlman gqa), but you'll use those to to verify the volume.

To get the analyze command to work, you may need to edit that command and have it call the primitive's volume function.  There are several examples to follow.

Code:

  • src/libged/analyze.c

Provide a patch for any changes you make to analyze and any changes/corrections to the original GCI patch.  Also provide output from gqa, analyze, and any manual testing that shows the results are correct.

Integrate and test centroid function for polyhedron with 4 to 8 sides (ARB8)[edit]

This is an extension of a previous GCI task:

This task involves taking the patch from that task, applying it, and verifying that it calculates the centroid correctly.  Hook it into the MGED 'analyze' command and demonstrate that it calculates centroid correctly by comparing a calculated result with a known result.  Also verify via the gqa command with at least two different parameterizations for each: arb8, arb7, arb6, arb5, and arb4.

BRL-CAD has a geometry editor called MGED.  MGED has a command called "analyze" that will report various calculations on primitives including plane equations, surface area, volume, centroids, etc.  The "gqa/g_qa" command will also calculate volume and centroids.  See the manual page to both for more information (e.g., brlman gqa), but you'll use those to to verify the centroid.

To get the analyze command to work, you may need to edit that command and have it call the primitive's volume function.  There are several examples to follow.

Code:

  • src/libged/analyze.c

Provide a patch for any changes you make to analyze and any changes/corrections to the original GCI patch.  Also provide output from gqa, analyze, and any manual testing that shows the results are correct.

Integrate and test centroid function for Hyperboloids of One Sheet (HYP)[edit]

This is an extension of a previous GCI task:

This task involves taking the patch from that task, applying it, and verifying that it calculates the centroid correctly.  Hook it into the MGED 'analyze' command and demonstrate that it calculates centroid correctly by comparing a calculated result with a known result.  Also verify via the gqa command with at least three different parameterizations.

BRL-CAD has a geometry editor called MGED.  MGED has a command called "analyze" that will report various calculations on primitives including plane equations, surface area, volume, centroids, etc.  The "gqa/g_qa" command will also calculate volume and centroids.  See the manual page to both for more information (e.g., brlman gqa), but you'll use those to to verify the centroid.

To get the analyze command to work, you may need to edit that command and have it call the primitive's volume function.  There are several examples to follow.

Code:

  • src/libged/analyze.c

Provide a patch for any changes you make to analyze and any changes/corrections to the original GCI patch.  Also provide output from gqa, analyze, and any manual testing that shows the results are correct.

Add missing documentation for any one command (#7)[edit]

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


NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.


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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

 

Fix some LLVM Clang compilation warnings[edit]

This is a follow-on task to a previous attempt to build BRL-CAD with the LLVM compiler:

http://www.google-melange.com/gci/task/view/google/gci2012/8023206

That task encountered a number of warnings and we like to fix our warnings as a matter of code quality, standards conformance, and portability.  Looking at the log, most are pretty easy warnings to address but care must be taken to quell the warnings without suppressing the false positives in a bad way.

Your task is to fix some of the warnings, at least 20 of them.  Keep track of how long you work on them and we may create additional tasks accordingly for your efforts.  You'll submit your work as a single patch file.  See http://brlcad.org/wiki/Compiling for help.

Note that the %V format specifier is valid to our functions and the 'inline' keyword is intentinoal.  Both need to be handled at the cmake build sysstem level, not by removing them from code or changing them.  If you don't know what that means, ignore those warnings.

Submit a log of the warning messages that you fixed (since they'll obviously not be there if your patch is appiled).  Copy-paste them and the preceding compile line verbatim from a "make VERBOSE=1" compilation.

As there are multiple warning-fix tasks, make sure you're compiling with up-to-date sources and are able to compile successfully before claiming this task.

Write a C tutorial that creates a triangle mesh (BOT) manually[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters and all of them can be programmatically created within C code.

This task involves writing up a very simple example program that creates an example BOT triangle mesh object in C.  Figure out how to use it and create a simple shape like a wedge or a box (at least one face should have more than three sides).

References:

  • src/proc-db/wdb_example.c
  • src/libwdb/bot.c
  • include/wdb.h
  • brlman libwdb

Code:

  • src/proc-db/CMakeLists.txt  <-- you enable your program here
  • src/proc-db/botmesh.c  <-- you write this

Provide a single patch file with your program and build system changes.  See http://brlcad.org/wiki/Patches for help.

Find and Fix 5 spelling mistakes in at least 40 different files (#2)[edit]

BRL-CAD is huge.  Thousands of files spread across 165 directories.  Maintaining a high quality of source code and documentation is a never ending task, but one anyone can help with.

Sound's easy, but you might be surprised because you need to ignore all of the source code and function variables that will easily trip up any automatic spell-check program.  You basically only care about spelling mistakes within comments.  Even for our documentation, much of it is formatted in xml and you have to ignore all of the xml tags.

This task involves finding and fixing simple spelling mistakes.  To complete the task, you need to find 5 or more different spelling mistakes in at least 40 different files.  You have to fix all occurrences of the spelling mistake across all those files.  Make sense?

Remember to check and fix all occurrences of the mistakes in all 40+ files, make and submit it as a patch file.

BE SURE TO HAVE UP-TO-DATE SOURCES!!! We find and fix spelling mistakes on a daily basis and throughout the day.  You have to find mistakes that are not already fixed or reported.

To clarify:

  • 1 mistake in 7 different files counts as: 1 and 7
  • 20 mistakes in 2 files counts as: >10 and 2
  • 5 mistakes across 20 files counts as: 5 and >10
  • You need to find: >=5 mistakes AND >=40 files

ADD MISSING DOCUMENTATION FOR ANY ONE COMMAND (#10)[edit]

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

NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.

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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

Create test for mutex/semaphore locking[edit]

This is a follow-on of a previous GCI task:

Your task is to test whether that semaphore/mutex locking actually works correctly.  Write a small test program that attempts to acquire a lock from two or more bu_parallel() threads.  Make sure to test a contention case where a lock is acquired and another thread requests it.

You can submit this as a partial unit test for semaphore.c by adding a new test file similar to several other existing files.  You can write the test on any platform.

Code:

  • src/libbu/tests/CMakeLists.txt
  • src/libbu/tests/bu_semaphore.c  <-- you write this

Create prototype 2D Drawing Redux[edit]

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.  The prototype MUST capture a set of design requirements and follows industry conventions.

If you've never seen a real blueprint drawing before, then this task might be too hard for you.  Your result needs to refer to ISO 128 and/or ASME Y14.41 or other standard drawing elements. 

Basically, identifying a style of drawing that we should support including pointing out the critical elements to be included on each drawing, their location, size, placement, etc.

References:

Note that this is a "redo" of a previous GCI task.  Read the discussion thread and his work to help ensure you don't make similar mistakes. ;-)

http://www.google-melange.com/gci/task/view/google/gci2012/7985229

Integrate and verify polyhedron (ARB8) surface area function[edit]

This is a follow-on task to http://www.google-melange.com/gci/task/view/google/gci2012/8028203

It's a two-part task:

1) Ensure that the function that was implemented in that task is properly hooked into our MGED analyze command.  MGED is BRL-CAD's geometry editor.  The analyze command reports a slew of information about primitive objects including aspects like surface area, volume, centroid, and more.  This probably amounts to adding just one or two lines and there are lots of examples to follow.

2) Verify and validate that the surface area is correct by creating an ARB8 with specific known dimensions and demonstrating that the analyze command reports that value.  The "in" command will interactively create an arb8 for you.

You'll probably end up running mged and modifying this code:

  • src/libged/analyze.c

Submit you changes as a single patch file, see http://brlcad.org/wiki/Patches for help.  Also submit output from the analyze command (text) showing that it worked.

 

Create primitive regression test[edit]

BRL-CAD includes an extensive regression testing system to help detect unexpected changes. A previous GCI task created a geometry database of every primitive.

This task builds on that work to turn that example geometry into a useful test case.  Add the geometry to our example databases:

  • regress/CMakeLists.txt  <-- you'll edit this to add your new test
  • regress/*.sh  <-- you'll write one of these

The test you create can be pretty much anything, but it needs to examine every object in the database (e.g., use mged 'ls' command and iterate) and perform some action on them.  Feel free to suggest your test before spending time to write it.

You can write the test in any language you want.  Submit your changes as a single patch file with all changes.  See http://brlcad.org/wiki/Patches for help.

This is a continuation of this task:

http://www.google-melange.com/gci/task/view/google/gci2012/7985226

 

Clean up and add new example geometry database[edit]

BRL-CAD includes several dozen example geometry database files.  A previous GCI task created a geometry database of every primitive.

This task builds on that work to clean it up, make sure it's really complete, and add it to our collection.  There may be external files missing that need to be recreated and there may be a couple primitives that need to be created.

This task should create a single combination that includes all primitives in a scene together.  See the 'oed' tutorial.

Add the geometry to our example databases:

  • db/CMakeLists.txt  <-- you'll edit this to add the new geometry file
  • db/*.asc  <-- you'll add a new one of these
  • brlman g2asc

Submit the geometry as a single patch file with all changes.  See http://brlcad.org/wiki/Patches for help.

This is a continuation of this task:

http://www.google-melange.com/gci/task/view/google/gci2012/7985226

 

Fix hyperboloid of one sheet raytracing bug[edit]

One of our GCI tasks recently uncovered unexpected behavior, a bug, when raytracing hyperboloids that have other objects subtracted.

Your task is to figure out why, report on the cause, and devise a fix.  This "should" be a relatively straight-forward walk through our ray tracing code with a debugger.

How to reproduce, open the geometry file submitted for the previous task, attempt to raytrace  the shape.r object:

B shape.r

rt -W

Note that we were not able to reproduce the error in isolation.  If we create a hyperboloid in mged (make hyp hyp).  Create a sphere in mged (make sph sph).  Subtract the sphere from the hyperboloid (r hyp.r u hyp - sph).  Redraw (B hyp.r) and render (rt -W), the bug does not present itself.

Here is the GCI task in question:

http://www.google-melange.com/gci/task/view/google/gci2012/7985246

 

Fix GCC 4.8 compilation[edit]

This is a follow-on task to a previous attempt to build BRL-CAD with the GCC 4.8 compiler:

http://www.google-melange.com/gci/task/view/google/gci2012/7982223

That task encountered a couple errors that stopped the compilation.  Looking at the log, they are pretty easy errors/warnings and one looks like a bonafide bug that was detected.

Your task is to fix the compile correctly and get it to complete successfully.  You'll submit your work as a single patch file that either fixes the warnings/errors (we consider warnings as errors).  See http://brlcad.org/wiki/Compiling for help.

 

Test polygonal mesh conversion function[edit]

This is a follow-on of a previous GCI task:

http://www.google-melange.com/gci/task/view/google/gci2012/8031202

That task involved implementing a function that converts triangle mesh geometry to polygonal mesh format.

This task involves verifying and validating the implementation that was provided.  Create a unit test program that uses the new function and demonstrate that it works (or doesn't) using a simple cube.  You can create a cube with "make box rpp" and the facetize command.  Create a bot (triangle mesh) cube and show that the function will turn it into an equivalent nmg.  This program may help write a test case:

http://brlcad.org/wiki/Example_Application

  

Investigate and fix an isolated bug (GED 'draw' crash)[edit]

We have isolated a bug that crashes.  It shouldn't crash.  Figure out why and fix it.

Here is a simple program that demonstrates the bug:

http://brlcad.org/tmp/ged_draw_crash.c

Build BRL-CAD and install it.  Figuring out how to compile and run without installing is an exercise for the reader, but the example provided in following assumes that approach.

Compile the above program.  You will need to point it to the appropriate headers and library, but something like this will work from a source directory with a .cmake build directory contained therein:

gcc -I.build/include -Isrc/other/tcl/generic ged_draw_crash.c -R.cmake/lib -L.cmake/lib  -lged -lbu -ggdb

gdb --args ./a.out

gdb> run

It should crash inside the ged_draw() function due to a null pointer dereference.  Figure out specifically WHY it's crashing, report back here, and fix the code so it does not crash.

You can use any development environment to debug this problem, but you must be able to compile BRL-CAD and reproduce the task in order to claim the bug.  Just reporting back that it doesn't crash for you or that you couldn't figure out how to compile it isn't useful.

Submit a single patchfile to LIBGED that fixes the crash while still providing reasonable behavior.  See http://brlcad.org/wiki/Patches for help making a patch.

Add missing documentation for any one command (#6)[edit]

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

NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.

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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

 

Add missing documentation for any one command (#3)[edit]

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

NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.

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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

 

Write a wiki tutorial on how to create a triangle mesh (BOT) manually[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters.  Several of the more complex primitives have a wiki page describing them in more detail with an example on how to create them.

This task involves writing up a page on our BOT "Bag of Triangles" mesh primitive.  Figure out how to use it (not a simple task, will require some trial and error), create an example input, and write up a wiki page on exactly what steps are needed similar to our other wiki pages:

Note the "facetize" command in mged will convert an existing object into BOT format.  The get/put commands should help from there like the sketch tutorial.  Importing geometry will also bring in BoT objects.

Show how to create a BoT cube or wedge or similar simple shape.  Include images like the other examples.  Put the write-up at http://brlcad.org/wiki/BOT

 

Write a C tutorial that creates a polygonal mesh (NMG) manually[edit]

BRL-CAD provides a couple dozen distinct primitives.  Each primitive is defined by a set of parameters and all of them can be programmatically created within C code.

This task involves writing up a very simple example program that creates an example NMG polygonal mesh object in C.  Figure out how to use it and create a simple shape like a wedge or a box (at least one face should have more than three sides).

References:

Code:

  • src/proc-db/CMakeLists.txt  <-- you enable your program here
  • src/proc-db/manifold.c  <-- you write this

Provide a single patch file with your program and build system changes.  See http://brlcad.org/wiki/Patches for help.

 

Add missing documentation for any one command (#9)[edit]

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

NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.

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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

 

Find and Fix 20 spelling mistakes in at least 5 different files (#2)[edit]

BRL-CAD is huge.  Thousands of files spread across 165 directories.  Maintaining a high quality of source code and documentation is a never ending task, but one anyone can help with.

Sound's easy, but you might be surprised because you need to ignore all of the source code and function variables that will easily trip up any automatic spell-check program.  You basically only care about spelling mistakes within comments.  Even for our documentation, much of it is formatted in xml and you have to ignore all of the xml tags.

This task involves finding and fixing simple spelling mistakes.  To complete the task, you need to find 20 or more different spelling mistakes in at least 5 different files.  You have to fix all occurrences of the spelling mistake across all those files.  Make sense?

Remember to check and fix all occurrences of the mistakes in all 5+ files, make and submit it as a patch file.

BE SURE TO HAVE UP-TO-DATE SOURCES!!! We find and fix spelling mistakes on a daily basis and throughout the day.  You have to find mistakes that are not already fixed or reported.

To clarify:

  • 1 mistake in 7 different files counts as: 1 and 7
  • 20 mistakes in 2 files counts as: >10 and 2
  • 5 mistakes across 20 files counts as: 5 and >10
  • You need to find: >=20 mistakes AND >=5 files

Create 3D Fresnel lens with matching specific measurements[edit]

Model a specific Fresnel lens in BRL-CAD.  Use the measurements in this paper:

http://www.osti.gov/bridge/servlets/purl/120927-64DD1o/webviewable/120927.pdf

See figure 3.2 (page 13) for an overview of what it looks like.  Try making it exactly to those specifications, which are itemized in table 3.2 (page 12) on the preceding page.  See if you can model that perfectly.  Bonus points if you can match the slant on the edge of each Fresnel facet (notice the starting and ending radius values are different in table 3.2).  Model all 17 facets.

Your model should define a single region and be free of modeling errors such as overlaps.  Submit your .g file and a 1024x1024 rendering.

References:

  • http://brlcad.org/wiki/Documentation (see the MGED tutorial and cheat sheets)
  • rt -s1024 -A0.75 -c {set ambSamples=128}  (will make a nice rendering)
  • rtcheck  (checks for overlaps)

This is a continuation of http://www.google-melange.com/gci/task/view/google/gci2012/8049208

Add missing documentation for any one command (#5)[edit]

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

NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.

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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

 

Add missing documentation for any one command (#8)[edit]

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

NOTE!  Some may have been completed, so check our other finished GCI tasks or ask us.

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 summary 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/CMakeFiles.txt
  • doc/docbook/system/man1/en/*.xml

How to get started:

You'll need a source checkout, see http://brlcad.org/wiki/Compiling You can use any of the existing xml files in that directory as a template starting point (see doc/docbook/articles/en/TEMPLATE.xml for Docbook examples) Learn the tool, find its source, write up the documentation You'll need to run svn add doc/docbook/system/man1/en/yourfile.xml You'll need to compile your xml file (make doc) to ensure it has no errors Review the html file it creates from your xml file You'll then submit your work as a single patch file, see http://brlcad.org/wiki/Patches

 

Successfully compile BRL-CAD with the Intel compiler[edit]

This is a follow-on task to a previous attempt to build BRL-CAD with the Intel compiler:

http://www.google-melange.com/gci/task/view/google/gci2012/7982222

That task encountered several warnings and an error that stopped the compilation.

Your task is to either fix/quiet all of the warnings being reported (via make -k) or (even better) fix the compile so it completes successfully.  You can do either, but if you do both, we'll make another GCI task out of it.

You will probably need to modify cmake build files and possibly make some minor source code changes, but you'll definitely need to search the web for clues on the best way to address the errors or warnings.  Feel free to ask questions if you get stuck, after searching for an answer.

You'll submit your work as a single patch file that either fixes the warnings or fixes the errors.  See http://brlcad.org/wiki/Compiling for help. 

Design a prototype CAD GUI layout (#3)[edit]

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:

Provide one or more mock-up images (png, pdf, psd, html, whatever)

Design a Tshirt for BRL-CAD[edit]

This is where the magic happens. If you've got an awesome idea for a design, submit it here. If your design is chosen for print, it could end up selling as a real product that people all around the world can have! It would be fun and showcase your creativity.

Your Tshirt design should have the BRL-CAD logo to be accepted.

Design a Tshirt for BRL-CAD[edit]

This is where the magic happens. If you've got an awesome idea for a design, submit it here. If your design is chosen for print, it could end up selling as a real product that people all around the world can have! It would be fun and showcase your creativity.

Your Coffee Mug design should have the BRL-CAD logo to be accepted.

Design a Cover Page for BRL-CAD Manual for doccamp book[edit]

This is where the magic happens. If you've got an awesome idea for a design, submit it here. If your design is chosen for print, it could end up selling as a real product that people all around the world can have! It would be fun and showcase your creativity.

You need to design a cover for the first book at [1]

Your Cover page design should have the BRL-CAD logo to be accepted.  

Search for other similar GCI tasks to avoid making a similar design.  You can use any tools, but your work must be original.