I would like to work on this task.

This task has been assigned to Johannes Schulte. You have 72 hours to complete this task, good luck!

The work on this task is ready to be reviewed.

You included a change in the comment for the function bn_polygon_centroid() in your patch.  This doesn't belong here.

Furthermore "declaration = initialization" is a good coding paradigma.  You should use it whenever it's possible (it isn't always the case).  E.g.: point_t **tmp_pts = (point_t **)bu_calloc( ...

One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.

The work on this task is ready to be reviewed.

• At the moment, we have the same helper function to sort points ccw 4 times duplicated, spread across librt and libged. While it only has 3 lines (iirc), at least for me it looks like some complicated logic, which isn't obvious, when you want to sort points. As ccw sorted points are required by the other polygon functions, I designed and implemented, I'm not sure, if we can expect that from another caller. So, on the one hand, its just 3 lines, on the other hand, one could loose much time having to work out these 3 lines, just because he wants to know the area of a polygon. What do you think. Is this worth a public function?


• While looking through table.c, I saw, that a surface area function for bot and a volume function for arbn are still missing. These should be possible to implement, so I would appreciate GCI tasks for those.

Congratulations, this task has been completed successfully.

committed in r59263

Number of lines is irrelevant.  Any code duplication warrants refactoring.  What's not clear to me (and will need to be addressed in the API doxygen comment at a minimum) is what implications sorting has on a given input data set.

If I gave you N random coplanar points, they could describe a number of valid polygons (that do not self-intersect).  Reordering the points could change not just the orientation, but also the shape of a polygon.

That said, if you literally refactor N identical lines from M places throughout the code, put the N into a function that does exactly the same thing and update the M places, there shouldn't be a problem and the API can state the assumptions implied in those M places where it's used. 

You're welcome to get started on surface area and volume functions for any primitives that still lack them and we'll be sure to create and accept those tasks before the deadline.

Note that there is a BoT bounding box function that is still open.  Basically we have two implementations including a new one that doesn't work quite right.  You could investigate or re-implement, whatever is easier.  The task is basically create a bounding box around a mesh (which in theory is just the min/max sum of all vertices):

http://www.google-melange.com/gci/task/view/google/gci2013/5780674933948416

There's not a BoT surface area task because you already implemented it last year.  The patch could not be applied because it needed some careful review and testing.  We had other priorities take up all our time, but now that you have commit, you can make it all current.  Last year's work:

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

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

Really glad to see you complete more than three tasks this year.  ;-)

A task for BoT mesh surface areas has been added:

http://www.google-melange.com/gci/task/view/google/gci2013/5836041357361152