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:
|
| File name/URL | File size | Date submitted | |
|---|---|---|---|
| my.patch | 4.1 KB | December 04 2012 21:10 UTC |
I would like to work on this task.
This task has been assigned to tka. You have 72 hours to complete this task, good luck!
The claim on this task has been removed, someone else can claim it now.
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!
As the first draw is now ready, I have some questions:
1. Where should the function be placed (just at the end of bot.c?) and how should it be called?
2. How should the result be brought outside of the function, via an fastf_t return value, or shall there be another parameter, which is an pointer onto an fastf_t, like shown in rt_functab?
3. Shall I let the function just stand alone, or shall I connect already with rt_db_internal-idb_meth- ft_surface_area, and if, where and when has this connection to made, as I couldn't find a simple create function for BoT while quickly browsing bot.c.
4. Shall the thickness of the triangles also be a part of the surface area?
1. If it's really long, you can add a bot_surf_area.c file, but at the end of bot.c is fine too. Follow the naming convention used by the other surface area functions for other objects (see src/librt/primitives/table.c where they get registered).
2. that is already defined by the function callback signature used in rt_functab.
3. the functab in table.c is where it gets registered. You can create BoT from any existing geometry with the 'facetize' command. Most of our geometry importers (outside of mged) will also import as BoT (e.g., stl-g).
4. Add a check to make sure the BoT is volume mode, otherwise return an error. We can create another task to handle plate-mode BoT where the edges and both sides get taken into account.
How shall I return this error? Are there standardised ways in brl, shall I do it just on my own like shown here: http://www.on-time.com/ddj0011.htm or shall I just write -1 into the fastf_t parameter. And in general, do I have to comment somewhere that this function has not full functionality, and if, where?
Moreover, I'm wondering, why I should implement this just for volume mode(am I right that you mean solid?), but not for surface mode, as this is also pretty simple, because there, I have just to double the result, I calculated for each face.
As I don't want to get into trouble with the deathline, I have submitted now my first patch. The algorithm itself is really ready for review. As I didn't got an answer to my error questions fast enough, I chose to easiest way, just returning -1. If this isn't enough, just send it back and give me a hint, how this has to be made correctly. Moreover, I implemented the surface mode already. If this isn't requested, or I did wrong, do also just send it back.
The work on this task is ready to be reviewed.
The deadline of the task has been extended with 2 days and 0 hours.
Did you extend the deadline to give yourself more time to review my patch or do you expect action from me. If you expect action from me, it would be great, if you answer my questions, because otherwise, I don't know, what I have to do anymore.
I could not enter text from my phone on this site for some reason, but what I wanted to say is that I find myself with very little free time this week. Thus, since you were concerned about the clock running out an I didn't think I'd be able to get to your code before it did, I figured it would simply be easier to just extend the deadline.
Johannes,
There are obviously lots of ways, but keeping the interface minimal is our usual approach. Since we don't yet know of multiple types of errors (and even this one suggested is temporary), the only cases we know about are unimplemented, a surface area, no surface area, or an error. Unimplemented is a NULL callback. Surface area is obviously a 0 value. No area is obviously 0, so using negative to imply an error fits naturally.
You are certainly welcome to also implement it for surface mode, but let us create another task for you to claim. This one is complex enough. That said, the answer is not just double the one-sided area. You have to account for the sides of any exterior edges.
Johannes, so the patch seems reasonable at a quick glance, but it obviously warrants some validation testing. We'll add some more tasks in a few days to test routines like this one that haven't been fully tested. The only problem is that your *2 multiplier for plate-mode BoT is wrong, so that'll have to be expanded on and fixed in a subsequent task. Let me know if you're interested in tackling that and I'll post the link when it's available.
Congratulations, this task has been completed successfully.
There are two follow-on tasks to integrate this into 'analyze' and to implement surface area for plate mode BoT geometry:
http://www.google-melange.com/gci/task/view/google/gci2012/8070203
http://www.google-melange.com/gci/task/view/google/gci2012/8088204