Tor Olav Kristensen wrote:
> 
> Chris Huff wrote:
> >
> > In article <3A61158D.9D409B1B@online.no>, Tor Olav Kristensen
> > <tor### [at] onlineno> wrote:
> >
> > > Hmmm ... Are you sure about this ?
> >
> > The normal to the -x side of a box is -x. The top of the box is then
> > sheared +x so the -x and +x faces are at a 45 degree angle...but points
> > still remain in the same xz plane as they were before, the -y and +y
> > faces remain perpendicular to the y axis. The normal should be at a 45
> > degree angle now, <-sqrt(2)/2, sqrt(2)/2, 0> to be precise, but since
> > the two sample points were in the same xz plane, their position relative
> > to each other is the same, and the normal is still -x.
> 
> I see.
> 
> Then would this work ?
> 
> #declare dP = Deform(P);
> #declare vN = vnormalize(N);
> 
> #declare AA = 0.01;
> #declare BB = 0.1;
> 
> #declare dNpx = vnormalize(Deform(P + AA*(vN + x*BB)) - dP);
> #declare dNmx = vnormalize(Deform(P + AA*(vN - x*BB)) - dP);
> 
> #declare dNpy = vnormalize(Deform(P + AA*(vN + y*BB)) - dP);
> #declare dNmy = vnormalize(Deform(P + AA*(vN - y*BB)) - dP);
> 
> #declare dNpz = vnormalize(Deform(P + AA*(vN + z*BB)) - dP);
> #declare dNmz = vnormalize(Deform(P + AA*(vN - z*BB)) - dP);
> 
> #declare dN = vnormalize(dNpx + dNmx + dNpy + dNmy + dNpz + dNmz);

I see now that this will probably not work either.

I'll think of it while I sleep.  :)


Goodnight from Tor Olav
-- 
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

"Chris Huff" wrote:
> are you only using matrix transformations?

No.

> Or were you only using shearing matrices as an example?

Yes.

> I'll be thinking about this problem for a while...

I've tried this:

#local SomeVector = x;
#local Small = 0.001;
#local N1 = Perpendiculize(SomeVector,N);
#local N2 = vcross(N1,N);
#local deformP = mezz_deform(P);
#local nN1 = mezz_deform(N1*Small+P)-deformP;
#local nN2 = mezz_deform(N2*Small+P)-deformP;
#local deformN = vnormalize(vcross(nN1,nN2));

It doesn't work, but I can't understand why.

( Perpendiculize(A,B) adjusts A so it is perpendicular to B. The adjusted A
is returned. )

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a6190d0@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> It doesn't work, but I can't understand why.
> 
> ( Perpendiculize(A,B) adjusts A so it is perpendicular to B. The 
> adjusted A is returned. )

I think you need to make two vectors perpendicular to the normal, deform 
those, and find a vector perpendicular to those. It looks like this 
might have been what you are doing...cross products give me a headache. 
Maybe something along the lines of:

#local Small = 0.001;

#macro mezz_deform_dir(P, DP, N) (mezz_deform(P + N*Small) - DP) #end

#macro DeformNormal(Point, deformedPoint, Normal)
    #local N1 = Perpendiculize(Normal, y);
    #local N2 = Perpendiculize(Normal, N1);

    #local N1 = mezz_deform_dir(Point, deformedPoint, N1);
    #local N2 = mezz_deform_dir(Point, deformedPoint, N2);

    #local deformedNormal = Perpendiculize(N1, N2);
    (deformedNormal)
#end

I don't think a third point will be necessary, because the normal 
shouldn't change if the surface moves perpendicularly to it...but I may 
be wrong, it may be something to try.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> I think you need to make two vectors perpendicular to the
> normal, deform those, and find a vector perpendicular to
> those. It looks like this might have been what you are
> doing...cross products give me a headache.

It's exactly what I did. It's not what your solution does though... :)

> I don't think a third point will be necessary

It wouldn't make sense to use a third point.

The solution I posted myself actually turned to work perfectly after all.
The strange results I was getting were caused by a bug a somewhere else in
my macro.

Thanks for the help anyway.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune <run### [at] inamecom> wrote:
> The solution I posted myself actually turned to work perfectly after all.
> The strange results I was getting were caused by a bug a somewhere else in
> my macro.

In effect, you're deforming the plane defined by the current normal at the
point of the current vertex.  For the most accurate results, I guess you'd
use the derivative of your deformation function - in the general case, using
small distances along the plane should be fine.

And yes, as you've found I didn't take this into account when creating the
mesh deformation macros in the Compressed Mesh Macro File.  My only defence
is laziness - and when I first created the macros I only had one mesh that
didn't use smooth triangles, so it didn't bother me much!

Post a reply to this message

Rune wrote in message <3a60d0eb@news.povray.org>...
> I'm working on some deformation macros that deforms the point vectors and
> the normal vectors in a mesh.
>
> Deforming the points is easy. Deforming the normals is a bit more
> complicated.

yes, little more complicated ...

> To find a deformed normal I try to find the deformed points very close to
> the start point of the normal, and see how the direction changes. However, I
> can't figure out quite how to do it.

in the first version of my deform patch I had such calculation of normal - first
I had calculated n points around of deformed point on plane perpendicualr to the
base normal with distance d, and then deformed and calculated weighted normal of
achived virtual triangles

in symbolic code:

input:
  int n - n points around base/deformed point
  dbl d - distance beetwen points and base point
  vect P - base point
  vect N - normal in base point
  func deform( point ) - deformation as function

output:
  vect ND - normal after deformation
  vect D - point after deformation

code:
  dbl local a,b,c,i,j,p,l[n]
  vect A[n]

  p = N[Y]*N[Y]

  if ( p<(1.0-EPSILON) )
   {
    p=d/sqrt(1-p)
    A[0] = p * < N[Z], 0.0, N[X])
   }
  else
   {
     A[0] = < 0.0 , 0.0 , d >
   }

  for ( i = 1 ; i < n ; i = i + 1 )
   {
    A[i] = vaxis_rotate( A[0] , N , i * 2*pi/n )
   }

  D = deform( P )

  for ( i = 0 ; i < n ; i = i + 1 )
   {
    A[ i ] = deform( A[ i ] + P ) - D
    l[ i ] = vlength( A[ i ] )
   }

  DN=< 0.0, 0.0, 0.0 >

  for ( i=0 ; i < n ; i = i + 1 )
   {
    j = i+1
    j = ( j<n ) ? j : 0
    c = vlength( A[ i ] , A[ j ] )
    p = ( l[ i ] + l[ j ] + c ) / 2.0
    p = sqrt( p * ( p - l[i] ) * ( p - c ) * ( p - l[j] ) )
    DN = DN + p * vnormalize( vcross( A[ i ] , A[ j ] )
   }

  DN = vnormalize( DN )

I hope it helps

ABX

Post a reply to this message

"Chris Colefax" wrote:
> And yes, as you've found I didn't take this into account when
> creating the mesh deformation macros in the Compressed Mesh
> Macro File.  My only defence is laziness - and when I first
> created the macros I only had one mesh that didn't use smooth
> triangles, so it didn't bother me much!

:)

I intent to release my own macros sometime that can read PCM files.
They will have both advantages and disadvantages compared to your macros.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Chris Colefax <chr### [at] tagpovrayorg> wrote:
: And yes, as you've found I didn't take this into account when creating the
: mesh deformation macros in the Compressed Mesh Macro File.  My only defence
: is laziness - and when I first created the macros I only had one mesh that
: didn't use smooth triangles, so it didn't bother me much!

  A working version would apply transformations differently on vertices and
normals.
  If a PCM is optimized, some vertices and normals can be shared. This causes
a problem (and it's a headache in the mesh compressor program as well).

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

"Warp" wrote:
>   A working version would apply transformations differently
> on vertices and normals.

Yes.

>   If a PCM is optimized, some vertices and normals can be
> shared. This causes a problem

That can easily be solved, it just requires more memory in the parsing
stage...

As I said, I'm working on a PCM reading macro that handles normal
deformation correctly. See p.b.i for an example image...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune <run### [at] inamecom> wrote:
:>   If a PCM is optimized, some vertices and normals can be
:> shared. This causes a problem

: That can easily be solved, it just requires more memory in the parsing
: stage...

  It's, however, a rather rare case. I suppose that most people don't
optimize the PCM, and even if they do, it seldom succeeds (unless they
use a very high error tolerance).
  I'm not sure if it's worth the efforts to take that possibility into
account...

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message