I'm not posting (soley) to brag about an animation.  I've got my character
walking system set up to walk along any spline, so I figured I'd try it in 3D. I
found code for the curve of a baseball seam and set it to go:

http://www.youtube.com/watch?v=Fh2pIMN3ZlQ

Does anyone have any ideas on how I can prevent the loop-de-loops? I'd like to
have it always pointing outwards from the circle.

Given a bodypath spline, I go:

#declare bodypos0=<0,0,0>+bodypath(clock) ;  // the bo
#declare bodypos1=<0,0,0>+bodypath(clock+1e-4);
#declare bodylocalz=bodypos1-bodypos0;
#declare bodylocalx=vcross(-y,bodylocalz);

object{body  Reorient(z+0.0001,bodylocalz)  translate bodypos0 }


I guess my problem is in my vcross statement.

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> I'm not posting (soley) to brag about an animation.  I've got my character
> walking system set up to walk along any spline, so I figured I'd try it in 3D. I
> found code for the curve of a baseball seam and set it to go:
>
> http://www.youtube.com/watch?v=Fh2pIMN3ZlQ
>
> Does anyone have any ideas on how I can prevent the loop-de-loops? I'd like to
> have it always pointing outwards from the circle.
>
> Given a bodypath spline, I go:
>
> #declare bodypos0=<0,0,0>+bodypath(clock) ;  // the bo
> #declare bodypos1=<0,0,0>+bodypath(clock+1e-4);
> #declare bodylocalz=bodypos1-bodypos0;
> #declare bodylocalx=vcross(-y,bodylocalz);
>
> object{body  Reorient(z+0.0001,bodylocalz)  translate bodypos0 }
>
>
> I guess my problem is in my vcross statement.

Looks pretty good.

I'm not certain, but one thing that you are doing that may make a minor
difference, is that you are basing the orientation on a vector from the current
position to one slightly ahead (bodylocalz).  I would (as I do with procedural
meshes) use one point behind and one ahead as my forward vector, which should be
approximately close to the tangent of the current point.

-tgq

Post a reply to this message

Le 09/03/2011 04:04, gregjohn a écrit :
> 
> I'm not posting (soley) to brag about an animation.  I've got my character
> walking system set up to walk along any spline, so I figured I'd try it in 3D. I
> found code for the curve of a baseball seam and set it to go:
> 
> http://www.youtube.com/watch?v=Fh2pIMN3ZlQ
> 
> Does anyone have any ideas on how I can prevent the loop-de-loops? I'd like to
> have it always pointing outwards from the circle.
> 
> Given a bodypath spline, I go:
> 
> #declare bodypos0=<0,0,0>+bodypath(clock) ;  // the bo
> #declare bodypos1=<0,0,0>+bodypath(clock+1e-4);
> #declare bodylocalz=bodypos1-bodypos0;
> #declare bodylocalx=vcross(-y,bodylocalz);
> 
> object{body  Reorient(z+0.0001,bodylocalz)  translate bodypos0 }
> 
> 
> I guess my problem is in my vcross statement.
> 
> 

what is your vector base ? (right, up, depth ?)

it seems so far that z is the horizontal direction.
x might be the vertical one ? or is it y ?

you do not use bodylocalx, so vcross is not the issue.

If you want to avoid loop-de-loops, (if I got that correctly), it just
means that you want to fix one vector (y ? well the line of shoulders)
and have a planar rotation (along the depth vector) only. If you
normalise bodylocalz, you can ask atan2 the angle needed for that
rotation (comparing to an implicit z), and then perform the rotation.

That would be fine for 2D spline.

Also, beware of z+0.0001 ... it's <0.0001, 0.0001, 1.0001> !

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

Thanks for the advice all.


Le_Forgeron <lef### [at] freefr> wrote:
>
> you do not use bodylocalx, so vcross is not the issue.
>

Ah, you leave code lying around for a while and sometimes you forget what's
active.

>
> Also, beware of z+0.0001 ... it's <0.0001, 0.0001, 1.0001> !
>

This I found to be necessary for any use of Reorient. If you transform from z to
z, it bombs out with singular matrix in inverse thing.  Not helpful.


"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:

>  I would (as I do with procedural
> meshes) use one point behind and one ahead as my forward vector,
> which should be approximately close to the tangent of the current point.
>

I don't think this is a universal solution. I'd like it to work for any spline,
whether it's ten points widely spaced along a natural_spline curve, or one
defined with a thousand points set up via trig functions.  I had an application
where I wanted it to walk around obstacles, and so I only needed to set up ten
points that avoided the obstacles. "Next point" would disrupt that system.

Post a reply to this message

Am 09.03.2011 04:04, schrieb gregjohn:
>
> Does anyone have any ideas on how I can prevent the loop-de-loops? I'd like to
> have it always pointing outwards from the circle.
>
> Given a bodypath spline, I go:
>
> #declare bodypos0=<0,0,0>+bodypath(clock) ;  // the bo
> #declare bodypos1=<0,0,0>+bodypath(clock+1e-4);
> #declare bodylocalz=bodypos1-bodypos0;
> #declare bodylocalx=vcross(-y,bodylocalz);
>
> object{body  Reorient(z+0.0001,bodylocalz)  translate bodypos0 }
>
> I guess my problem is in my vcross statement.

No, the problem is that you don't /use/ that vcross statement ;-)

Presuming that "Reorient" is a copy of "Reorient_Trans" from 
transforms.inc, the macro doesn't give you enough control over the 
transformation: It makes sure that what originally points to z+0.0001 
(BTW, why not just z?) is now pointing to bodylocalz, but takes the 
freedom to mess with all the other axes involved in order to achieve this.

For more control, compute all the new axis directions (X, Y and Z) 
yourself, and use the Shear_Trans macro, i.e.:

   #include "transforms.inc" // or copy the macro to your code
   #declare bodylocalz = vnormalize(bodypos1-bodypos0);
   #declare bodylocaly = vnormalize(bodypos0-Center);
   #declare bodylocalx = vcross(bodylocaly,bodylocalz);
                  // or -vcross(bodylocaly,bodylocalz);
   object {
     body
     Shear_Trans(bodylocalx,bodylocaly,bodylocalz)
     translate bodypos0
   }

Post a reply to this message

Am 09.03.2011 13:36, schrieb gregjohn:

>> Also, beware of z+0.0001 ... it's<0.0001, 0.0001, 1.0001>  !
>>
>
> This I found to be necessary for any use of Reorient. If you transform from z to
> z, it bombs out with singular matrix in inverse thing.  Not helpful.

I guess if you leave it like that, tansforming may still bomb in case 
the new vector happens to be z+0.0001.

>>   I would (as I do with procedural
>> meshes) use one point behind and one ahead as my forward vector,
>> which should be approximately close to the tangent of the current point.
>
> I don't think this is a universal solution. I'd like it to work for any spline,
> whether it's ten points widely spaced along a natural_spline curve, or one
> defined with a thousand points set up via trig functions.  I had an application
> where I wanted it to walk around obstacles, and so I only needed to set up ten
> points that avoided the obstacles. "Next point" would disrupt that system.

I guess his suggestion is to use

   #declare bodypos0=<0,0,0>+bodypath(clock-1e-4); // (!!!)
   #declare bodypos1=<0,0,0>+bodypath(clock+1e-4);

which doesn't really harm what you're doing, and should indeed typically 
be closer to the tangent.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.03.2011 13:36, schrieb gregjohn:
>
> >> Also, beware of z+0.0001 ... it's<0.0001, 0.0001, 1.0001>  !
> >>
> >
> > This I found to be necessary for any use of Reorient. If you transform from z to
> > z, it bombs out with singular matrix in inverse thing.  Not helpful.
>
> I guess if you leave it like that, tansforming may still bomb in case
> the new vector happens to be z+0.0001.
>

Thanks for the elegant fixes suggested.  Your code however bombed out after
about 80 frames to to the singular matrix inverse problem.  I had to fix the
Shear_Trans macro to be that below.  For some reason, I end up with guys facing
forward (+Z) in my work.


#macro Shear_Trans(A, B, C)
   transform {
      matrix < A.x, A.y, A.z,
             B.x, B.y, B.z,
             C.x, C.y, C.z+.000001,
             0.00001, -0.000002, 0>
   }
#end

Post a reply to this message

Am 10.03.2011 13:22, schrieb gregjohn:

> Thanks for the elegant fixes suggested.  Your code however bombed out after
> about 80 frames to to the singular matrix inverse problem.

I don't see why this should happen, unless at some point your spline 
heads straight at (or away from) the center.

Also note that the code I proposed presumes that your spline lies on 
(sufficiently close to) the surface of a sphere around the center.

> I had to fix the
> Shear_Trans macro to be that below.

Again you're just suppressing the problem for a particular scene, still 
risking bombing in others, rather than really fix it.

> For some reason, I end up with guys facing
> forward (+Z) in my work.

That's just strange.

Post a reply to this message

What causes the "singular" matrix error in Shear_Trans?  If it is that it is
unable to shear from <a,b,c> to <a,b,c>, then isn't it possible to add some
"epsilons" to the matrix and prevent that problem?


clipka <ano### [at] anonymousorg> wrote:
> Am 10.03.2011 13:22, schrieb gregjohn:
>
> > Thanks for the elegant fixes suggested.  Your code however bombed out after
> > about 80 frames to to the singular matrix inverse problem.
>
> I don't see why this should happen, unless at some point your spline
> heads straight at (or away from) the center.
>
> Also note that the code I proposed presumes that your spline lies on
> (sufficiently close to) the surface of a sphere around the center.
>
> > I had to fix the
> > Shear_Trans macro to be that below.
>
> Again you're just suppressing the problem for a particular scene, still
> risking bombing in others, rather than really fix it.
>
> > For some reason, I end up with guys facing
> > forward (+Z) in my work.
>
> That's just strange.

Post a reply to this message

Am 12.03.2011 15:06, schrieb gregjohn:
> What causes the "singular" matrix error in Shear_Trans?  If it is that it is
> unable to shear from<a,b,c>  to<a,b,c>, then isn't it possible to add some
> "epsilons" to the matrix and prevent that problem?

That wouldn't really be a reliable solution - because any epsilon you 
might add would just shift the problem to other parameter combinations.

AFAIK, a "singular" matrix error indicates that the generated matrix 
represents a transformation that collapses the resulting object from 3D 
to 2D - in other words, a shearing transformation where either (a) one 
of the new axes is zero, (b) two of the new axes are collinear, or (c) 
the three new axes are coplanar (i.e. lie in the same plane).

Post a reply to this message