I spoke with Dr. Gorrell about first trying to call the nearest-neighbor routine, releasing the trapped exception where the matrix ends up being singular, and trapping it in the grid object's run_baker, where I could then call the connectivity-based lookup routine. Those are my next steps, as well as starting to think about pushing the 3D front ahead this week.
by next friday i need to have implemented a way to select between normal kdtree point lookups, and nearest-neighbor lookups. Hopefully i'll have that done tonight.
the qdelaunay app doesn't alway display all faces for a point. lame. I worked around it by creating the point-> face relationships manually.
There is a max recursion something happeneing when I try to save so pickle. look into this.
I spent some time writing a visualizer for blender. 10 lines of code. simple stuff.
next steps would be to move the KDTree into the mesh object. GOOD LUCK (me)!!
--HG--
rename : bin/grid_driver.py => bin/grid_random.py
rename : bin/grid_driver.py => bin/grid_regular.py
I really think that I need to create my own point object, and hang the facet information directly off of that. right now there are simply parallel arrays for q, numpy.array(x,y), and {point_index: [adjacent faces]} ...
work to be done!
mostly spent time trying to figure out subprocess (which i though i already understood). I am concerned for what will happen with large datasets.
next steps include:
1) design data struture
2) implement slurping of stdout into this structure
3) drink coke
--HG--
rename : lib/smcqhull.py => lib/smcqdelaunay.py
