Alain <aze### [at] qwertyorg> wrote:
> 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


What! The whole message?

>"As long as all values are positive"

The main problem of 3D space is that around seven eighths of all the coordinates
are in some way negative.  However that's quite handy to know.

I'm using a crazy 2D animation track system (X=time; Y=value to go into
something) so theoretically I could format the data file like "<0,1> <1,-1>
<2,-1>" without having to worry about the commas between the ><'s?

Might make for a prettier file as I'm determined not to use other software for
anything (except a spreadsheet to sort the motion data)

Cheers!

Post a reply to this message