Has anyone figured out an economic way to handle motion capture to use for
skeletal animation joint rotation vector specifications in different poses?

I presume, digital image processing with multiple digital cameras with optical
markers might still be the least expensive option?

So far, I have used pose pictures in Character animation books, drew some
pictures for myself, and from those picture eyeballed the joint rotation
vectors.

Given I have 23 joint rotation vectors, 10-15 of which get involved in most
gross poses I played with. The going had been extremely slow.

Thanks,
Meltem

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47b53aaa96bac4aa92254edf0@news.povray.org...
> Has anyone figured out an economic way to handle motion capture to use for
> skeletal animation joint rotation vector specifications in different 
> poses?
>
> I presume, digital image processing with multiple digital cameras with 
> optical
> markers might still be the least expensive option?
>
> So far, I have used pose pictures in Character animation books, drew some
> pictures for myself, and from those picture eyeballed the joint rotation
> vectors.
>
> Given I have 23 joint rotation vectors, 10-15 of which get involved in 
> most
> gross poses I played with. The going had been extremely slow.
>
> Thanks,
> Meltem

This is a tricky question because the economics depend on what you have 
access to and how much you're likely to get value out of it. If you're doing 
movies, then it's economic to splash out on the most professional kit about. 
If you're at college, you may be able to find someone close with some form 
of solution that you could team up with.

I don't think there's a free way of doing it. Even image processing of 
optical markers needs some software and I don't recall seeing any freeware 
that does that sort of thing, though I haven't done a Google on that sort of 
thing recently.

Most data capture techniques require that the data be cleaned up after data 
capture. For example, a certain proportion of optical markers are likely to 
be out of sight in each frame. So far as I know, even some of the more 
sophisticated hardware can generate spikes that register an unrealistic 
joint position from time to time, so you still need hours of work to create 
a smooth sequence.

If you're talking about economies in terms of time, then I think you'd have 
to be doing an awful lot of this to pay back the time it would take to 
evaluate solutions, buy and learn how to use one, then work out how to get 
the output into a format that you can use with POV-Ray.

On the other hand there are free BVH files out there that other people have 
captured which contain thousands of poses (which cuts the problem in half). 
There are also free tools for visualising pose data and potentially for 
modifying it using wireframe characters that could cut the time to hand-pose 
a model. You still have the problem of converting it into the format you 
wish to use though.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:

Thanks Chris.

Could you pls tell me what BVH files are?

Yes, "economics", the way I used in passsing was very ill-defined.  As a
differently-abled adult, ex-engineer,  who is trying very hard to teach herself
character animation.  Who feels the progress had been painstaking
slow.

You are right, even digital image capture & processing would require investment
in hardware and software.  The information I discovered on various ways to
accomplish this the state of technology was simply mind boggling.  Then I found
myself researching 6D rotation sensors.

Thanks anyway...


> "melo" <mel### [at] coxnet> wrote in message
> news:web.47b53aaa96bac4aa92254edf0@news.povray.org...
> > Has anyone figured out an economic way to handle motion capture to use for
> > skeletal animation joint rotation vector specifications in different
> > poses?
> >
> > I presume, digital image processing with multiple digital cameras with
> > optical
> > markers might still be the least expensive option?
> >
> > So far, I have used pose pictures in Character animation books, drew some
> > pictures for myself, and from those picture eyeballed the joint rotation
> > vectors.
> >
> > Given I have 23 joint rotation vectors, 10-15 of which get involved in
> > most
> > gross poses I played with. The going had been extremely slow.
> >
> > Thanks,
> > Meltem
>
> This is a tricky question because the economics depend on what you have
> access to and how much you're likely to get value out of it. If you're doing
> movies, then it's economic to splash out on the most professional kit about.
> If you're at college, you may be able to find someone close with some form
> of solution that you could team up with.
>
> I don't think there's a free way of doing it. Even image processing of
> optical markers needs some software and I don't recall seeing any freeware
> that does that sort of thing, though I haven't done a Google on that sort of
> thing recently.
>
> Most data capture techniques require that the data be cleaned up after data
> capture. For example, a certain proportion of optical markers are likely to
> be out of sight in each frame. So far as I know, even some of the more
> sophisticated hardware can generate spikes that register an unrealistic
> joint position from time to time, so you still need hours of work to create
> a smooth sequence.
>
> If you're talking about economies in terms of time, then I think you'd have
> to be doing an awful lot of this to pay back the time it would take to
> evaluate solutions, buy and learn how to use one, then work out how to get
> the output into a format that you can use with POV-Ray.
>
> On the other hand there are free BVH files out there that other people have
> captured which contain thousands of poses (which cuts the problem in half).
> There are also free tools for visualising pose data and potentially for
> modifying it using wireframe characters that could cut the time to hand-pose
> a model. You still have the problem of converting it into the format you
> wish to use though.
>
> Regards,
> Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47bd1332bbc54f08587ef5e20@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>
> Thanks Chris.
>
> Could you pls tell me what BVH files are?

It's just one of the formats used for storing motion capture data. It's 
actually a proprietary format but the format is human readable and 
published. See:
http://www.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html

When I was doing this sort of thing there were quite a few free animation 
files in BVH format available for download, including dancing animations and 
kick boxing animations that folk had captured, so I wrote a little converter 
to convert BVH pose files into the format I used for POV-Person.

>
> Yes, "economics", the way I used in passsing was very ill-defined.  As a
> differently-abled adult, ex-engineer,  who is trying very hard to teach 
> herself
> character animation.  Who feels the progress had been painstaking
> slow.
>

Well, it's a pretty advanced topic with lots of interesting aspects and 
offshoots. It's possible to spend months just getting the animation of a 
single joint looking realistic once you get into muscle deformations. How 
long have you been working at it?

> You are right, even digital image capture & processing would require 
> investment
> in hardware and software.

.. and time. There are so many different approaches and techniques, none of 
which meet everyones requirements, so when you start digging into it it's 
easy to spend a lot of time on it and quite hard to work out what's likely 
to be a success.

> The information I discovered on various ways to
> accomplish this the state of technology was simply mind boggling.  Then I 
> found
> myself researching 6D rotation sensors.

Ah. Now you've caught me out. What the begeebees is a 6D rotation sensor?

Regards,
Chris B.

Post a reply to this message

Chris B escribió:
> Ah. Now you've caught me out. What the begeebees is a 6D rotation sensor?
> 

I think it's the 3 dimensions of movement and the 3 dimensions of 
rotation. x,y,z,pitch,yaw,roll = 6D

But that's just a guess.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Chris B escribió:
> > Ah. Now you've caught me out. What the begeebees is a 6D rotation sensor?
> >
>
> I think it's the 3 dimensions of movement and the 3 dimensions of
> rotation. x,y,z,pitch,yaw,roll = 6D
>
> But that's just a guess.

You guess really well, Nicolas.  Yes, this is how they defined it, 3 dimensions
to characterize linear movement, 3 dimensions to characterize rotational
movement.  For humans rotational sensors are enough if movement is to be
tracked in place, but if you want to allow your subjects the freedom of
movement you allow for linear motion tracking, for robotics all 6D is used in
the way body parts move.

Here is an interesting definition of Inertial Motion Tracking in 6D:
http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA474118

A cool example of what some cretive folks did with this technology
http://www.xsens.com/index.php?mainmenu=products&submenu=human_motion&subsubmenu=Moven
I even looked at their sensor kit to see if I can built the whole thing they
build using POV-RAY, so it will be available..

Here is a very good reference with links on the subject "Instrumented Analysis
of Human Movement"
http://www.brooklyn.liu.edu/bbut04/adamcenter/Instrumented%20Analysis%20Website/index.html

Beware once you start following the links you turn into a little kid in a candy
store.  Oh WOW!  Really, Really.   Electromagnetics are cool.  They are all
cool.

Post a reply to this message

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!

Post a reply to this message

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

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