Hello, Chris,

I have struggled some more with my animation, then started playing with
POVPerson.  I was going to follow
Quick reference step by step before I play with animation

However I had not managed to go far:

The online documentation recommends

#include "povperson.inc"

object {ppFigure("ann.inc","style1.inc","smile","standing.inc","ppoutfit1.inc")
translate x*5}

to drop add into my pov scene.

I had surely updated my Library_Path to include PPV2 folder. well, as I started
testing the code hoping to see ann,
I realized, I had to add "pp" prefix to all include files.  For a Quick
Reference documentation, it might be a nice touch to keep example follow your
naming convention.

Anyhow, that is not where I stopped, as POV-RAY parser complained I kept adding
"pp" prefixes.  Only to realize,
there was no smile file, ppsmile.pov, or any version that sounded like an
expression, Okay. the document does say None yet provided, but I got a parser
error at line reading

#include ppExpression

in ppFigure macro.   What would you recommend that I do? Passsing a blank file
name does not work, not passing that argument does not work.  I could eliminate
that arg from ppFigure macro for now?  Would that be safe?

As for my simple approach, relying on POV-RAY to figure out the coordinates when
there are rotations involved in a subset of joints in a joint-segment pair CSG
union tree hierarchy.  It worked.  POV-RAY definitely figures out where the
segments go as  result of rotations in select number of nodes.  Having
programmed in C and SAS for a long time, I had assumed that there would be a
way to query POV-RAY to learn the resulting state of joint-segment coordinates.

Thanks to this listserve, and thank you Chris, I learned I was being just too
optimistic. Well, not being the one who can take a no easily, now I wonder, how
difficult could it be to add a custom C level function to POV-RAY.  I remember
seeing urls to source code somewhere, of course I am assuming it is very well
documented, it will be very easy to locate an object handle, given the name of
an object.  Even if I can locate the object handle for the root of my Humanoid
tree.  Would each node contain updated transformed coordinates of that node?

Now that I have started reading more on animation, and thinking about rotations,
I have come across a new branch of geometry that was not in the works while I
went for my doctorate with a minor in ECE. The Engineering Mathematics back
then were about Linear Algebra.  Given 3D vectors, we worked with 3x3 rotation
matrices.  Now I hear about "quaternions", memory and computational
efficiency-wise they are regarded very highly it appears.   Well, even for the
old school I used to know I cannot remember fathom how to apply cummulative
effects of rotational transformation at a node and at its parents.   Not only
there might be rotational transformations at some parent nodes, they are
happening  about the center points of those parents.  As for quaternions I
guess I need to get my hands on a book.
I need a few more life times to pursue this interest and possibilities.

Thanks,
Meltem

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47d49e814b35a0df587ef5e20@news.povray.org...
> Hello, Chris,
>
> I have struggled some more with my animation, then started playing with
> POVPerson.  I was going to follow
> Quick reference step by step before I play with animation
>
> However I had not managed to go far:
>
> The online documentation recommends
>
> #include "povperson.inc"
>
> object 
> {ppFigure("ann.inc","style1.inc","smile","standing.inc","ppoutfit1.inc")
> translate x*5}
>

Ah yes. That is wrong. The example files like 'pp00example05.pov' contain 
the later version of the syntax for the ppFigure macro, where all of the 
parameters have been removed and where you need to 'include' files and call 
macros to set specific options before calling the 'ppFigure' macro. This 
allows defaults to be used and the parameters in the example above are 
roughly the defaults.

The minimum required to add a figure is therefore:

#include "povperson.inc"
ppFigure()

Which adds an 'ann'  figure about 1.6 POV-Ray units tall standing at the 
origin facing towards +Z. The hair looks terrible in this default figure as 
it's cut to about 30 hairs to minimise the performance impact, so you may 
want to try:

#include "povperson.inc"
#include "ppstyle6.inc"
ppAddPoseFile("ppsitting.inc");
object {ppFigure() rotate y*180}
light_source { < 2, 60  ,-30> color rgb<1, 1  , 1  >*0.6 }
light_source { < 0, 24  ,-26> color rgb<1, 1  , 1  >*1.2 }
light_source { <5,  6.5,-10> color rgb<1, 0.5, 0.5>}
camera {
  location <-0.3, 1.08,-2.1>
  look_at  y
}

which gives you a model with hair and a non-default pose.

I do have an updated version of the users guide that I never got round to 
publishing. I'll dig it out and see if it makes sense to replace the one 
that's there.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47d49e814b35a0df587ef5e20@news.povray.org...
> > Hello, Chris,
> >
> > I have struggled some more with my animation, then started playing with
> > POVPerson.  I was going to follow
> > Quick reference step by step before I play with animation
> >
> > However I had not managed to go far:
> >
> > The online documentation recommends
> >
> > #include "povperson.inc"
> >
> > object
> > {ppFigure("ann.inc","style1.inc","smile","standing.inc","ppoutfit1.inc")
> > translate x*5}
> >
>
> Ah yes. That is wrong. The example files like 'pp00example05.pov' contain
> the later version of the syntax for the ppFigure macro, where all of the
> parameters have been removed and where you need to 'include' files and call
> macros to set specific options before calling the 'ppFigure' macro. This
> allows defaults to be used and the parameters in the example above are
> roughly the defaults.
>
> The minimum required to add a figure is therefore:
>
> #include "povperson.inc"
> ppFigure()
>

Thanks Chris.  I will give this a whirl.  In the meantime.  I will still try to
get the stick-figure Humanoid of my 1st try walk.  After all i had already
invested 5-6 months in it. Ickkk!

Who knows, there might be a way to export the current posed state of a skeletal
object to Moray or Bishop from which one can interactively generate coordinates
of next pose?

Always the dreamer.

Cheers,
Meltem

> Which adds an 'ann'  figure about 1.6 POV-Ray units tall standing at the
> origin facing towards +Z. The hair looks terrible in this default figure as
> it's cut to about 30 hairs to minimise the performance impact, so you may
> want to try:
>
> #include "povperson.inc"
> #include "ppstyle6.inc"
> ppAddPoseFile("ppsitting.inc");
> object {ppFigure() rotate y*180}
> light_source { < 2, 60  ,-30> color rgb<1, 1  , 1  >*0.6 }
> light_source { < 0, 24  ,-26> color rgb<1, 1  , 1  >*1.2 }
> light_source { <5,  6.5,-10> color rgb<1, 0.5, 0.5>}
> camera {
>   location <-0.3, 1.08,-2.1>
>   look_at  y
> }
>
> which gives you a model with hair and a non-default pose.
>
> I do have an updated version of the users guide that I never got round to
> publishing. I'll dig it out and see if it makes sense to replace the one
> that's there.
>
> Regards,
> Chris B.

Post a reply to this message

It appears you might have a different/local version of POVPerson.

When I tried your new simple syntax recommendations i.e

 #include "povperson.inc"
 ppFigure()

I got a Parse Error saying :  Expected 5 parameters but only 0 found.

Now a totally unrelated question:

Is it possible to specify movement constraints in POV_RAY.  I had managed to
calculate the coordinates of my Humanoids's forward heal after he strides
forward.  During Cross-Over pose to come in 3 Key-Frames, he moves his back leg
next to his forward leg. This move shifts his weight over forward leg, as his
centroid translates to be directly vertically over his forward heal.

Having said all that, throughout 3 key-Frames, I donot want his forward foot to
move at all as the joint rotations of some other 10-11 joints might be
changing, including the immediate parents of forward_heal_joint & forward_foot
pair's parents, which are forward leg's knee, and hip joints.   They get rotated
to bring Humanoid_Root over the forward heal. They are slightly bent as they are
weight bearing.

I was hoping for some constraint specification that would keep an object
location wise gripped.

Another application of constraint specification could be to ensure that the
floor my exercise room is solid, so as I move my Humanoid around, I would not
be able to dip any part of him/her below the surface.

Well, s/he has been entertaining me emerging through walls, stepping into
floors.   Now just by a new comers luck and mistakes, I had learned how I can
dismantle him/her, segment by segment into a pile.  No, no I am not into
violence, but animating what happens to a being when hit by a car could be
doable, not very realistically, for now.  Given how little I had accomplished
for having worked as long as I had on rudimentary animation, and how much I had
discovered I don't know as of yet.



> "Chris B" <nom### [at] nomailcom> wrote:
> > "melo" <mel### [at] coxnet> wrote in message
> > news:web.47d49e814b35a0df587ef5e20@news.povray.org...
> > > Hello, Chris,
> > >
> > > I have struggled some more with my animation, then started playing with
> > > POVPerson.  I was going to follow
> > > Quick reference step by step before I play with animation
> > >
> > > However I had not managed to go far:
> > >
> > > The online documentation recommends
> > >
> > > #include "povperson.inc"
> > >
> > > object
> > > {ppFigure("ann.inc","style1.inc","smile","standing.inc","ppoutfit1.inc")
> > > translate x*5}
> > >
> >
> > Ah yes. That is wrong. The example files like 'pp00example05.pov' contain
> > the later version of the syntax for the ppFigure macro, where all of the
> > parameters have been removed and where you need to 'include' files and call
> > macros to set specific options before calling the 'ppFigure' macro. This
> > allows defaults to be used and the parameters in the example above are
> > roughly the defaults.
> >
> > The minimum required to add a figure is therefore:
> >
> > #include "povperson.inc"
> > ppFigure()
> >
>
> Thanks Chris.  I will give this a whirl.  In the meantime.  I will still try to
> get the stick-figure Humanoid of my 1st try walk.  After all i had already
> invested 5-6 months in it. Ickkk!
>
> Who knows, there might be a way to export the current posed state of a skeletal
> object to Moray or Bishop from which one can interactively generate coordinates
> of next pose?
>
> Always the dreamer.
>
> Cheers,
> Meltem
>
> > Which adds an 'ann'  figure about 1.6 POV-Ray units tall standing at the
> > origin facing towards +Z. The hair looks terrible in this default figure as
> > it's cut to about 30 hairs to minimise the performance impact, so you may
> > want to try:
> >
> > #include "povperson.inc"
> > #include "ppstyle6.inc"
> > ppAddPoseFile("ppsitting.inc");
> > object {ppFigure() rotate y*180}
> > light_source { < 2, 60  ,-30> color rgb<1, 1  , 1  >*0.6 }
> > light_source { < 0, 24  ,-26> color rgb<1, 1  , 1  >*1.2 }
> > light_source { <5,  6.5,-10> color rgb<1, 0.5, 0.5>}
> > camera {
> >   location <-0.3, 1.08,-2.1>
> >   look_at  y
> > }
> >
> > which gives you a model with hair and a non-default pose.
> >
> > I do have an updated version of the users guide that I never got round to
> > publishing. I'll dig it out and see if it makes sense to replace the one
> > that's there.
> >
> > Regards,
> > Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47d9f8f03d86ff96314b3d800@news.povray.org...
> It appears you might have a different/local version of POVPerson.
>
> When I tried your new simple syntax recommendations i.e
>
> #include "povperson.inc"
> ppFigure()
>
> I got a Parse Error saying :  Expected 5 parameters but only 0 found.

Oh. Well looking on the bright side, that means that at least the 
documentation and the code on the website are more consistent than it 
appeared for a moment. :-)

>
> Now a totally unrelated question:
>
> Is it possible to specify movement constraints in POV_RAY.

It's possible to specify constraints on joint rotations to keep a joint 
within realistic limits.


> I had managed to
> calculate the coordinates of my Humanoids's forward heal after he strides
> forward.  During Cross-Over pose to come in 3 Key-Frames, he moves his 
> back leg
> next to his forward leg. This move shifts his weight over forward leg, as 
> his
> centroid translates to be directly vertically over his forward heal.
>
> Having said all that, throughout 3 key-Frames, I donot want his forward 
> foot to
> move at all as the joint rotations of some other 10-11 joints might be
> changing, including the immediate parents of forward_heal_joint & 
> forward_foot
> pair's parents, which are forward leg's knee, and hip joints.

I think this is where you need to be able to change which body part is 
fixed. In my system I just specify the new fixed body part as being the 
forward foot. From then on, any small spurious rotations affect the back 
foot position rather than shifting the front foot.

> They get rotated
> to bring Humanoid_Root over the forward heal. They are slightly bent as 
> they are
> weight bearing.
>
> I was hoping for some constraint specification that would keep an object
> location wise gripped.

Having a single fixed body part obviously contrains that body part, but when 
you get into fixing multiple body parts (e.g. on stairs where both feet can 
be in contact with the steps and both hands on the handrails for a number of 
animation frames) then it starts to get an order of magnitude more complex. 
This gets you into inverse kinematics which I never got round to 
implementing properly in POV-Person, although I did have some thoughts on 
how I'd go about doing it.

There's no single solution to inverse kinematics as the body parts could 
more or less take any route from one fixed position to another. Also this 
requires some way of dealing with situations where two body parts can no 
longer be joined without violating other constraints. POV-Person was written 
to allow for this to a limited extent in that it calculates a pose by 
scanning the arrays back and forth rather than working from a single fixed 
starting point. If two fixed positions are set and they can't be joined 
it'll work out what it can and just leave a gap between body parts it can no 
longer join. The next logical step would be to track back and 'straighten' 
nearby joints to attempt to bridge the gap.

>
> Another application of constraint specification could be to ensure that 
> the
> floor my exercise room is solid, so as I move my Humanoid around, I would 
> not
> be able to dip any part of him/her below the surface.
>

This brings you into collision detection which is another somewhat complex 
area of study. Once again, I wrote POV-Ray to be able to respond to such 
detection by maintaining body part positions and rotations in arrays that 
can be adjusted iteratively, but never implemented very much in that 
respect. My forays into this area were largely contained in the crowd 
positioning macros, which use the POV-Ray trace command to detect suitable 
positions on a surface for a person to stand on. The macros actually shoot 
out multiple traces for a given position to check the gradient of the 
surface and the proximity of nearby vertical dropoffs and objects.

> Well, s/he has been entertaining me emerging through walls, stepping into
> floors.   Now just by a new comers luck and mistakes, I had learned how I 
> can
> dismantle him/her, segment by segment into a pile.  No, no I am not into
> violence, but animating what happens to a being when hit by a car could be
> doable, not very realistically, for now.  Given how little I had 
> accomplished
> for having worked as long as I had on rudimentary animation, and how much 
> I had
> discovered I don't know as of yet.
>

Well human animation is one of the most difficult things to get right. If it 
were an easy subject then the professional animators who've been struggling 
with it for years would have it nailed by now. There have been a couple of 
recent films where, seen at a distance, you can't really tell which of the 
figures are real or generated, but I've not yet seen anything that's very 
convincing up close.

Our brains are extremely sensitive to even the very slightest inconsistency 
in human appearance, posture and movement. Despite being completely 
surrounded by images and representations of humans, it's very rare that we 
would mistake any of that for a real person for very long. Even when someone 
jumps and says "I though that was a real person" it's usually where they've 
seen it out of the corner of their eye and the deception only lasts a tenth 
of a second or so.

Regards,
Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote:
I had tried the new, easier syntax you recommended
 ppFigure()

I got a Parser error, complaining about expecting 5 parameters, and only finding
0.

Your working version sounds different than the downloadable version of PP.

Thanks,

Meltem

Is there any way to define transformation constraints in POV-RAY?  I need to
keep my skeletal objects forward feet locked in place whereever it lands, as he
brings his back leg forward into his cross-over pose ready to take his next
stride.

Another place where I might need transformation constraints is obstacle
avoidance, or not allowing him stepping into or thru hard objects.  Now he
steps into the floor or walks right thru the walls, he is very entertaining, as
he is.

Thanks again.   Of course, none of the above had been doable, since I left it to
POV-RAY to come up with coordinates of bone-segments & joints in my moved
(=posed) skeleton.

How I wish POV-RAY had allowed some kind of structure and linked list
definitions, how I wish it had known and informed its users about states.
It is obviously doing a whole bunch of marvelous, mathematically sound
computations, to be able to render complex CSG objects transformed in any
conciveable ways.

Well, this is the second time I am attempting to respond to this posting, the
first one has disappeared on me.  If they both appear, please accept my
appologies.

Cheers,
Meltem



> "Chris B" <nom### [at] nomailcom> wrote:
> > "melo" <mel### [at] coxnet> wrote in message
> > news:web.47d49e814b35a0df587ef5e20@news.povray.org...
> > > Hello, Chris,
> > >
> > > I have struggled some more with my animation, then started playing with
> > > POVPerson.  I was going to follow
> > > Quick reference step by step before I play with animation
> > >
> > > However I had not managed to go far:
> > >
> > > The online documentation recommends
> > >
> > > #include "povperson.inc"
> > >
> > > object
> > > {ppFigure("ann.inc","style1.inc","smile","standing.inc","ppoutfit1.inc")
> > > translate x*5}
> > >
> >
> > Ah yes. That is wrong. The example files like 'pp00example05.pov' contain
> > the later version of the syntax for the ppFigure macro, where all of the
> > parameters have been removed and where you need to 'include' files and call
> > macros to set specific options before calling the 'ppFigure' macro. This
> > allows defaults to be used and the parameters in the example above are
> > roughly the defaults.
> >
> > The minimum required to add a figure is therefore:
> >
> > #include "povperson.inc"
> > ppFigure()
> >
>
> Thanks Chris.  I will give this a whirl.  In the meantime.  I will still try to
> get the stick-figure Humanoid of my 1st try walk.  After all i had already
> invested 5-6 months in it. Ickkk!
>
> Who knows, there might be a way to export the current posed state of a skeletal
> object to Moray or Bishop from which one can interactively generate coordinates
> of next pose?
>
> Always the dreamer.
>
> Cheers,
> Meltem
>
> > Which adds an 'ann'  figure about 1.6 POV-Ray units tall standing at the
> > origin facing towards +Z. The hair looks terrible in this default figure as
> > it's cut to about 30 hairs to minimise the performance impact, so you may
> > want to try:
> >
> > #include "povperson.inc"
> > #include "ppstyle6.inc"
> > ppAddPoseFile("ppsitting.inc");
> > object {ppFigure() rotate y*180}
> > light_source { < 2, 60  ,-30> color rgb<1, 1  , 1  >*0.6 }
> > light_source { < 0, 24  ,-26> color rgb<1, 1  , 1  >*1.2 }
> > light_source { <5,  6.5,-10> color rgb<1, 0.5, 0.5>}
> > camera {
> >   location <-0.3, 1.08,-2.1>
> >   look_at  y
> > }
> >
> > which gives you a model with hair and a non-default pose.
> >
> > I do have an updated version of the users guide that I never got round to
> > publishing. I'll dig it out and see if it makes sense to replace the one
> > that's there.
> >
> > Regards,
> > Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47db0e5f3d86ff96314b3d800@news.povray.org...
>
> How I wish POV-RAY had allowed some kind of structure and linked list
> definitions, how I wish it had known and informed its users about states.
>

I suspect that it would be difficult to meaningfully interpret the internal 
structures and the rotational and positional information used internally by 
POV-Ray. You'd need to know the starting point that this information is 
relative to, and this may not be easy to determine or what you may expect in 
all situations.

What POV-Ray does provide is a series of macros that enable you to apply 
transformations to vectors. You can therefore say, "if this is my starting 
point, where would it end up when I apply these transformations?". IMO this 
is more productive and easier to use.

> Well, this is the second time I am attempting to respond to this posting, 
> the
> first one has disappeared on me.  If they both appear, please accept my
> appologies.
>

Does that mean you can't see my response to your first attempt either?
I find that, if stuff doesn't appear, it's helpful to look at the same 
newsgroup on http://news.povray.org as a reference, but it still doesn't 
guarantee that everyone can see the same things.

> Cheers,
> Meltem

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47db0e5f3d86ff96314b3d800@news.povray.org...
> >
> > How I wish POV-RAY had allowed some kind of structure and linked list
> > definitions, how I wish it had known and informed its users about states.
> >
>
> I suspect that it would be difficult to meaningfully interpret the internal
> structures and the rotational and positional information used internally by
> POV-Ray. You'd need to know the starting point that this information is
> relative to, and this may not be easy to determine or what you may expect in
> all situations.
>
> What POV-Ray does provide is a series of macros that enable you to apply
> transformations to vectors. You can therefore say, "if this is my starting
> point, where would it end up when I apply these transformations?". IMO this
> is more productive and easier to use.

Your statements highlighted a lot more that I had made assumptions on.  Meaning,
I had assumed that, the documentations on POV-RAY would have enabled me to
interpret the internal structures.  Yet another assumption I had made is that,
those internal structures are state aware.  Meaning, during animation, if I am
in "frame_number=x"  the internal structures would correspond to all the
code parsed, executed for that particular frame number.

As I had mentioned before, in my crude, 1st skeletal animation attempt, I had
povided joint rotation vectors with respect to a global coordinate system, not
in relation to parent joint-segment pairs.   And I had utilized
             Rotate_Around_Trans(Rotation, Point)
macro.

With your help so far, I had managed to get him move from Key-Frame(=Pose) to
Key-Frame(=Pose).  I give him 5 frames to move from one Key-Frame to next.

Well now that I put him in a room, I could see the short-comings of my approach.

Obviously remembering his previous Pose when the new Pose began was not good
enough.  In addition to the Pose, I had to remember where to place him.  Not
into the wall, not below the floor.

Not wanting to give up, the very first pose is when he takes his very first
stride, I used

  vtransform  and  VProject_Plane macros

to calculate where his forward heal and toes would ended up.  By placing
transparent circles I verified that my calculations were correct. Much to my
surprise, they were.

Well, from then on it takes him 4 poses, to bring his back leg into cross over
position.  Throughout all those poses, i.e frame_numbers 6..25, I tried to use

   #if ( !VZero( Forward_Heal_Coord ) )
       object{ PosedHumanoid }
       Align_Trans( PosedHumanoid, -y, Reference_Point )
       Align_Trans( PosedHumanoid,  z, Forward_Foot_Coord )
   #else
       object{ PosedHumanoid }
       Align_Trans( PosedHumanoid, -y, Reference_Point )
       Align_Trans( PosedHumanoid, -z, Reference_Point )
   #end

The first part of the if condition was meant to align him with his forward foot
always - with an assumption that his forward toes would be his right most point
(not a good assumption, I know, just to see him walking I was willing to live
with this assumption for now.

Reference_Point was a globally declared vector attempted to prevent him from
dropping below floor or moving into walls.

I was quite disappointed this last attempt did not save the day.

Given, I had not had much luck with PovPerson until now either. And I am
convinced, my simple approach will not save the day.  I do need to keep track
of location as well as rotation of joints of my skeletal tree.

After realizing that I started searching internet again.  Much to my shock I
discovered a freeware character animation software:  Blender, which provided
both build in forward and inverse kinematics.  It was rated next to 3dMax &
Maya.

Has anyone had much/any experience with it.  Am I daydreaming?

Thanks
Meltem

>
> > Well, this is the second time I am attempting to respond to this posting,
> > the
> > first one has disappeared on me.  If they both appear, please accept my
> > appologies.
> >
>
> Does that mean you can't see my response to your first attempt either?
> I find that, if stuff doesn't appear, it's helpful to look at the same
> newsgroup on http://news.povray.org as a reference, but it still doesn't
> guarantee that everyone can see the same things.

NO, No, I was able to see your response.  False alarm.  I was just being
impatient.

Thanks for all your help
Meltem

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47e2cb703d86ff96314b3d800@news.povray.org...
>
> Well now that I put him in a room, I could see the short-comings of my 
> approach.
>

You may find that you can use the 'min_extent' and 'max_extent' functions 
may help you avoid collisions between your object and floors/walls/ceilings 
(or at least detect them).

>
> Much to my shock I
> discovered a freeware character animation software:  Blender, which 
> provided
> both build in forward and inverse kinematics.  It was rated next to 3dMax 
> &
> Maya.
>
> Has anyone had much/any experience with it.  Am I daydreaming?
>

Blender is an open source modeller, (see http://www.blender.org/). It seems 
to have come a long way since I last looked at it many years ago and their 
site indicates that it incorporates some character animation features. The 
'features' section on the site certainly talks of skeleton rigging and 
animation with forward/inverse kinematics, although it's difficult to judge 
where it's limitations may lie from the brief description that I just read.

Their 'scripts' section at 
http://www.blender.org/download/python-scripts/wizards/ talks about 
MakeHuman Python scripts, but I couldn't get the links there to work. I 
don't know if those scripts are anything to do with the sourceforge 
MakeHuman project at (http://sourceforge.net/projects/makehuman/).  There's 
also talk of 'Walk.O.matic ' scripts and 'Blender People' scripts that seem 
to be separate initiatives.

Their site does have an animation forum which looks to be pretty active, so 
you would probably be able to get some good feedback there on how easy it 
would be to achieve what you want to do. Also you may well get a wider 
audience on this newsgroup by starting a separate thread for this question 
rather than tagging it to the bottom of this thread. It might be only you 
and me still reading this one :-).

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47e2cb703d86ff96314b3d800@news.povray.org...
> >
> > Well now that I put him in a room, I could see the short-comings of my
> > approach.
> >
>
> You may find that you can use the 'min_extent' and 'max_extent' functions
> may help you avoid collisions between your object and floors/walls/ceilings
> (or at least detect them).

Yes, I had tried those a while back, and reported by failures in getting them
work the way I hoped.  See I attempted to draw a box around my Humanoid after
getting min and max extends to see visually what how those macros behaved.
Much to my disappointment, the boxes seemed to extend outside screen.  Well I
played with camera coordinates to see if by accident I had put any part of him
way out of limits.  I could not find anything it down.

Besides, even I was successful getting them working, I was not liking using
them, what if s/he was carrying something in her/his hand that extended beyond
his/her forward foot.   Nonetheless, the macros I found, and keeping rotations
in arrays, allowed me calculate the coordinates of his forward heal/foot
correctly.   Nothing too sophisticated.  Knowing the exact placement of his her
forward foot, and for the poses I coded seeing no other part of his/her was
further ahead than her forward foot should have made
    Align_Trans(Object, Axis, Pt).
macro work, it had not.  Well, I am clueless why the heck not?

It appears I could use a language I am comfortable with to generate POV-RAY
scene code using the Pose files, skeletal hierarchy definition files, to
generate the coordinates of all of the joints, then use POV-RAY to render it.

Well, I was finding myself needing a structured language that could allow me to
create a tree to represent the skeletal hierarcy, where each node would be a
joint-segment pair.   whenever a pose file specify a rotation for a node, that
rotation would need to be applied to all the children of that node.   Well this
is for forward kinematics part of the movement.

It blows my mind that you were able to accomplish not only forward, but some and
absolutely relevant inverse kinematics by traversing an array of joints up and
down and resolving all unresolved movement and geometry constraints.  Assuming
I interpreted your approach correctly.

I have accumulated lots of bioengineering and anthropological references that
give average volume/weight percentages of every segment in an average
male/female human body.   As well as biological joint rotation constraints.
All of those could be properties of tree nodes.

I have hopes, not limited energy to carry thru with all my hopes & dreams.   I
wanted an animated humanoid that would be subject to  the laws of mechanics and
dynamics as s/he moves to stay in balance.

I wonder how I managed to get my doctorate without Google?  Now, with the touch
of my fingertips I can do so much through research than before. Which has its
benefits and its down site, I get lost in the information highway, when I
realiaze how little I know, and how much more I want to know.

Well as I started teaching myself skeletal and character animation, and reading
up on forward and inverse kinematics, I realized the mathematics needed to make
my virtual being move was the the same math used in robotics.   Now, I want a
take robotic classes, I want to  have a robot that will be syncronized with my
virtual humanoid, in hopes they can facilitate robotic rehabilitation device
development and testing.

Yeah, yeah.  very doable for someone who is a recovering perfectionist, and a
recovering TBI survivor.

Thanks for your note, I will create a separe line of inquiry on Blender?
Instead of investing my years into resolving problems already solved -see that
would be the only way for me to really understand them and learn them- I should
focus on the areas I want to apply them to.

Cheers,
Mel


>
> >
> > Much to my shock I
> > discovered a freeware character animation software:  Blender, which
> > provided
> > both build in forward and inverse kinematics.  It was rated next to 3dMax
> > &
> > Maya.
> >
> > Has anyone had much/any experience with it.  Am I daydreaming?
> >
>
> Blender is an open source modeller, (see http://www.blender.org/). It seems
> to have come a long way since I last looked at it many years ago and their
> site indicates that it incorporates some character animation features. The
> 'features' section on the site certainly talks of skeleton rigging and
> animation with forward/inverse kinematics, although it's difficult to judge
> where it's limitations may lie from the brief description that I just read.
>
> Their 'scripts' section at
> http://www.blender.org/download/python-scripts/wizards/ talks about
> MakeHuman Python scripts, but I couldn't get the links there to work. I
> don't know if those scripts are anything to do with the sourceforge
> MakeHuman project at (http://sourceforge.net/projects/makehuman/).  There's
> also talk of 'Walk.O.matic ' scripts and 'Blender People' scripts that seem
> to be separate initiatives.
>
> Their site does have an animation forum which looks to be pretty active, so
> you would probably be able to get some good feedback there on how easy it
> would be to achieve what you want to do. Also you may well get a wider
> audience on this newsgroup by starting a separate thread for this question
> rather than tagging it to the bottom of this thread. It might be only you
> and me still reading this one :-).
>
> Regards,
> Chris B.

Post a reply to this message