User:Crdueck/log

From BRL-CAD

This page will contain a log of my progress throughout my project.

30/04/2012:

after having some difficulty compiling BRLCAD from the SVN source due to issues with missing libs, I completed my first successful build. The issue was with the unorthodox naming scheme my distro uses for the lib32 and lib64 directories, and so CMake was unable to find them.

I am now looking for some bugfixes to tackle so I can gain commit access.

09/05/2012:

while looking through the BUGS file, I found that the bug regarding drawing with an attached X session crashing MGED in command line mode unreproducible. Perhaps it was indirectly fixed in a previous patch.

As well, I've been working through the Introduction to MGED and am comfortable using it to draw and analyze all primitive shapes as well as using booleans to combine primitives into more complicated shapes.

21/05/2012:

one of my patches, adding a function to librt/primitives/ell.c that computes the surface area of an ellipsoid, was accepted a few days ago and a patch for libbu/lex.c is pending review. Although I dont yet have commit access, the first official day of coding is tommorrow, so I hope to begin producing patches related to my project and have commit access by the end of the week.

22/05/2012:

added a patch to the tracker for a centroid function for ell. The function is very simple as the central point of an ell is already stored in the rt_ell_internal struct.

24/05/2012:

the next step in my goals for this week is to try to integrate the newly written functions for ell into MGED's analyze command, as well as clean up some of the documentation regarding ell

28/05/2012:

wrote centroid, volume and surface area functions for the tor primitive. like ell, the centroid is stored as a point in the rt_tor_internal struct, and the formulas for surface area and volume use radii values found in the internal struct as well.

29/05/2012:

first day with commit access, committed the tor functions written yesterday with some slight mishaps which resulted in a chance to learn how to revert commits with svn.

Worked on a bug where MGED crashes when running "joint holds" or "joint solve" with a joint file loaded due to a NULL pointer being accessed as an array, although neither command works properly yet, an error message is now printed instead of crashing.

finally, tested the libbu/lex.c patch with the "joint list" command. the output is identical to the pre-patch version so there's some assurance that the patch hasnt introduced any parsing errors. plan to commit that patch tomorrow

30/05/2012:

the previous test for the bu_lex routine was a bit off the mark. the section of code that I rewrote dealt with skipping past initial comments in a joint file which could be C or Bash style, and the test file used originally only contained Bash comments. After adding some C comments and testing again, I found there was an error in the code. Some adjustments were made and the bu_lex routine is now working properly.

Also, i've been looking into the funtabs MGED uses to store its commands as I'll be needing to modify them to make use of the new primitive functions in MGED's analyze command. the funtab in src/mged/animedit.c is a good example.

02/06/2012:

looking into adding new primitive functions to MGED, reading source code in include/raytrace.h, librt/primitives/table.c and librt/primitives/obj_*.c. commited changes to the rt_functab in raytrace.h, adding function pointers for the new functions and made changes to the func_tab array in librt/primitives/table.c as well

05/06/2012:

added a general volume function for tgc that determines if a general tgc is a rec, rcc, tec, or trc and computes the volume.

06/06/2012:

added a general centroid function for tgc. the function handles rec, rcc and trc, but the formula for tec still needs to be determined. Also continued working on integrating the new callback functions into the rt_functab interface so they can be used in libged/analyze.c

07/06/2012:

fixed math error in rt_ell_surf_area(). made changes to analyze_ell() in libged/analyze.c to make use of the new callback functions and tested the new functions against the old implementation to ensure correctness.

updated analyze_tor() to include the new callbacks for tor

added rt_tgc_surf_area() to primitives/tgc.c and updated analyze_tgc() to include the new callbacks for tgc.

tested the analyze command for tgc, tor and ell against the old implementation and tested corner cases for ells with zero vector axis.

12/06/2012:

working on rt_arb_volume(), this primitive is more difficult to deal with than the previous ones. I've found a formula that will calculate the volume of an arb with an arbitrary amount of vectors, the tricky bit is that it requires the area of each face on the arb. Its been difficult to find a method to calculate the area of the faces from the given vertices of the arb.

also, there is already an implementation of rt_arb_centroid() which is used in a few places throughout libged/analyze.c and primitive/arb8.c. Unfortunately the function signature of the current implementation does not match the signature of the previous centroid functions i've written, so it doesnt currently fit into the rt_functab interface i've been using. It will take some work to ensure that it can be called from the rt_functab and also not cause problems in any of the places its already being used.

14,15,16/06/2012:

implemented rt_arb_volume() and tested analyze_arb() using the new function. the volume function works, but it has to declare a new bn_tol struct that could easily be passed from its calling function analyze_arb(). Unfortunately due to the strict function signature imposed by the rt_functab interface, I'm unable to change to type, or number of inputs to the function.

This is annoying because the current implementation for rt_arb_centroid() has an extra input that must be removed, but its value is required to calculate the centroid and so must be found from scratch, using more struct declarations, and extra function calls. rt_arb_surf_area() also suffers from a similar problem. Having the option of changing the number of inputs each function takes per primitive would greatly reduce the amount of repeated or unnessecary code needed, and the functions themselves would be much cleaner.

while it was not as much an issue as with arb, the callback functions for tgc could also benefit from extra inputs. i have a feeling this will be a recurring problem as the geometric shapes of the primitives become more complicated (i chose to work on the primitives in order of most geometrically simple to more complicated).

18/06/2012:

implemented volume, surface area and centroid functions for rpc. tested the new functions and updated analyze_rpc() to use the new callbacks.

19/06/2012:

found some errors in rt_tgc_centroid(). the centroid was being calculated from the origin instead of from the center of the the base of the tgc. also made some improvements using the VJOIN1 macro i learned of while writing rt_rpc_centroid().

found an equation for the volume of a epa while investigating formulas for the arc length of a hyperbolic/parabolic segment, and then wrote rt_epa_volume().

Unfortunately, the formulas regarding hyperbolas involve integrals containing non-elementary functions such as the elliptical integral. I'll see if its possible to simplify these as they are needed to calculate the surface areas of tec, rec, eta, ehy, and rhc.

21/06/2012:

while working with the rt_arb_centroid function, i noticed that it's algorithm is incorrect. for example, it reports the centroid of an arb6 consisting of [(2,0,0),(0,2,0),(0,0,2),(-2,0,0),(0,-2,0),(0,0,-2)] to be (0,-0.33...,0) (as opposed to the correct (0,0,0)). this is because the arb6 is stored as an arb8 with some duplicate points, but the ordering of the points is not consistent with what rt_arb_centroid expects and so in calculating the centroid some duplicate points are used and a unique point may be completely ignored.

this lead me to take a look at rt_arb_get_cgtype() (which is called before rt_arb_centroid()), as the comments suggest that this function re-orders the points of the arb into "GIFT standard". the function did not modify the arb in any way, but the code was difficult to read, could be improved by simplifying some vector operations with existing macros, and had some kludgy sections so i decided to clean it up as much as possible. I then tested it against many different kinds of arbs until the output was correct for all cases.

i plan on fixing the errors in rt_arb_centroid() tommorrow.