POV-Ray : Newsgroups : povray.advanced-users : Inverse Kinematics : Re: Inverse Kinematics Server Time
29 Jul 2024 00:34:05 EDT (-0400)
  Re: Inverse Kinematics  
From: David Wallace
Date: 22 Jul 2003 15:14:08
Message: <3f1d8d00@news.povray.org>
> > An array-based approach works too.
> >
> > #declare ataObjs = array[8] { ataBase, ataSectB, ataSectM, ataSectM,
> > ataSectM, ataSectH, ataHandL, ataHandR }
> > #declare ataLens = array[8] { atabHgtB, atasH, atasH, atasH, atasH,
atasH,
> > 0, 0 }
> > #declare atArmAng = array[1][3]
> > #declare atArmAng[0][0] = array[7] { <-40, 20,-35>, x*26, x*30 , x*28,
x*33,
> > x* 5,-x*10 }
> > #declare atArmAng[0][1] = array[7] { < 10, 70,  5>, x* 6, x* 4 , x* 8,
x*13,
> > x*10,-x*20 }
> > #declare atArmAng[0][2] = array[7] { <- 3,-90,-15>, x*10, x* 8 , x*14,
x*11,
> > x*15,-x*30 }
> > #declare ataMoves = array[7]
> >
> > #macro ManipArm(Objects, Lengths, Joints, Moves)
> >  #local aSiz = dimension_size(Joints,1);
> >  #debug concat(str(aSiz,0,0), " objects.\n")
> >  #local ps = 0;
> >  #while (ps<aSiz)
> >   #local rt = ps;
> >   #declare Moves[ps] = transform {
> >    #while (rt>=0)
> >     rotate Joints[rt]
> >     translate y*Lengths[rt]
> >     #local rt = rt - 1;
> >    #end
> >   }
> >   #local ps = ps + 1;
> >  #end
> >  union {
> >   #set ps = 0;
> >   object { Objects[ps] }
> >   #while (ps<aSiz)
> >    #local ps = ps + 1;
> >    object { Objects[ps] transform { Moves[ps-1] } }
> >   #end
> >  }
> > #end
> >
> > #macro atArm(obn, arn) object { ManipArm(ataObjs, ataLens,
> > atArmAng[obn][arn], ataMoves) } #end
> >
> > The idea is to set up the transforms for each object first so that
nesting
> > becomes unnecessary:
> >
> > If you want the object definitions check out my "Manipulator arm"
thread.
> >
>
> Yes, such an approach 'is' possible, but far more complex, especially for
> very complex mechanisms. Nesting has the advantage of providing a clear
> structure for the objects relationships within the SDL code itself. You
> can see immediately where you screwed something up by incorrectly nesting
> it. Using an array system requires, for one thing keeping track of the
> current position of 'both' ends, since sub objects do not automatically
> move to match to position and location of their parent in such a system.
> It isn't something I would attempt to make adjustments to by hand. ;)
>

What the ataLens array does is position each object onto the meeting point
of its parent.  This only has to be done when (re)designing the object.  The
ataArmAng array "poses" the structure.  The ManipArm macro takes the
individual positioning and posing transforms and combines them in reverse
order.  My macro is a bit basic in that it assumes the connecting sections
pile up vertically.  ataLens could just as easily contain 3D vectors,
matrices, or transforms.

In your nested structure you still have to pose each item and position it
onto the end of its parent.  The result is an object which you then
transform again, etc.  All I did was use a macro to combine the transforms
in ataLens into a single transform in ataMoves for each arm segment.  You
don't have to "make adjustments by hand"-- the ManipArm macro makes them for
you.  The posing transforms need to be watched in both systems, however.

The issue I have with nesting comes from what I suspect are limits within
POV-Ray on the number of nested levels you can have.  It's not that nesting
is inherently wrong; it actually works for simple models.  But heaven help
you if you want to build a millipede using nesting.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.