Difference between revisions of "User:Crdueck/log"

From BRL-CAD
Line 57: Line 57:
  
 
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.
 
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).

Revision as of 16:51, 16 June 2012

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).