Implement a primitive centroid function ... for extruded bitmaps (EBM)BRL-CAD
Status: ClosedTime to complete: 72 hrs Mentors: Sean, Matt S.Tags: C, C++, math, geometry, centroid

BRL-CAD provides more than two dozen types of geometry "primitives" such as ellipsoids, boxes, and cones. Every primitive is described by a collection of callback functions, for example rt_ell_bbox() returns the bounding box dimensions for an ellipsoid. Wikipedia, Wolfram Mathworld, and various other math sites (and research papers) around the web include the equations for most of our basic primitives while others are a little more tricky to compute.

This task involves writing a new callback function that takes an rt_db_internal object and calculates its centroid (as a point_t 3D point). There are numerous examples in our code where we compute centroids for other primtiives. The primitives that do not already have a centroid callback are itemized in following.

References:

Code:

  • src/librt/primitives/table.c
  • src/librt/primitives/ebm/ebm.c
Uploaded Work
File name/URLFile sizeDate submitted
table.c35.8 KBDecember 03 2012 07:11 UTC
ebm.c46.1 KBDecember 03 2012 07:11 UTC
ebm.c46.1 KBDecember 03 2012 07:14 UTC
ebm.c.diff1.2 KBDecember 03 2012 20:15 UTC
table.c.diff8.8 KBDecember 03 2012 20:15 UTC
Comments
fernozzleon November 30 2012 15:22 UTCTask Claimed

I would like to work on this task.

Harmanpreet Singh on November 30 2012 15:35 UTCTask Assigned

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

fernozzleon December 3 2012 07:12 UTCReady for review

The work on this task is ready to be reviewed.

Matt S. on December 3 2012 08:31 UTCCouple things...

First, I think it would be better to submit your work as a patch, as it's rather cumbersome to have the entire .c file in front of me to look at.  Minor issue though.


Looking only at your rt_eb_centroid function, I have a few issues.


First, calling your variables avgx, avgy, avgz is misleading, as "centroid" is not the same as "average". Again though, minor thing.


Second, I don't understand why you have tacked on the extra value of 0.5 to avgx and avgy.  What are you doing this for?


So, very close to complete, and I'll ignore the fact that I don't know how to test it as I see Sean has mentioned fixing up analyze() as a task here, which would take care of that for me.


Cheers!

Matt S. on December 3 2012 08:31 UTCTask Needs More Work

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.

Matt S. on December 3 2012 08:31 UTCDeadline extended

The deadline of the task has been extended with 0 days and 12 hours.

fernozzleon December 3 2012 15:29 UTCExplanations

Thanks for the suggestions.


Now, I have my reasons for doing what I did! I'm going to refer to the term "pixel" as "the rectangular prism representing the pixel"


"calling your variables avgx, avgy, avgz is misleading, as 'centroid' is not the same as 'average'"


To pluck a definition straight from Wikipedia, "informally, it is the "average" (arithmetic mean) of all points of X.", and I took this in mind when writing this function. In addition, since each pixel is an oblong (which we know the centroid of), and each pixel has exactly the same dimensions (width 1, height 1, constant tallness) (they are all represented equally, so an average of averages certainly does work here), we can represent all of the points of each pixel with a single point, its individual centroid. After averaging the centroids of all of the pixels, we can be sure that all points within this extruded bitmap have been equally represented.


"I don't understand why you have tacked on the extra value of 0.5 to avgx and avgy.  What are you doing this for?"


The indices of a pixel only represent its bottom-left corner. So if I were to only average all of the indices of the pixels, that would not be averaging their centroids; that would be averaging their bottom-left corners. However, each and every pixel's centroid is exactly half-a-pixel up and half-a-pixel right from its bottom-left-corner. So, after averaging, we can simply add 0.5 to the x and y of the indices' average to reach the final centroid.

fernozzleon December 3 2012 20:15 UTCReady for review

The work on this task is ready to be reviewed.

fernozzleon December 4 2012 00:30 UTCCentroid examples

Here are some examples of the exact same centroid procedure in action (amazing balancing acts!):


http://cl.ly/image/0e2j1d0A2l2q


"If a physical object has uniform density, then its center of mass is the same as the centroid of its shape."

Melange on December 4 2012 03:36 UTCNo more Work can be submitted

Melange has detected that the deadline has passed and no more work can be submitted. The submitted work should be reviewed.

Sean on December 4 2012 06:23 UTCTask Closed

Congratulations, this task has been completed successfully.

Sean on December 4 2012 06:25 UTClikely follow-on

We'll likely have a follow-on task to confirm that your implementation works (maybe a unit test), but it looks reasonable at a glance.  For reference, it really helps us if you create a patch file that includes all changes together (not separated per file).  Running "svn diff" will give you that patch file automatically.

Sean on December 4 2012 06:30 UTCfollow-on


We'll likely have a follow-on task to confirm that your implementation works (maybe a unit test), but it looks reasonable at a glance.  Thanks for your efforts and bonus points for updating the analyze command call and identifying that existing centroid function that you could leverage. ;)


Sean on December 4 2012 06:31 UTCblah

sorry, ignore that last "follow-on" post.  browser cache woes with the melange interface.

Sean on December 4 2012 06:36 UTCreal name

fernozzle, if you provide your real name, we'll include it within our authorship file to reflect your code contribution.

fernozzleon December 4 2012 06:38 UTCReal name

My real name is Michael Huang.


Thanks for the support! I really appreciate it!

Sean on December 4 2012 07:21 UTCquick to accept

femnozzle, I was apparently way too quick to accept your task... :)


Your table.c.diff file is rather incorrect (read it, did you change all of that? it says you did!) because you apparently worked on an old version and then diffed against a newer more up-to-date version of the table.c source file.  If you could re-do the patch file (with both ebm.c and table.c included), it would be appreciated.  You can submit it to our patches tracker on sourceforge and provide the link as a comment here:


https://sourceforge.net/tracker/?func=addgroup_id=105292atid=640804


Details on creating patches are at http://brlcad.org/wiki/Patches and at the top of http://brlcad.org/wiki/Deuces


 

fernozzleon December 4 2012 08:54 UTCPatch

Sorry about that. I had generated those previous patches on the locked-down Windows machines at school and hurriedly had to jump through all sorts of hoops to do so.


Now that I'm at home, however, I have submitted a proper patch (which I have read):


https://sourceforge.net/tracker/?func=detailaid=3592384group_id=105292atid=640804


Thanks!

Sean on December 14 2012 14:20 UTCfollow-on task

A follow-on task has been created:


http://www.google-melange.com/gci/task/view/google/gci2012/8069204?validated


 

Sean on January 10 2013 06:05 UTCfyi

In case you didn't know, completing just one more task will get you the free Google t-shirt prize!

Sean on January 14 2013 15:08 UTCthank you

As GCI comes to a close, we wanted to take the time to say THANK YOU for all your efforts.  This comment interface closes after GCI is over, so you're encouraged to join our mailing list where we'll be announcing contributions from GCI participants like yourelf over the upcoming months: 


https://lists.sourceforge.net/lists/listinfo/brlcad-news


If you've provided your full name, we'll be sure to credit you in our authorship documentation and you'll see your name in a future announcement.  If you contact us at devs@brlcad.org or via IRC, we'll even let you know when your work is integrated and follow up with updates.  You're welcome and encouraged to contact us any time, especially if you have a question about how to continue participating in Open Source after GCI is over, but even if just to keep in touch.  Note that ongoing participation in Open Source is one of the most impressive skills to have on your resumé.  Take care, be well, and thank you again!


With your background and abilities, I really hope you stay involved!