|
 |
"Chris B" <nom### [at] nomail com> wrote:
> "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.
Well, I did wonder about that, the help files associated with window 3.6 version
did not mention this. The examples given about arrays made me think, POV-RAY
might have implemented arrays starting at '1', which gave my eyebrows a raise.
Now I feel better and I shall fix my code.
>
> > 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.
Thank you, given I really have 23 joints to rotate about, and 23 Key-Frames
going at odd numbers, mostly. I'll look into this.
> 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'.
I agree.
>
> > 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 KeyFrame = 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[KeyFrame][l_hip_ind] = AVAR[KeyFrame-1][l_hip_ind]*(1-IBP) +
<-25, 0, 0>*IBP;
> > #declare AVAR[KeyFrame][l_knee_ind] = AVAR[Frame-2][l_knee_ind]*(1-IBP) +
<25, 0, 0>*IBP;
> 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.
Stage=KeyFrame 1 was a special case, it simply did
#declare AVAR[KeyFrame][l_knee_ind] = <10, 0, 0>*IBP;
For other KeyFrames there was an attempt to use the previous one.
#declare AVAR[KeyFrame][l_knee_ind] = AVAR[KeyFrame-2][l_knee_ind]*(1-IBP) +
<25, 0, 0>*IBP; // Target in this KeyFrame is <25,0,0>
Here Since IBP goes from 0 -> 1, and I was multiplying previous KeyFrame's
contibution by (1-IBP), which goes from 1->0, so I thought, I was lineary
decreasing its contribution, while I was linearly adding the contribution of
the target rotation by multiplying it by IBP which goes from 0->1.
> 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.
Yes, I agree that I only should add the increment from the current stage. Here
you assumed one paradigm while I used another. For each KeyFrame, I had figured
out and defined the target rotation vectors for all involved joints, but not as
increments from the
previous pose. Now, I have a macro IRV short for InterpolateRoationVector.
// Interpolate Rotation Vector
#macro IRV( Prev_V, Target_V, IBP )
// find the difference between target rotation vector of the joint and
// rotation vector reached during the previous stage.
#local Diff_V = Target_V - Prev_V;
#local Result = <0, 0, 0>; // make sure Result is a 3D vector
// IBP is normalized clock variable by stage that goes from 0 to 1. When
// it is 0, we like rotation to be equal to the previous rotation vector,
// and as time moves on we like to add the difference onto the Prev
#local Result = Prev_V + Diff_V*IBP;
Result // Return the result to the caller
#end // end IRV
The call for this macro are like
#declare AVAR[KeyFrame][l_hip_ind] = IRV( AVAR[KeyFrame-2][l_hip_ind], <35,
0, 0>, IBP );
#declare AVAR[KeyFrame][r_knee_ind] = IRV( AVAR[KeyFrame-2][r_knee_ind],
<55, 0, 0>, IBP );
#declare AVAR[KeyFrame][l_elbow_ind] = IRV( AVAR[KeyFrame-2][l_elbow_ind]
+ <0, 0, 0> /, IBP );
For now target_rotation_vectors are hardcoded.
For joints for which there are no new targets, or the same target, I need to
make sure they move back to their default position. While I try to describe
the problem to you, I notice things that I am yet to address.
By keeping each KeyFrame in its own Animation Stage, I was thinking I oould
encourage modularity, target positions for each KeyFrame could go into their
...pose files, as you had recommended. See I manualy defined both right and left
side KeyFrames. Now once it is working if I turn cyclic animation on, he should
keep walking and walking?
Hey, do we have a library of 3D POV-RAY environments, so s/he can go hiking,
mountaineering, walking in the moon, in the city?
sorry, I am getting too excited...
>
> 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.
I was not ready to let go of the staged animation concept. Buuuut, I finally
get it.. Not only I needed a way to remember between stages, even as POV-RAY
animates within each stage, it has no way of remebering what happens from its
Frame to Frame. I set up what happens from my KeyFrame to KeyFrame, however it
may not enough. And I must have miscommunicated something, Each Stage only
increments/changes the KeyFrame assigned to it, not the previous ones. When
the end of stage is reached, the array contains the pose hopefully achieved
during that stage.
>
> 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.
Thanks for that warning as well. If this was mentioned somewhere, I obviously
missed it.
>
> > 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'll be quite happy when I get what I have working.
>
> > 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.
Thanks.
>
> 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.
I agree. I still have a long way to go, before I get to skinning, my person is
bound to stay in its a skeletal form that has the intelligence to move. One
thing I noticed is how mood could affect body posture even in walking. So, I
might add mood selector. walk happy, walk proud, walk depressed, etc...
> > 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.
Thank you so much. Now I have an entry point to debugging. ;-) ;-)
>
> > See in human beings joint rotations
> > happen to be the end result of muscle contractions.
>
> I knew that ;-)
I knew, you did. Sorry, I was just highlighting where I wanted to take this. i
can't help it, I get excited talking, oops I mean writing about this stuff.
> > 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.
Thanks, scientific part might come from knowing which muscles to apply what
transformations. Did you have that intelligence. I have an arts+science
book that talks about which muscles in the face control which facial expression,
really cool stuff. Then the whole talking part, the musculature of mouth
generating specific sounds. Yet that is a separate field of study. Oh boy,
overwhelming.
>
> 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.
Now we are totally outside my realm of knowledge. Well, I assume being in US,
POVPerson could be useable.
Thanks Chris.
Meltem
Post a reply to this message
|
|
