Editing Community Publication Portal

Welcome to the BRL-CAD community publication portal.  This page is dedicated to the preparation and editing of BRL-CAD announcements.  Proposed and upcoming topics are listed.  Anyone is '''welcome and encouraged''' to share news about any activity related to BRL-CAD.  Community editing and review are encouraged.

__TOC__

'''Formatting & Editing Standards:'''

* Quotations are italicized and placed between double quotes ('' "Like This" '').

* AA (All Acronyms) need to be defined upon first use, don't abbrev. words.

* Section headings uppercase the major words and are in bold ('''Like This''')

* Use the serial comma: one, two, and three; not one, two and three.

* Cite references, include hyperlinks.

* Keep it brief.

'''Distribution Channels:'''

For release publications, follow [http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/HACKING HACKING].  For everything else, distribute to the following:

* brlcad-news@lists.sourceforge.net
* http://brlcad.org/d/node/add/story
* https://sourceforge.net/news/?group_id=105292
* (optional) https://brlcad.org/wiki/
* (optional) http://www.tenlinks.com/NEWS/tl_daily/submit_news.htm
* (optional) http://upfrontezine.com

----
----


== Ready for Publication ==
These articles are ready for publication.  Release notes should be posted after tarballs, ideally the last or first week of a month.  Other publications should be scheduled one or two weeks later, ideally on the second or third week of the month.

Note: if you see a comment indicating that a section is FROZEN, any changes you make in that section may go unnoticed as the article is being prepared for distribution. If you find errors in a FROZEN article, go ahead and correct the article but contact Sean (brlcad on freenode [[IRC]]) who may be able to incorporate changes during final publication.

'''''Move from Final Review to Here When Ready'''''


------

==Final Review==
====Wanted - Software Maintainer for Windows Binary Platform====
We need a software maintainer/release maintainer. Maintainers are needed for free and open source software to perform a variety of tasks. As BRL-CAD is a cross-platform system it has maintainers allocated to many binary platforms but does not currently have one for Windows. We are looking for someone to fill this job as it’s an essential role when releasing software. 

Role of a Software Maintainer

A maintainer is someone who is basically willing to support creating the release for a particular platform (In this case Windows). They would be required to undertake a lot of work but this would prove very satisfying as there are thousands of binary downloads every month. This would mean a vast number of users would be making use of software you had contributed to. Overall as a maintainer you would be supporting our software on the Windows platform. 
Below are some of the typical responsibilities you would have as a software maintainer to give you an idea of the type of work you could potentially be doing.

•	Building source code into a binary package (Windows) for distribution

•	Commit patches

•	Organize code in a source repository

•	Cryptographically signing binaries (for verification of a person’s authenticity)

•	Naming a binary release

•	Patching a release

•	Compiling a binary release

•	Posting a binary release

•	Create/Prepare notes on a binary release

•	Announce binary release

•	Platform-specific fixes

•	Investigate platform-specific (Windows) issues, bugs and requests.

Being a software maintainer is a useful experience which can broaden your career prospects. To find out more or to indicate your interest, announce your interest either through:

- BRL-CAD devel Mailing List - http://sourceforge.net/p/brlcad/mailman/brlcad-devel/

- BRL-CAD IRC Channel - http://brlcad.org/wiki/IRC

Further Information
	If you wish for more detail about releases on BRL-CAD, visit this link:

 http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/HACKING 
(Go to the section on releases near the bottom of the page)
	For a definition of a Software/Release maintainer, visit this link: 

http://en.wikipedia.org/wiki/Software_maintainer


Article written by Alexander Lotsu

====Google Code In 2013 Announcements====
Out of only 10 chosen, its glad to announce that BRL-CAD was accepted to participate in [http://www.google-melange.com/gci/homepage/google/gci2013 Google Code-In (GCI)]! It is the second consecutive year in which BRL-CAD is participating. Complementary to the highly successful Google Summer of Code program for university students, GCI is a contest encouraging pre-university students (age 13-17) to get involved with open source. Students will work our [http://brlcad.org/wiki/GCI_Tasks "itty-bitty "] tasks related to code, documentation/training, outreach/research, quality assurance, and user interface.

The BRL-CAD open source community is honored to be selected for GCI, now in a forth year running. With no shortage of introductory tasks helping improve the state of open source CAD, students may begin making submissions on November 18,2013. For a detailed timeline of important events and more information please review the [http://www.google-melange.com/gci/document/show/gci_program/google/gci2013/help_page Frequently Asked Questions] For an introduction and itemization of all organizations participating in GCI, see the Google Open Source [http://google-opensource.blogspot.in/2013/11/mentoring-organizations-for-google-code.html Blog ] and watch their [http://www.youtube.com/watch?v=CW5yNIDPZeY screencast].

====BRL-CAD Accomplishments : GCI 2012====

[http://www.google-melange.com/gci/org/google/gci2012/brlcad Google Code -In 2012] brought 69 budding new shoots and branches to the mighty BRL-CAD tree, and the canopy of warmth and love offered by the community helped them blossom and bloom in the 7 weeks of the program . With a few snips, a little trimming and pruning, they have learned, innovated, created and contributed to one of the largest free and open source communities in the world, and have contributed to a software that will touch many people around the world. They now have their roots  planted in the BRL-CAD community with the successful completion of their tasks and are ready to shelter budding shoots to come!

We had 66 students from 36 countries complete 178 tasks in the 7 week contest.  Students worked with BRL-CAD on coding, documentation, training, user interface, research, outreach tasks, and quality assurance tasks. 

Akshay Kashyap and Cezar El-Nazli were among the 20 lucky and hardworking [http://google-opensource.blogspot.in/2013/06/google-code-in-grand-prize-winners.html grand prize winners of GCI-2012] who received a trip to Google’s Mountain View, California, USA Headquarters for themselves and a parent or legal guardian for an award ceremony, an opportunity to meet with Google engineers, explore the Google campus and have a fun day in the San Francisco, California sun.

[http://www.google-melange.com/gci/homepage/google/gci2013 Google Code In 2013] has been already announced. If you are of the age 13-17 years, a pre-university student, this is the best opportunity for you to grab and get your hands on and step into the whole new world of software development and maintenance. Are You Ready ?

More information on what is Google Code-In, how you can participate, what are the exciting prizes for you, etc. is available [http://brlcad.org/wiki/Google_Code_In here].

For further queries mail us on our [http://brlcad.org/wiki/Mailing_Lists mailing list] or contact us via [http://brlcad.org/wiki/IRC IRC]

------

==== "Improving BRL-CAD's networking library":Andrei - Constantin Popescu ====
by: Plamen Nikiforov

Andrei - Constantin Popescu is a second year undergraduate at Polytechnic University of Bucharest, studying at the computer science department. Here is an interview about Andreis Google Summer of Code project.
Plamen(Pl): How did you found out about BRL-CAD and why did you chose to them?

Andrei(An): I heard about BRL-CAD when I was searching for a Google Summer of Code project to do. After doing some research on their website regarding Google Summer of Code ideas, several interested me particularly.
The language I am currently strongest in is C  and I am also interested in computer graphics, this motivated me towards applying for BRL-CAD. Another key aspect was that the BRL-CAD mentoring community was very friendly and helpful towards me.


Pl: Why did you choose "Improving BRL-CAD's networking library" to be your project?

An: The first project idea I proposed was " Code reduction". First, I looked at this project at Sean's suggestion. There were several reasons why I chose this project idea : I was taking a networking course and it would help me consolidate my knowledge and the performance testing seemed a more interesting problem to investigate.


Pl: What were your aims of the project?

An: My initial aims were to investigate and fix any performance bottleneck regarding transfer speed for various file sizes and package sizes, test the code integrity of networking library and eliminating as many unhandled exceptions as well as eliminating global variables from the networking library.

“Here are some of Andreis performance measurements for different package sizes:
Package size 1 – 2048 - http://i.imgur.com/OPum5.png
Package size 2048 – 4194304 - http://i.imgur.com/fH4rL.png
Package size 1 – 4194304 - http://i.imgur.com/AXUpN.png ”


Pl: Has this project helped your skills improve?

An: Definetly! The most important aspect is that I greatly improved my communication skills. Aside of that, I also improved my capacity to work in a team, developed the ability to work with a large code base and of course improved my implementation skills.

Pl: Would you continue to contribute to BRL-CAD?
An: Of course ! I continued to contribute even after Google Summer of Code. Even if my contributions aren't as numerous as I would like because of my crowded academic schedule, I am trying to contribute for as much as possible. Contributing to BRL-CAD helps me improve knowledge as well as providing code that is actually useful for a large number of people.


====Google Summer of Code: Jianbang Wu====
by: John

This article is based on some questions I asked Jianbang and in his profile page.

Jianbang Wu (also known as Phoenix) participated in BRL-CAD development during Google Summer of Code 2012. His work was "to convert implicit Constructive Solid Geometry (CGS) primitives to boundary representations (BREPs)". He is a sophomore student in Peking University, China.
His skills involve C/C++, Object Oriented Programming, data structures, algorithms, math, and image processing.

Jianbang chose to apply to BRL-CAD because "The mentors of BRL-CAD are really nice. :)" and because he loves computer graphics and math.
He started working without any Computer Aided Design (CAD) software experience, which he learned during the summer.
He worked on two projects:

First, he followed Cliff's suggestion: "Implicit to NURBS conversion". This consisted in the conversion from implicit primitives to Non Uniform Rational Basis Spline (NURBS) primitives. In this project he also modified some unfinished conventions and added some new primitives.
Since he finished this task before the mid-term evaluation, he decided to make a follow-up: "NURBS surface-surface intersection".

Finally, he suggests future Google Summer of Code students to "Follow your interest, choose the project you like, and you will find Google Summer of Code really an excellent experience".

You can check out some images related with his work here:

http://brlcad.org/wiki/User:Phoenix/GSoc2012/Reports#Test_Results

Related with his first work:
* m35.g: component (left: implicit + csg, right: brep + csg)
[[Image:M35.implicit.png]]      [[Image:M35.brep.png]]

Related with his second work:
* The intersection curves (green) of a tgc (red) and an epa (blue). (Two segments)
[[Image:Tgc epa.png]]

John is a Google Code-In student living in Portugal. He's favourite language is Python although he's considering to widen his knowledge to C.

==== Linux Release Packaging Process: A mission for Jordi Sayol ====
By: John

Jordi Sayol is the man behind the automation of the BRL-CAD Linux release packaging process, which he recently finished. His work continues the one made previously by Manuel A. Fernandez Montecelo in .dbm packages.

This article is based on some questions I asked him and on an interview made to Jordi by Gala, a Google Code-in student.

Jordi has been working with BRL-CAD since January 2011,with his Linux experience (as advanced user) as his only companion. By that time, he started to collaborate on-line with other BRL-CAD team members.

With such a massive project, which has millions of lines of code, he decided to take as his responsability the building of binary packages for Linux systems, since he's not a programmer.

In both interviews, he explains quite accurately the process of making those. He has made two scripts that automate the whole work. What the scripts do is to handle all the pre-building proccess and then create the packages. "In fact the building job is done by debhelper to create deb packages, and the rpmbuild command to create rpm packages. The scripts tries to ensures that all dependencies needed by these commands are available, copy Linux specific files, create configuration files, etc. before building the packages".
The scripts allow anyone to easily create their own deb/rpm packages as needed", since they "create deb/rpm packages for the host architecture where they are executed".
This allows BRL-CAD to be distributed Debian-like and Fedora-like systems, which means a great variety of platforms where BRL-CAD will be able to work. Unfortunately, since Fedora and OpenSUSE don't share the same nomenclature, their rpm packages must be separate ones.
The scripts can be found at the "sh" folder when you download the BRL-CAD sources.

Since he is not a programmer (only an advanced Linux user), he won't develop other parts of the code, but I think all the BRL-CAD community can be grateful for what he has done.

by John.

John is a Google Code-In student living in Portugal. He's favourite language is Python although he's considering to widen his knowledge to C.

Gala Taylor is a 2012 Google Code-In participant. Although she has used various Free and Open Source Software (FOSS) products over the years, and has contributed example files and tutorials to several projects, this is the first time she has actively participated in the development of FOSS code. Gala is currently in 9th grade, and her favorite computer language is Java.

==== Gala Taylor: New BRL-CAD Linux Release Packaging Process Automation ====
By: Gala Taylor

BRL-CAD supports Debian, Ubuntu, Fedora, and openSUSE, and other Linux distributions. Jordi Sayol recently finished automating the BRL-CAD Linux release packaging process, and he took some time out to chat with Gala Taylor about it - and also answer some question about what it's like to work on the BRL-CAD project.

'''Gala Taylor (GT)''': How long have you been working on the BRL-CAD project?

'''Jordi Sayol (JS)''': I've been involved with the BRL-CAD project since January 2011.

'''GT''': How much education and experience were required to prepare you to contribute to the BRL-CAD project?

'''JS''': My experience is just as an advanced Linux user.

'''GT''': Do you need to physically meet with the other team members in order to contribute to the BRL-CAD project, or is it sufficient to work on-line?

'''JS''': All of my collaboration is done on-line.

'''GT''': The BRL-CAD project is a collection of over four hundred tools, utilities and applications, with over a million lines of source code. With such a massive and complex system, how do you decide what to work on? Is it necessary to understand all that code in order to contribute to the project?

'''JS''': My responsibility is focused on building binary packages of BRL-CAD for Linux systems.

'''GT''': Besides the release processing work which is described in the HACKING file, can you walk me through the process of actually transforming a developer’s checked-in source code into an .rpm or .deb that is ready to be downloaded and installed?

'''JS''': It's quite simple. I have created two bash scripts that automate this process. The "sh/make_deb.sh" script creates a deb package installable on Debian-like systems. This currently includes Debian, Ubuntu, Linux Mint, and other distributions. The "sh/make_rpm.sh" script creates an rpm package for Fedora-like systems. This includes Fedora, Centos, Redhat, and some other distributions, or OpenSUSE, depending on the system where it is built. There are separate rpm packages for Fedora and OpenSUSE because they do not share the same nomenclature on their packages. Note also that both scripts create deb/rpm packages for the host architecture where they are executed, and that the results are currently only tested on x86_32 and x86_64 hosts.

With these scripts, anyone can easily create their own deb/rpm packages as needed. This is especially useful if the user wants to install BRL-CAD on a very old system, maybe requiring special compilation for specific graphic cards drivers, etc.

'''GT''': Thank your for your time today and your contributions to BRL-CAD, Mr. Sayol!

'''JS''': It was a pleasure.


Please visit the BRL-CAD project website for more information: http://brlcad.org


'''Jordi Sayol''' is the maintainer of the BRL-CAD Linux release packaging process.

'''Gala Taylor''' is a 2012 Google Code-In participant. Although she has used various Free and Open Source Software (FOSS) products over the years, and has contributed example files and tutorials to several projects, this is the first time she has actively participated in the development of FOSS code. Gala is currently in 9th grade, and her favorite computer language is Java.

----

==== Kyle Bodt: Ronja ====

http://brlcad.org/wiki/Ronja

Ronja (Reasonable Optical Near Joint Access) is an innovative piece of equipment that utilizes reliable optical data links to create a current communication range of 1.4 km and a speed of 10Mbps full duplex that can be used as a general purpose wireless link for virtually any networking project. This is a very important project for Twibright Labs, a small group of computer science graduate students operating out of Charles University in Prague in the Czech Republic. The group specializes in the usage of Free Software and User Controlled Technology Development.

The primary output for the Ronja project is a design. The lab does not intend to manufacture and sell the hardware that is being designed but wants to engage in open source development of the technology. The philosophy surrounding User Controlled Technology is the ideal that the end-user is provided with unrestricted access to the intellectual property surrounding the technology, including the tools that are being used to create it. One tool playing an integral part in the development of the Ronja designs is BRL-CAD. All of the models that Twibright labs use to display the different variants of their Ronja concept were created with the help of BRL-CAD. BRL-CAD has allowed the members of Twibright labs to create instructional diagrams so that the users and builders of their open source technology will be able to have the latest information with regard to the proper construction of a Ronja unit. The interactive geometry editor and ray-tracers in BRL-CAD are an integral part in the communication of design plans for Twibright labs and enables them to connect with the users, who are the driving force behind the User Controlled Technology ideal.

----

== Initial Drafts ==
These are incomplete articles being worked on.  Short 250 to 500-word articles (not counting tables, images, etc) are usually perfect.

==== Documentation Redux ====

BRL-CAD was selected to participate in the 2013 Google Summer of Code '''[http://www.flossmanuals.org/news/2013-doc-camp-call-proposals Doc Camp]'''.  A team of contributors got together in California, brainstormed, and wrote an entire book for BRL-CAD in just a few days.  They created a guide for contributing to BRL-CAD.

[[File:DocCamp_WorkingHard.jpg|thumb|right|256px|BRL-CAD doc team getting to work writing a book from scratch in less than three days]]

Contrary to and perhaps because of longstanding efforts, people interested in improving BRL-CAD sometimes find themselves lost in a sea of information.  In all, BRL-CAD has more than a million words of documentation across hundreds of manual pages, dozens of tutorials and examples, hundreds of wiki pages, dozens of technical papers, and other resources.  It's a lot, created over decades of development.

Over the course of a week in October, members from our community participated in something fresh.  Something different.

[[File:DocCamp_TopicWall.jpg|thumb|right|256px|Unconference brainstorming stickies]]

A team of individuals traveled to the Google headquarters in Mountain View, California, to participate in a 2-part event: an unconference and a book sprint.  Teams for GNOME, OpenMRS, and BRL-CAD arrived on the Google campus and talked about techniques, tools, formats, documenters, and more.  By the end of the week, seven individuals from four different countries, three continents, and one oceanic island produced a book for BRL-CAD more than 100 pages in length.

As free open source software, one of BRL-CAD's greatest strengths is that anyone can get involved and directly contribute.  You can make it better.  This new book focuses on that aspect and introduces people to the project while providing detailed information for developers, writers, artists, and other potential contributors.
  
[[File:DocCamp_Relaxing.jpg|thumb|right|256px|Fresh air break with Allen Gunn of Aspiration and Adam Hyde of FLOSS Manuals]]

This new effort kick-starts a campaign to dramatically improve BRL-CAD's documentation, starting with this new contributor's guide.

Attending the camp provided an exciting opportunity to get a grasp on new techniques for documenting and sharing information about our software, hopefully in ways that help us grow our community.  BRL-CAD's team included Sean Morrison, Eric Edwards, Cliff Yapp, Harmanpreet Singh, Check Nyah, Isaac Kamga, and Scott Nesbitt.  Thank you to Google for their sponsorship, [http://aspirationtech.org/ Aspiration] for magnificently framing the event, and [http://www.flossmanuals.org/ FLOSS Manuals] for directing the production.

[[File:DocCamp_Team.png|thumb|right|384px|The BRL-CAD Doc Camp Team]]


==== Anurag Murty: Voxelizing Geometry ====
Given a set of primitives as input, the voxelize command uses the data obtained from BRL-CAD's raytracer to represent the input in the form of voxels(Volumetric Picture Elements). A uniform grid of rays is uniformly shot on the given input and an approximation of the volume filled in each voxel region is made from the raytracing data. Depending on the approximate volume of the voxel filled, a voxel is classified as IN or OUT of the voxelized output. The voxels are represented as RPPs. 
Such voxelized outputs have applications in Volumetric rendering and finite element analysis.

SYNTAX : 
voxelize [-s "dx dy dz"] [-d n] [-t f] new_obj old_obj [old_obj2 old_obj3 ...]

ARGUMENTS-

-d  - Specifies the level of detail(precision in approximation of volume) required. An input of n means that n * n rays will be shot through each row, and an approximation of volume filled is reached averaging these n * n values

-s  - Specifies the voxel size in each direction. 

-t  - Specifies the threshold volume to decide if voxel is to be included in the voxelized output. 

new_obj  - Name for resultant primitive that is a region containing the resulting voxels. 

old_obj  - Name of source primitive or collection.


NOTES-  

1. A greater level of detail usually implies a much better approximation of fill volumes at the cost of more computations.

2. Lesser voxel sizes give a more precise representation of the input at the cost of more memory requirements.

3. Threshold value (the argument of -t) should be a value between 0 and 1, and not a percentage.

==== Cristina Precup: Visualizing Directed Acyclic Graphs ====
'''Visualizing Constructive Solid Geometry''' is a project meant to illustrate in an intuitive and interactive manner the hierarchical structure of .g geometry databases.

For the representation of the hierarchies, the '''Adaptagrams''' graph library has been used. This made possible organizing the objects contained within the database into directed acyclic graphs.

Following, are the steps that have been taken in developing the graph layout API:

* Integrate the Adaptagrams library into BRL-CAD.
* Traverse the geometry database and distinguish different types of objects (''primitive'', ''combination'', ''non-geometry'') within it, as well as, establish the operations between them (''union'', ''difference'', ...). Add all this data to the graph structure constructed with Adaptagrams.
* Display the objects using a Tk Canvas widget inside a window.
* Develop a ''decorative routine'' that sets different colors for different types of objects, correspondingly.
* Create a name label for each represented object.
* Develop a layout algorithm that aligns the nodes of the graph in a hierarchical way.
* Introduce the '''graph''' command in both '''MGED''' and '''Archer'''. It has two subcommands:
** '''show''' which displays a list with the name and type of the objects along with the nodes' and edges' positions;
** '''positions''' that lists the names, types and positions of the corresponding nodes within the graph;
* Introduce the '''igraph''' command in both MGED and Archer. This command pops up a graph based visualization window of the currently opened .g database. Its documentation can be found in ''brlman''.

As an example, here is how the graph for the ''share/db/axis.g'' database looks like now:
:[[Image:Graph_editor_v2.png]]

Further work that can extend the ''interactive'' trait of the graph layout API includes adding user actions upon the graph such as ''move'' (dragging a node) or ''delete'' functionalities.

==== Ksenija Slivko: Reducing Code ====

===== Abstract =====
The main aim of this project was to decrease the number of lines of code in the project. Since the project is being developing for quite a long time there were many "copy-pastes". They were redacted. 

===== The process of developing =====
Coding period can be divided into three parts:
* reduction in the single files
* reduction in different files in the single program or library
* reduction in different libraries

===== Improving =====
Since the project is quite large the redaction can be continued

==== Laijiren: NURBS Tessellation: What, Why, How? ====
===== Abstract =====
Non-Uniform Rational B-Spline surfaces are widely used in CAD system. But they are not suitable for direct visualization on modern GPU systems. Today’s graphics hardware supports the high-speed display of polygonal objects consisting of triangles. This means that analytical surfaces (like NURBS) need to be triangulated so they can be displayed by 3D graphics cards.

===== Main work =====
===== For debugging tool =====
*add 'info TB' 'info SB' to display information of piecewise bezier trim curve
*add 'info T' 'info E' to display information of trim curve in parameter region and edge in 3d region
*add 'plot SCV' to display control point net and 'plot TESS' to display the result of tessellation

===== For surface tree =====
*subdivide a Nurbs surface in a adaptive method and a new recursion termination condition for surface subdivision.
reference:NURBS rendering in OpenSG Plus
*implement the doTrimming function in Surface tree.
1)compute the intersection between trim curve and rect's edge of sub-surface in  parameter region

2)implement a trimLoop class to get the valid loop and the trimmed loop

3)triangulate the valid loop in form of polygon

==== Suryajith Chillara: Benchmark Performance Database ====
===== Abstract =====
The main idea is to store the data both in the database and the log files stored in the archive. The storage in the database enables the content to be searched via the parameters such as machine descriptions, versions, results and could be compared. The storage as a file in the archive is to maintain a back up of the file and whenever a developer needs a specific bunch of benchmark logs, he could get them from the archive with or without the help of the database.

===== Main Components =====
* '''Log Parser :''' The data of the log file needs to be parsed and the relevant and important information has to be logged in the database so as to make the data access for the graphic display through the frontend could be made possible. 
* '''Web API :''' Implemented via the bottle framework so as to submit the logs from the brlcad installation via scripts.
* '''Web backend :''' A backend has been implemented as a MVC framework from scratch using the python bottle framework. 
* '''Frontend :''' The website that can offer multiple mechanisms for adding new performance run data into the database and provide multiple graphical and non-graphical visualizations of aggregate performance data (i.e., graphs, charts, tables, etc). Graphs, tables and charts are generated with the help of Google Charts via wrapper which generates the javascript code to interact with the Google Charts service.
[[Image:Absavgperfvsimagescomb.png]]


Plumbing between these components is via the python scripts. 


===== Tool & Service dependancies =====
* Python 2.7 and libraries
* Bottle web framework
* MySQL
* Google Charts

==== Wu Jianbang: NURBS surface-surface intersections ====
I focused on the "NURBS surface-surface intersections" project after the mid-term evaluation of this year's GSoC, before which I worked on converting implicit primitives to NURBS B-rep forms.

The function calculating NURBS surface-surface intersection curves is surface_surface_intersection() which is declared in include/nurbs.h and implemented in src/libnurbs/opennurbs_ext.cpp. It outputs intersection curves in 3d space and in both surfaces' UV parameter spaces.

The approach of the algorithm originates from:

Adarsh Krishnamurthy, Rahul Khardekar, Sara McMains, Kirk Haller, and Gershon Elber. 2008. Performing efficient NURBS modeling operations on the GPU. In Proceedings of the 2008 ACM symposium on Solid and physical modeling (SPM '08). ACM, New York, NY, USA, 257-268. DOI=10.1145/1364901.1364937 http://doi.acm.org/10.1145/1364901.1364937

It can be divided into several steps:

* Generate the bounding box of the two surfaces.
* If their bounding boxes intersect:
** Split the two surfaces, both into four parts, and calculate the sub-surfaces' bounding boxes
** Calculate the intersection of sub-surfaces' bboxes, if they do intersect, go deeper with splitting surfaces and smaller bboxes, otherwise trace back.
* After getting the intersecting bboxes, approximate the surface inside the bbox with two triangles, and calculate the intersection points of the triangles (both in 3d space and two surfaces' UV space)
* Fit the intersection points into polyline curves, and then to NURBS curves. Points with distance less than max_dis are considered in one curve.

It needs to be mentioned here that the value max_dis can be provided by the user or generated automatically.

Besides, after calculating the intersection curves, the next steps towords evaluated NURBS are splitting the surfaces into sub-surfaces with the intersection curves as their boundaries, and some inside-outside tests to decide which sub-surfaces should be included in the final object. Some work on splitting has been done, generating some b-rep faces that can pass IsValid(), but still further work is needed.

==== Andrei Popescu: Network Performance Testing ====

The project that I have been working on during the summer, as part of the Google Summer of Code program,<br> can be broken down into three independent parts and it consisted in running various tests for the BRL-CAD<br> networking library(Libpkg) .

*Speed testing and investigations to uncover any potential performance bottleneck.
*Unit tests and code review to find and cover any untreated exceptions(crashes) in the Libpkg library.
*Eliminate the assumption of globals in the API.

For the first part, I have run two types of tests : <br>

Local ones, both the "sender" and the "receiver" were located on localhost.
The script gathered data<br> regarding the transmission speed for each set of package sizes (Here, package refers to the package <br>created by networking   library, not networking packages) respectively file sizes.

Remote ones, where the "sender" and the "receiver"  were on separate machines, connected using SSH.<br> The script ran and the data gathered was done in the same way as the localhost one.Using the data <br> obtained from the tests, two 3D graphs were drawn.However, the tests were inconclusive, I could not find<br> an "ideal" package size to use regardless of file size.

After Mid-term I focused mostly on second part. I used  test units from libbu(Utility library) as an example<br> for the unit test type and design.
When the mentioned tests were run, several exceptions that caused<br> crashes were discovered. Lastly, I have written fixes for the discovered crashes.

The third part of the project has not been covered yet, so more work is needed.Although, I am doing my<br> best to finish it in the following weeks.

==== Chris Dueck:  Calculating 2D Sketch Surface Area ====

Calculating the surface area of a 2D Sketch primitive is not a trivial task. Sketches are created interactively by the user, and can contain straight line segments, circular arc segments (and full circles), as well as Bezier and NURBS curves.

The method used to approximately compute the area of a 2D sketch is as follows:

*1.) Approximate the sketch by a polygon
*2.) Compute the area of the polygon exactly using Green's Theorem
*3.) Add the areas of any circular arc segments that were created during (1)

To approximate the sketch by a polygon, each possible curve type of a sketch must be considered.

*If the curve is a straight line, it need not be approximated.

*If the curve is a circular arc, it must be determined if it is a full circle (in which case its area can be computed easily) or if it is a circular arc segment. If it is a circular arc segment, the line segment from the beginning of the arc to the endpoint is added to the polygon, and the excess area of the circular arc segment itself can be calculated easily (https://en.wikipedia.org/wiki/Circular_segment)

*If the curve is a Bezier curve, it can be approximated by a series of circular arcs. The algorithm used can be found here (http://itc.ktu.lt/itc354/Riskus354.pdf). The algorithm recursively subdivides the Bezier until it is approximated to tolerance by a biarc and uses the curvature value of the Bezier at a point to determine the depth of subdivision. Then each circular arc in the approximation of the Bezier curve is treated as above.

Finally, the area of the polygon can be efficiently calculated using Green's Theorem (http://www.softsurfer.com/Archive/algorithm_0101/algorithm_0101.htm#3D%20Standard%20Formula) using cross products.

==== Cliff Yapp: NURBS Ray Tracing in BRL-CAD ====

Over the past year, an intense development effort by BRL-CAD's development team has successfully implemented raytracing of Non-Uniform Rational BSpline (NURBS) geometry within the BRL-CAD Computer-Aided Design (CAD) package. NURBS surfaces are very general, very complex mathematical shapes used by virtually all modern commercial CAD software packages. Because BRL-CAD did not originally support this type of geometry, commercial models could only be imported into BRL-CAD after a labor-intensive and difficult conversion process from NURBS form to triangle-base geometry (referred to in BRL-CAD as Bags-of-Triangles or BoTs). The new NURBS raytracing capability builds on work by many developers over a period of years, who in turn built on the open source library OpenNURBS. Support for this primitive type means BRL-CAD can now store and raytrace data from commercial models without requiring preliminary conversion to another type of geometry.

The last major feature needed to make import of commercial models in BRL-CAD straightforward is conversion support for ISO’s "Standard for the Exchange of Product model data" or STEP file format. STEP uses NURBS geometry in its definition, making support for NURBS geometry a necessary prelude to support for STEP import. Most commercial CAD modelers support this file format as an output option, hence STEP support in BRL-CAD would allow a direct path for moving geometric descriptions from a variety of commercial modelers to BRL-CAD. Considerable progress has already been made on STEP import support, but more work is need to bring the code and feature set to "production quality". If anyone would like to join the BRL-CAD open source development effort and has a little familiarity with C++, the step-g converter and its supporting libraries have some simple-yet-useful tasks that would be an excellent and very useful way to explore the project - join BRL-CAD's IRC channel or development email list if you are interested!

==== Erik Greenwald: Bolting ADRT's libtie under the hood ====

[[Image:BoTvsTie.png|right|thumb|256px|BoT vs Tie pixdiff]]

Initial progress on the integration of ADRT's libtie "triangle intersection engine" with LIBRT.

==== Tan YuGin: BRL-CAD's Code Hardening Efforts ====

A/N: Written as a Google Code-in 2013 task.

BRL-CAD is a software based on decades of development and contains over a million lines of code. Any project of such magnitude is bound to face problems with ensuring consistency and high standards across its various aspects. The core team behind BRL-CAD, however, have sought to alleviate such issues as far as possible, and hence have put in place an extensive range of measures designed to maintain and improve the quality and maintainability of its code.

As an open-source software, BRL-CAD relies on input from numerous developers, both existing and new, from across the world. With individual developers having differing methods and standards of coding, the quality and styles of each contributor’s code are likely to vary. Thus, the BRL-CAD team has ensured that all developers have easy access to the same guidelines and tools used to ensure code consistency and quality. 

A ‘HACKING’ document included with the rest of the software gives a detailed description of the universal guidelines and good practices in all BRL-CAD code, for easy reference by contributors. The scope of these guidelines include formatting issues, such as indentation and stylistic whitespace conventions; code organization, including the locations where various types of code should be stored in; and code conventions, for example the discouraging of the use of global variables within code. Furthermore, the document also provides general guidelines for miscellaneous aspects of development such as the incrementing of version numbers, handling of bugs or unexpected behavior, and submission of patches.

BRL-CAD encourages the use of various tools to make it easier for developers to check for problems or errors in their code. One of these is the Simian similarity analyzer, a frequently used program that searches for instances of code that is repeated across multiple files. This is particularly useful given the inevitable duplication resulting from decades of development. Developers can then use the findings of the analyzer to refactor the largest or most frequently duplicated code into reusable, space-saving functions.

[[Image:Simian_analysis_sample_output.PNG]]

''Sample output of Simian similarity analyzer. Screenshot courtesy of BRL-CAD wiki.''

BRL-CAD also has an built-in tool to allow developers to easily check for errors within their code. The CPPCHECK-CLEANUP  tool can be called with a single line of input into the command line interface, and checks for issues in all of the source code files. The tool can be customized to search only for specific issues, such as those relating to style or unused functions.

[[Image:CPPCHECK-CLEANUP_sample_output.PNG]]

''Sample output of CPPCHECK-CLEANUP tool. Screenshot courtesy of BRL-CAD wiki.''

BRL-CAD enforces the practice of strict compilation, or the treating of issues detected by the compiler as errors instead of mere warnings. This acts as another safety barrier for the detection of potential problems with the code. By treating all of the compiler’s warnings as matters that have to be resolved before development can proceed, any detected issues that are in actual fact errors can be fixed. Even false positives, or incorrectly detected errors, are often due to weaknesses in the code that can hinder development or increase the risk of bugs or failures in the future, and these can also be dealt with.

To further deal with any errors that may have slipped into the code, BRL-CAD has since 2006 participated in the Coverity Scan Initiative, where a thorough static source code analysis is performed and a detailed list of detected problems generated. 

[[Image:CoverityExample2.png]]

''Coverity analysis showing secure coding suggestions. Image courtesy of BRL-CAD wiki.''

After the 2011 edition of the scan, a team of core developers met up in person and spent a week inspecting and fixing over fifteen hundred of these issues. Consequently, BRL-CAD’s defect density was reduced to just 0.22 defects per thousand lines of code- less than a quarter of the industry average. In addition, a publicly available document was created to present a peer-reviewed, tested and documented workflow for addressing issues reported in the Coverity Static Analysis, to aid further resolving of the reported problems as well as future maintenance of code.


----

== Idea Hopper ==
These are ideas for interesting or useful publications.  We need someone to at least write a draft.

==== BRL-CAD's Evolutionary API ====

Talk  about BRL-CAD deprecation process.

==== Introduction to new .deb and .rpm builds ====

Brief article overviewing the efforts by jordisayol for Debian, Ubuntu, Fedora, and openSUSE.  Included are new icons, menu items, mime type associations, and more.

==== 2010 End Of Year Review ====

Article giving an overview of the past year's highlight developments with hints at what 2011 may bring.  Alternatively, may be the annual statistics review if we switch from fiscal to calendar year reporting.

==== Erik Greenwald: ADRT/ISST Visualization ====

Article introducing ADRT/ISST core capability.

==== Bob Parker: Alpha Archer: Working Towards Next Generation MGED ====

Article introducing Archer's core new features that will be "coming" to MGED.  Undo, interactive editing, tree view, and info panels come to mind.

==== Finding the Hot Spots ====

Article on the rt lighting model Stephen Kennedy developed that visualizes the time spent per-pixel.

==== Point Clouds ====

Article introducing the new point cloud primitive.

==== bn_mat_inv: singular matrix ====

Article on the v4 format and binary compatibility.

==== Model Showcase: Goliath ====

Article talking about the making of the Goliath model.

==== Model Showcase: Chumaciera ====

Article on Pedro Baptista's bearing model.

==== Model Showcase: Proyecto Catapulta ====

Article on a model developed by André Santos, António Almeida, and Pedro Ferreira.

==== Model Showcase: Union Coupling Tool ====

Article on a model developed by Inês de Matos under teacher Luís Ferreira. The project focuses on a tool, union coupling, based on the book, http://purl.pt/14352 , page 122 of the original book and page 128 of the file, figures 108 and 109.

==== Geometry Service FAQ ====

FAQ summarization of the GS as it pertains to the wider open source community.

==== BRL-CAD's 3rd Generation Build System  ====

Article on the new CMake build system.

==== BRL-CAD's Open Source Vision ====

Article introducing the Project Priorities diagram and overall project vision.

==== BRL-CAD Primitives Showcase ====

Article summarizing all of BRL-CAD's primitives and their current status.

==== BRL-CAD Geometry Converter Showcase ====

Article summarizing all of BRL-CAD's geometry converters.

==== Release Schedule ====

Explain our release schedule and versioning system.

==== RTGL ====

Article on Nick's point-based visualization mode.

==== BRL-CAD Quick Reference Card ====

Article on a BRL-CAD QRC similar to the existing MGED QRC.

==== BRL-CAD Bibliography ====

After the .bib gets published to the website, an article announcing it and soliciting additions.

==== Revolve Primitive ====

Article on Timothy Van Ruitenbeek's work implementing 'revolve'.

==== Parametrics and Constraints ====

Article on Dawn Thomas' work to integrate parametric equation and constraint evaluation support.

==== Converting Implicit to Explicit: CSG to BREP NURBS ====

Article on the work by Cliff Yapp, Joe Doliner, and Ben Poole converting primitives with an implicit representation into an explicit NURBS representation.

==== Online Model Repository ====

Article on Elena Băutu's work developing the model repository website.

==== Project Statistics for 2010 ====

Article on our current stats similar to previous years.

==== Next Generation BRL-CAD ====

Article on our super secret awesome new GUI.