The evolution seems to work mostly fine now, but there seem to be a problem (NAN on color)
which needs to be debugged. The reasons needs to be investigated..
In Gridaccell I added a method which zeros the correspondence data of the rays,
so they can be re-computed at the next iteration.
I also added the closest point code to OLD.h
A PokeRay is nothing else than a ray which is allowed to "poke" only
one specific face.
I changed the class GridAccell to allow to keep track of pokerays rather
than simple rays and modified "mode == FACEINTERSECTIONS" in Balloon::updateViewField
to use these structures instead. Note that when using this mode you discard rays
which have t<0, so you don't even need to re-specify anything in the accellerator,
as wahtever will be used by the next mode will be simply discarded...
I also added a new mode (STILL IN DEVELOPMENT) called BIFACEINTERSECTIONS which
do not only look at the intersections found by a ray in the +side but also
takes a look behind the scanpoint.
the smoothing term is damped by a functional that goes to zero when the distance term is zero.
The gridaccell has also been modified to march rays not only in the direction of the ray itself,
but also up to an offset in the opposite direction. This can be done by offsetting the starting
point along -r.d by some value. GridAccell::trace_ray( ray, off ).
Note that The vasewidget settings have been changed for this new debugging step!!
The evolution seems to proceed well!
I tried first a dummy evolution which shrinks the field by .05 at each iteration (check balloon evolve and the if(false) therein.
Then, I corrected the refresh of the data structures for the field update
The simple test contraction works well, I also tried the tests on the sphere dataset using only view direction, as the laplacian complains about marching cube having
svn commit -m
