The main thing is that all your normals are pointing in the wrong direction.
They're all pointing away from the origin but they should all be pointing
away from the corresponding point on the spline.

The attached "spheresweepA.jpg" has cylinders added along your normals, and
"spheresweepB.jpg" shows where they should be pointing (I've reduced the
number of polygons and switched off reflection to make the normal cylinders
clearer).

To fix this, remove the "p0+" and "p1+" bits from the definitions of the
normal vectors, i.e.

  cos(m/numrotes*2*pi)*drx1    +sin(m/numrotes*2*pi)*dry1,
  cos((m+1)/numrotes*2*pi)*drx1+sin((m+1)/numrotes*2*pi)*dry1,
  cos((m+1)/numrotes*2*pi)*drx2+sin((m+1)/numrotes*2*pi)*dry2,

  cos(m/numrotes*2*pi)*drx1    +sin(m/numrotes*2*pi)*dry1,
  cos((m+0)/numrotes*2*pi)*drx2+sin((m+0)/numrotes*2*pi)*dry2,
  cos((m+1)/numrotes*2*pi)*drx2+sin((m+1)/numrotes*2*pi)*dry2

This nearly fixes things, but there's also a typo in the lines that say
               #declare drx2=arr1*vnormalize(vcross(vrotate(dr1,40),dr2));
They should say "vrotate(dr2,40)" not dr1.
You recalculate the position and normal of each point 6 times, and this typo
means that 3 of the 6 recalculations are slightly misplaced.

Post a reply to this message

Attachments:
Download 'spheresweepA.jpg' (74 KB) Download 'spheresweepB.jpg' (77 KB) Download 'spheresweep.jpg' (65 KB)

Preview of image 'spheresweepA.jpg'

Preview of image 'spheresweepB.jpg'

Preview of image 'spheresweep.jpg'

Mike Williams wrote:

> You recalculate the position and normal of each point 6 times,
> and this typo means that 3 of the 6 recalculations are slightly
> misplaced.

Oh, my.  You mean five unnecessary recalculations?  Sometimes I think doing
this kind of stuff with the intellectual capacity I have is like a
five-year-old driving a heavily loaded tractor trailer.


Nonetheless, I am extremely grateful that you took the time to fix the code.
And my I ask, "Source, please?"  ;-)  It would have great value in my
animations as I try to make pipes: sliced & diced torii were just giving me
too many headaches.

But seriously, do you think this will have any universal value as a macro--
the sphere sweep per se is a really slow rendering.

Greg M. Johnson

Post a reply to this message

Wasn't it gregjohn who wrote:
>Mike Williams wrote:
>
>> You recalculate the position and normal of each point 6 times,
>> and this typo means that 3 of the 6 recalculations are slightly
>> misplaced.
>
>Oh, my.  You mean five unnecessary recalculations?  Sometimes I think doing
>this kind of stuff with the intellectual capacity I have is like a
>five-year-old driving a heavily loaded tractor trailer.
>
>
>Nonetheless, I am extremely grateful that you took the time to fix the code.
>And my I ask, "Source, please?"  ;-)  It would have great value in my
>animations as I try to make pipes: sliced & diced torii were just giving me
>too many headaches.

I didn't keep the versions with the normals sticking out, and you can
obtain the final version by applying the changes I listed.

>But seriously, do you think this will have any universal value as a macro--
>the sphere sweep per se is a really slow rendering.

It might be a good idea to produce something that does this, but I'd
suggest a slightly different approach. I'd use Ingo Janssen's
makemesh.inc to do the mesh creation (because it's there, and it gives
us extra stuff like uv mapping, *.obj support and file cacheing) and put
our reusable stuff into a separate "sweepmesh.inc" file.

I'd only calculate each point once, and I'd calculate the spline
direction symmetrically (i.e. by taking a small step backwards and
forwards and taking the difference, rather than just stepping forwards).

I've nearly got some code working. It works for your particular splines,
but for some simple splines the points suddenly cross over to the other
side of the tube. Each calculated point is an actual point on the
surface, but the ring of points is twisted through 180 degrees.
I guess that the problem might be something to do with the line
        #declare drx1=arr0*vnormalize(vcross(vrotate(dr1,40),dr1));
which I borrowed from your code without understanding it properly. If
you have a spline that turns so that its direction (dr1) changes from
angling slightly away from the origin to angling slightly towards it I
think the vcross() suddenly points in the opposite direction.

See my current code in binaries.scene-files.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Mike Williams who wrote:
>
>I've nearly got some code working. It works for your particular splines,
>but for some simple splines the points suddenly cross over to the other
>side of the tube. Each calculated point is an actual point on the
>surface, but the ring of points is twisted through 180 degrees.
>I guess that the problem might be something to do with the line
>        #declare drx1=arr0*vnormalize(vcross(vrotate(dr1,40),dr1));
>which I borrowed from your code without understanding it properly. If
>you have a spline that turns so that its direction (dr1) changes from
>angling slightly away from the origin to angling slightly towards it I
>think the vcross() suddenly points in the opposite direction.

If I reduce the vrotate vector from 40 to 1 then the flipping only seems
to happen on splines that have points where the direction is close to
<1,1,1>, but for the code to be generally useful it needs to be fixed so
that it never flips.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message