In case you get bored before the end, I'll say this now:
Whatever the results, you're in for an interesting project. One that I
considered but soon dropped as too difficult. Should you succeed, there would be
quite a few applications for your tool.

A few comments:

The 'Box Method':
With the exception of scanning objects with only 90 degree edges, you would
always have to do the triangle-culling pass. Otherwise you will not just have
redundant triangles, but these triangles will intersect - can be very
conspicuous.
Howeveer, with an above-average number of triangles, culling will become very
slow. If you have to compare every point to every other point, the number grows
exponentially. One answer would be to arrange the points in some tree-structure
(octtree, kd-tree, ...) but I'm not sure that's feasible or even possible in POV
script.
My fur generator uses a sampling macro very similar to the box method you
describe. It gives a statistically uniform distribution of points over the
surface, but I consider it unsuitable for tessellation.

The spherical methods:
These have the main disadvantage of a very non-uniform distribution of points
from the poles to the equator, and at different distances from the axis. So, you
must at least provide, with both methods, for transforming the sampling axis to
suit an object's geometry.
A partially improved solution might be an equal-area distribution of samples (on
the sphere), but I don't have the math skills to help you there.

I see no need for the 'progressive intersection' method. My sampling macro
simply does a new trace from the current intersection point, in the same
direction as before. It continues doing so until no more intersections are
found. Thus, you always get all intersections along the current sampling ray.

I find that trace() should _not_ return the perturbed normal, since normal
perturbations are not a part of object geometry.
Anyway, a normal map is used to simulate small surface features and you would
need a very high density mesh to recreate it in actual geometry. I say let
normal maps remain normal maps.
Should you still wish to find the perturbed normal, it is already theoreically
possible in MegaPov. Normal perturbations are calculated from your regular
pattern values (I think POV evaluates the gradient of the pattern function by
sampling a few points around the current point). You could recreate this with
eval_pattern. I'm not sure if this function lets you mixed patterns though. Nor
do I think a pattern identifier can be passed as a macro parameter.

OK, enough rambling for one night, methinks...

Margus

Post a reply to this message