Okay, I've been lazy, but gradually I've gotten around to writing
up my idea for simulated surface scanning with trace(). I've only
just started the experiments, but in the meantime, I've written a
comprehensive description of the experiments that I wanted to post
for the sake of getting comments from anyone who might understand 
this topic better than I do. 

My point in putting this all online was simply to get constructive
comments and caveats. I'm kind of hoping for something more
constructive than "you're insane, that's never going to work!"
but I may have to make due if that's all you can give me <bg>.

For anyone who might be interested in the potential of this
technique, a complete write up of the experiments I'll be 
attempting in the next couple (few) weeks can be found at...

http://www.enter.net/~cfusner/triscanRFC.html

Whether it works, fails, or something in between, I'll also
post a synopsis of what I get from these experiments in the hopes 
that even if it doesn't work for me, someone with more background 
in 3D might be able to do something with the results.

Charles

Post a reply to this message

That's some very interesting work. I hope you do get something out of it.
Could you move beyond ideas and actually show us a working example?

Post a reply to this message

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

TonyB wrote:
> 
> That's some very interesting work. I hope you do get something out of it.
> Could you move beyond ideas and actually show us a working example?

Actually, that's more of a challenge than a comment, Tony. But
I'll take it, just the same :)

Charles

Post a reply to this message

Margus Ramst wrote:
> 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.

Hmm, yes, especially if we end up with coincidents... something
else I hadn't considered, but I've just been made aware of by my
preliminary box tests. Even with a well chosen discrepency 
threshold for culling, though, there will be some minor overlap 
at the edges that will not be trimmed, so it looks like box
method may well be impractical from what I've seen so far.

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

(looks sheepish) well, that's kind of my fault for illustrating it
the way I did. Actually, I was thinking of beginning with a point 
at the pole and vrotating the rest into place before the scan, so
it would be an even distribution along the arc - it just doesn't
look that way in my illustration due to the fact that I made the
bad choice to use spherical mapping in the illustration which gave
a false impression of the distribution.

Actually, I'm about to start this phase of testing now, and I've
just finished reading up on Justin Whitton's original shield macro
and although he's converted to a proximity pattern, his original
technique of painting triangles over the surface of a complex object
caught my eye for obvious reasons. From what I gathered in his
code, although his objective was quite different in a couple ways
he seems to have used a variation of the spherical scan method 
himself, and got good coverage, so I'm definitely thinking this 
is the most promising approach, hence the acceleration of the 
experiment on that method.
 
> 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.

Actually, someone else (I think it was Ron Parker) mentioned this
before. I was, until this evening laboring under a fundamental
misconception about surface normals that led me to think this would
invert some of the triangle's normals, but as it turned out, this
was based on an untested assumption of mine that I just now proved 
a falsehood, so I appreciate you bringing this up again, as I now 
think this will form an integral part of the final technique.
 
> OK, enough rambling for one night, methinks...

Heh heh. Thanks, I appreciate the rambling, though. It will
be quite helpful. :)

Charles

Post a reply to this message