You should have quoted the original message, most of us, including me, 
will not see it. It's a must when you reply to any post older than a 
month... Make that a week old or more.


> Jumping on to this thread a year later than the last post, may I offer some
> "helpful" info.
> 
> On BVH files ->  Marvelous!  They take the following format.
> 
> Hierachy -> Data.
> 
> Nice and simple.  Or not as the case may be!
> 
> The first set of data gives the "reader" the opportunity to sort out the lengths
> and offsets of all the bones in a kind of natural pose.  This gives us POV
> coders the problem that everything has to be absolute or useless/TMTC*.
> 
> The only way to take in a BVH bone Hierarchy is to import it via #read.  Problem
> number two comes in there.  We can't read any file that doesn't separate
> everything with handy commas (Maybe POV4 might? - Hint hint!!).  So, that's
> that screwed then.  But even if it could, could we come up with a
> POV-source-hierarchy that is able to adapt itself?  I couldn't, not without a
> lot of time spent at the local mental health rehabilitation center.
> 
> So, the first half of the BVH format is not good for us.
> 
> However, I did have some (limited) success with the second part!  BVH part two
> takes the the format of a spreadsheet.  I.E Row = Frame, Column = Data(Rotation
> angle, etc)
> 
> In the Hierarchy, BVH tells us how may "columns" each bone will take in the
> motion data.  So....
> 
> --= BVH data starts here =--
> 
> HIERARCHY
> ROOT Hips
> {
>  OFFSET 0.00000 0.00000 0.00000
>  CHANNELS 6 Xposition Yposition Zposition Zrotation Yrotation Xrotation
>  JOINT LHipJoint
>  {
>   OFFSET 0 0 0
>   CHANNELS 3 Zrotation Yrotation Xrotation
>   JOINT LeftHip
> 
> ->BVH hierarchy data continues from here!!
> 
> ->Until here where it becomes...
> 
> MOTION
> Frames: 432
> Frame Time: .0083333
> 16.1514 23.2122 -8.4365 -5.3491 -3.5725 9.9077 0.0000 0.0000 0.0000
> 16.1501 23.2332 -8.3453 -5.1539 -3.7875 10.0314 0.0000 0.0000 0.0000
> 16.1690 23.2611 -8.2105 -5.1359 -4.9409 9.8798 0.0000 0.0000 0.0000
> 
> --=And then ends=--
> 
> In the hierarchy bit, you'll notice "CHANNELS 6"  followed a bit later with
> "CHANNELS 3".  These two little nuggets of info describe the format of the
> motion data detailed under "MOTION".  Then "Xposition" etc describe what order
> all that data is in.
> So,
> 
> "Hips.Xposition = 16.1514, Hips.Yposition = 23.2122, Hips.ZPos...
> ....Hips.LHipJoint.Xrotation = 0.000".
> 
> Nightmare!!
> 
> However it is possible, if you cut'n'paste the motion data into a spreadsheet,
> organize it so that it fit's onto your rig and save it as a CSV file (then add
> a comma at the end of every line), you can read it into POV to take care of all
> your animation!
> 
> Way too long winded, innit.
> 
> To simplify matters, and this is what most professional animators do, it to use
> History Independent Inverse Kinematics.  I.E, you position the main body mass,
> set up the spine curve and where the hands'n'feet should be, then let maths do
> the rest!
> 
> I should probably leave it there for today, but I might post some more "useful?"
> information on this thread later...
> 
> *Too Much Too Code - Variable skeletons will take hundreds of thousands of line
> of code!
> 
> 

As long as all values are positive, most commas are effectively 
optionals. A white space can act as a separator between almost any two 
values. The problem with tab/space delimited creeps up when you have 
negative values preceded by another numeric entree.
1 2 3 4 5 6 7 are viewed as seven distinct values: 1, 2, 3, 4, 5, 6, 7
1 -2 3 4 -5 6 -7 are viewed as 4: (1-2) 3 (4-5) (6-7) or: -1, 3, -1, -1
1<2 3 4>5<6 7> is interpreted as 1, <2, 3, 4>, 5, <6, 7> In this case, 
even the space is optional, as there is no ambiguity.

You must convert each "-", BUT that of the very first value, into ",-". 
Otherwise, it will be interpreted as a substraction, not two distinct 
values.


Alain

Post a reply to this message