"melo" <mel### [at] coxnet> wrote in message 
news:web.47aa51553df0d7073c0d56f20@news.povray.org...
> 1. Declared the array as a 2d array
>  #declare AVAR = array[23][23];
>                         //  first dim is for Key-Frame id, goes by odd 
> numbers
>                         //  1..23, second is for Animation control 
> variables

The array index starts at '0' so 'array[23]' gives you elements 0..22.

> 2. Initialized its element to be all 0 rotation vectors
> #declare Frame = 1;
> #while ( Frame < 23 )
>   #declare AVarIndex = 1;
>   #while ( AVarIndex < 23 )

You're only using 22 elements (1..22). You're skipping element '0', but then 
you seem to be staying within the bounds of the array, so it shouldn't give 
an error, so long as you don't try using AVAR[23], which would tell you that 
the index is out of range.

I think the name 'Frame' is potentially misleading as it may get confused 
with the constant 'frame_number' and you're using it for quite a different 
purpose. I'd recommend changing it to 'KeyFrame'.

> 3. Changed my code in my Range stmts to something like, to simulate 
> simplest
> linear interpolation
>
>   #range( 2.0, 3.0 )
>      //== FRAME 5 page 113 in Caharacter Animation
>      #declare Frame = 5;
>      #declare IBP = clock - 2.0;  // In-Between Position counter
>      #declare Action = 1.15; // "Stride.Left.Frame5
>      // Now create linear combinations of joint locations from prev 
> key-frame
>      // and current key frame.  Contribution from prev key-frame linearly
>      // disappears from 1 ->0, while current pose's contribution
>      // increases    from 0 -> 1. I WANT SOMETHING BETTER!!
>      #declare AVAR[Frame][l_hip_ind] = AVAR[Frame-1][l_hip_ind]*(1-IBP)  +
>            <-25, 0, 0>*IBP; // Target: <-25*IBP, 0, 0>;
>      #declare AVAR[Frame][l_knee_ind] = AVAR[Frame-1][l_knee_ind]*(1-IBP) 
> +
>      <25, 0, 0>*IBP;  // Target: <25*IBP, 0, 0>;

I think there are a number of things wrong with this. If you're using clock 
in a range like this, then I don't see that AVAR[Frame-1] would ever get set 
to anything but 0 when you're processing Frame=5.

This is where I suggested using '#if (clock>=2)' (and '#if (clock>=1)' for 
the previous chunk of code) instead of the #range statements. You would then 
have to cap IBP, so  'IBP=min(1,clock-2)',  would take IBP from 0 to 1 as 
clock goes from 2 to 3 and then sticks at 1 in this section of code for all 
values of clock > 3. This section of code would be used whenever clock is 
greater than 2, so, in the following sections of code where clock>3 and 
where you process Frame 6, the Frame 5 data will be available to you because 
all of the SDL for frames 0 thru 6 would be run.

I would think that your calculation should be
#declare AVAR[Frame][l_hip_ind] = AVAR[Frame-1][l_hip_ind]  +  <-25, 0, 
0>*IBP;
You shouldn't need to alter the value from the previous stage once clock>2. 
You just need to add the increment for the current stage.

The whole first dimension of the array becomes a little unnecessary as you 
could just accumulate AVAR[l_hip_ind]'. Remember you're only ever processing 
a single frame at a time because all of the variables get wiped out for each 
new frame of the animation, so for each frame you need to start accumulating 
values again from 0.

It's best practice to start all of your variable names with an uppercase 
letter, because built-in functions and settings use lowercase letters. Using 
uppercase letters for your own identifiers (e.g. variable and macro names) 
should reduce conflicts with future versions of POV-Ray.

> 4. I changed rotation specification in Move_Humanoid( Frame, Action )
> AND, As oppesed to linearly switching between previous and current poses 
> in each
> of my animation stages, I would appreciate your input as to what worked 
> the best
> ..  In initial frame of the current stage, just repeat the last pose of 
> the
> previous stage?  Then use some trig funtion to move into current pose?
>

The simplest way is probably to stick with what you've got. This can take 
you quite a long way. You could always add a pose at the end of one stage or 
the start of the next if the transition does not look smooth enough.

> I hope to reduce the number of key-frames I am defining and come up with a
> better interpolation methodology.  Since you have been at skeletal 
> animation
> far longer, I would value your input there.

The 'walking' animation on the POV-Person home page uses a very small number 
of keyframes, I think it was 4 hand-posed keyframes mirrored from the left 
of the body to the right of the body for the second half of the cylcic 
sequence. The other frames were just interpolated using linear 
interpolation. If you get the keyframes in the right place you can use them 
to smooth acceleration and deceleration.

If you get to using captured motion data you'll get lots of keyframes and 
you won't need to worry so much about interpolation. When you get onto sharp 
turns with an arm swinging out in an arc, or the movement of hair as someone 
walks, then you may need to get more sophisticated, but I think it's likely 
to be a while before you'll need that and I suspect that the structure of 
your SDL will look a fair bit different by the time you get there.

> Is there some info on how I can get POV-RAY dump the values of all 
> variables
> declared whenever it reports an error during rendering, and I have on darn 
> clue
> as to what I might have done wrong.  That is how to debug ones' code with
> POV-RAY.

You need to write out information into the message stream using the #debug 
or #error directives. I usually use #debug. The most useful statements are:

#debug concat("My label: ",str(MyVar,3,3),"\n")
#debug concat("Or for Vectors: ",vstr(3,MyVar,",",3,3),"\n")

I'd recommend being selective, but if you really need to write out lots of 
values you could code a macro to do that. I don't know of any way of 
trapping the error and writing out the variables when the error occurred. 
You generally need to track it through manually and add a bebug statement 
just before the failure occurred.

> See in human beings joint rotations
> happen to be the end result of muscle contractions.

I knew that ;-)

> I love to write/chat with you how you were able to get muscles 
> manipulated.

I didn't do it in a very scientific way, I assigned the points from a mesh 
to a 2D array and applied transformations at either end of the array. I then 
used a macro to stitch the arrays for successive body parts together and 
called another macro to transform the points back into a mesh (generating 
the normals). I was quite pleased with the results though.

Regards,
Chris B.

>> There is documentation on the web site. I also have further documentation
>> for bits I developed since V2. I think there are many things it could be
>> used for. The SDL and the documentation is licensed to encourage reuse.
>
> Could you define what you mean by licensing here?

Yes. Another big and very complex area which takes us well off-topic. You 
mentioned Public Domain and there are some problems with the definition of 
Public Domain.

Some countries don't recognise the concept and there have been some attempts 
in the past to effectively 'acquire' copyright over such materials. All 
countries (so far as I know) acknowledge the existence of licenses and they 
can last in perpetuity (however long that is).

The open source community therefore tends to issue licenses to try and 
prevent unscrupulous individuals and organisations from using legal jiggery 
pockery to circumvent the intent behind making stuff freely available. See 
GPL, LGPL and the set of licenses from Creative Commons.

Post a reply to this message