it could be something as simple as camera and lights not being compatible with
what PovPerson likes, however I was unable to trace it down.  could you see if
it jumps at you?
Thanks,
Meltem
==============================================================================
#include "functions.inc"
#include "shapes.inc"
#include "shapes2.inc"
#include "colors.inc"
#include "woods.inc"
#include "textures.inc"
#include "povperson.inc"

// Copied from textures after commenting out indicated lines
#declare LBlue = rgb <0.0, 0.6, 0.6>;
#declare Vein  = rgb <0.6, 0.0, 0.0>;
//These variables commented out to avoid possibility of name clashes
#declare Blood_Marble_Map =
color_map {
    [0.0 color 0]
    [0.8 color rgb <0.0, 0.6, 0.6>]
    [0.9 color rgb <0.6, 0.0, 0.0>]
    [0.8 color LBlue]
    [0.9 color Vein]
    [1.0 color 0]
}
#declare Blood_Marble =
pigment {
    marble
    color_map { Blood_Marble_Map }
    turbulence 2.3
}
#include "transforms2.inc"


//#declare V_WorldBoundMin = <-1.000000, -1.000000, -1.000000>;
//#declare V_WorldBoundMax = <1.000000, 1.000000, 1.000000>;
/*======================================================================
                        .
    approach1  z   -30  . -15      0      15     30
                          |        |       |
    x               +===|=========================+
    ^               |\|/           ^ lookat     \||
 \  |               |-O-5          |           6-O|
  \1|6              |/|\           .            /||
 --\+----> z        |             \|/             |
    \ |-5           |             -O-4            |
    |\|-angle A=    |             /|\             | 40ft
      + atan(7/5)   |              |              |
                    |              |              |
 The same direction |              |              |
 will intersect far |            camera           |
 wall at            |                             |
                    +=============[O]=============+
 tan(A)= x/35              30ft    x      30ft
                      \|/          ^          \|/
 x=35*tan(atan(7/5))  -O-0         |         1-O-
                      /|\          |          /|\
 x=49                        ------+------> z    [O]
                                   |
                      approach1   \|/                                  }
                      coordinate 3-O-             y axis comes toward me
                      system      /|\
                      lights outside are for approach 1.
======================================================================*/

#macro Lights_And_Camera( N )
   #declare P_light0 = light_source // light0
   {
 <10, 20, -20>
 color rgb <0.800000, 0.800000, 0.800000>
   }

   #declare P_light1 = light_source // light1
   {
 <10, 20, 20>
 color rgb <0.700000, 0.700000, 0.700000>
   }

   #declare P_light2 = light_source // light2
   {
 <40, 20, 0>
 color rgb <1.00, 1.00, 1.00>
   }

   #declare P_light3 = light_source // light3  same level as camera
   {
 <-10, 10, 0>
 color rgb <1.00, 1.00, 1.00>
   }

   #if (N >= 4)
      // add lights 4, 5, and 6 inside depending on how many lights are
requested

   #end

   #declare Lights =
   union{
      object{ P_light0 }
      object{ P_light1 }
      object{ P_light2 }
      object{ P_light3 }
   }

   #declare P_camera0 = camera // camera0
   {
 location   <20.000000,  10.000000, 0>
 direction  <60.000000, 10.000000, 0.000000>// <1.000000, 10.000000, 0.000000>
 sky        <0.000000, 1.000000, 0.000000>
 up         <0.000000, 1.000000, 0.000000>
 right      <1.333333, 0.000000, 0.000000>
 look_at    <60.000000, 10.000000, 0.000000>// <60.000000, 10.000000, 0.000000>
 angle      150.0
   }

Lights
camera{ P_camera0 }
#end // macro  Lights_And_Camera

#macro Build_Stage( Back_Wall_D, Left_Wall_D, Right_Wall_D, Mirror_Reflection,
Floor_Reflection, Wall_Pigment  )
   #local Wood_Floor =
     plane { y, 0
        texture{ T_Wood4 } // pigment{ DMFLightOak }
        //translate <-.5,-.5, 0>
        finish {
           ambient 0.2
           diffuse 0.75
           reflection Floor_Reflection
        }
     };


   // dojo is a 60ft by 40ft room 20ft high.  60ft wall has a mirror
   // Left handed coordinate system is 20 ft before the entarance to the room
   // See plan in camera
   #local Stage =
      union{
         object { Wood_Floor }
         // mirrored back wall   Right across from the camera for approach 1
         plane { <-1, 0, 0>,  Back_Wall_D
            //pigment{ Blood_Marble }
            pigment { color <0.1, 0.1, 0.1> } //DimGray }
               finish {
               ambient 0.2
               diffuse 0.75
               reflection Mirror_Reflection
            }
         }
         // side walls
         plane { <0, 0, 1.0>, Left_Wall_D } // wall on left
         plane { <0, 0, -1.0>, Right_Wall_D  } // wall on right
         pigment{ Wall_Pigment } // Blue_Agate } // White_Marble  Blood_Marble }
Blue_Agate color < 0, 0.8 0.9>  }
      };

   Stage
#end // macro Build_Stage


#declare Back_Wall_D = -60;
#declare Left_Wall_D = -30;
#declare Right_Wall_D = 30;
#declare Mirror_Reflection = 1.0;
#declare Floor_Reflection = 0.15;
#declare Wall_Pigment = Blood_Marble;

#declare Dojo = Build_Stage( Back_Wall_D, Left_Wall_D, Right_Wall_D,
Mirror_Reflection, Floor_Reflection, Wall_Pigment  )
Lights_And_Camera( 3 )


// Use default camera c iff it works
//Action 3rd arg expresssion was smile.

union {
   object
{ppFigure("ppann.inc","ppstyle1.inc","smile","ppstanding.inc","ppoutfit1.inc")
translate <40, 0, -15> }
   Dojo
   }

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47e2dddb3e0fc8b5314b3d800@news.povray.org...
> it could be something as simple as camera and lights not being compatible 
> with
> what PovPerson likes, however I was unable to trace it down.  could you 
> see if
> it jumps at you?
> Thanks,
> Meltem
>
> union {
>   object
> {ppFigure("ppann.inc","ppstyle1.inc","smile","ppstanding.inc","ppoutfit1.inc")
> translate <40, 0, -15> }
>   Dojo
>   }
>

As you mentioned before a file called "smile" doesn't exist, so that needs 
replacing with an expression file like "pplookstraight.inc". Otherwise it 
seems to be mainly a question of scale. The person currently only shows up 
as a dot at 640x480, but if you scale by 15 the figure shows up ok. The 
bottom of the foot is the fixed position, but this character is wearing 
heels, so you probably want to move her up by a short distance to 
compensate.

So:

 
ppFigure("ppann.inc","ppstyle1.inc","pplookstraight.inc","ppstanding.inc","ppoutfit1.inc")
  scale 15
  translate 2*y

Should give you something that works.

Regards,
Chris B.

Post a reply to this message

Oh yes, I had forgotten to mention that in my version of ppFigure I had
commented out where the code was including the nonexistant Expression file.
So, I was not getting a parser warning any longer, it was a scaling problem,
which I could not solve, not knowing what the scaling ranges POVPerson would
like,
thanks for your pointers.

I will try your recommendation and will report back.  Well, if this ann has
high heals, I guess, I might need to try an alternative character.

See, as I learn Tai chi, I want to define poses for my POVPerson to check my
understanding of the form.

Hey, I have high hopes, the Eastern energy based medical philosophy and energy
pathways getting cleared as one moves thru the forms could be animated and
superimposed onto the POVPerson.  I am hoping that I would be able to locate
his/her key energy centers, and insert them into appropriate places within the
code.

Thanks Chris, you are a good pal.

Mel

P.S. I wonder if I could use a freebee high poly count character I found on the
internet and converted to .pov, as a skin, to your more robotic person, to
inherit its movements?  Well, never mind that poly character did not have a
head, only an anatomically acurate body, but then I discovered a paper that
talked about how to create a head only using CSG.  Still too much to do.


"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47e2dddb3e0fc8b5314b3d800@news.povray.org...
> > it could be something as simple as camera and lights not being compatible
> > with
> > what PovPerson likes, however I was unable to trace it down.  could you
> > see if
> > it jumps at you?
> > Thanks,
> > Meltem
> >
> > union {
> >   object
> > {ppFigure("ppann.inc","ppstyle1.inc","smile","ppstanding.inc","ppoutfit1.inc")
> > translate <40, 0, -15> }
> >   Dojo
> >   }
> >
>
> As you mentioned before a file called "smile" doesn't exist, so that needs
> replacing with an expression file like "pplookstraight.inc". Otherwise it
> seems to be mainly a question of scale. The person currently only shows up
> as a dot at 640x480, but if you scale by 15 the figure shows up ok. The
> bottom of the foot is the fixed position, but this character is wearing
> heels, so you probably want to move her up by a short distance to
> compensate.
>
> So:
>
>  
ppFigure("ppann.inc","ppstyle1.inc","pplookstraight.inc","ppstanding.inc","ppoutfit1.inc")
>   scale 15
>   translate 2*y
>
> Should give you something that works.
>
> Regards,
> Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote:
I am able to see all your people.  I decided to put them two at a time in my
scene.

I have 5 people, 6 style, 2 outfits, I mixed and matched them up to see what
combinations I would get.

The main trick in getting them show up was your scaling 15 times, and
translating 2 times up y.  Then I could play with the rest until I saw them the
way I liked.

I am afraid, in one of my combinations, I managed to get a Parse error in
ppshort1.pov at Line: 568.  I saved the section of the message file that
reported the error.  If there is a way to send you a zip file, I would be glad
to email you my scene, ini files and msg dump.

I am hoping the rest of POV_person doc is going to allow me to learn how to
easily change the clothing and appearance of the person I would start
animating.

Might you have any design doc that pictorially outlines the calling sequence. In
a way, it appears to me, ppann, ppalf, ppbill, etc acting like instances of
pphuman0001.  I wonder if ppmale, ppfemale would have made sense, before
instances?   It also appears to me the MODEL of human is a skelatal being made
up of joints and segments.  It appears to me you partioned the space of
humanoid object properties into properties that define
  (a) the character (b) the style, (c) the expression, (d) the "pose", and (e)
the outfit

Which happened to be the parms one passes to ppFigure.

From my OOP days, I hope you will forgive me if I attempt to partition your
design entities along MVC paradidgm lines:
Model is (a) the human. Hopefeully as a tree.  Any skeletal being could be
modeled using this joint-segment approach.  Humanoid is just one instance.

View: (b) all visual attributes of our model some male some female dependent?
Then at the model we could have divided it in male and female?,

Controller: (c) + (d) assuming they both give users means of making the being
laugh, walk, talk, etc. etc.  As I read about character animation, I learn that
facial expression and body expression are very closely related.  Like you are
sad, your face registers it as your shoulders sags, your walk changes, etc.

I would not even thought of including (e) as part of Humanoid object, it is an
external entity.  Yes, there should be an easy way to apply that external
entity on the Humanoid.

> SNIP...

> Thanks Chris, you are a good pal.
>
> Mel
>
> P.S. I wonder if I could use a freebee high poly count character I found on
> the internet and converted to .pov, as a skin, to your more robotic person, to
> inherit its movements?  Well, never mind that poly character did not have a
> head, only an anatomically acurate body, but then I discovered a paper that
> talked about how to create a head only using CSG.  Still too much to do.
>
> SNIP...

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47e6a65b9efbe653314b3d800@news.povray.org...
> "melo" <mel### [at] coxnet> wrote:
> I am able to see all your people.  I decided to put them two at a time in 
> my
> scene.
>...
> I am afraid, in one of my combinations, I managed to get a Parse error in
> ppshort1.pov at Line: 568.

Ironically,line 568 in file 'ppshorts1.inc' is actually an error trap and a 
warning message to indicate that there could be artefacts on the loop on the 
waistband designed to hold a belt. This line doesn't do anything that 
contributes to the resulting object, so if you comment out the line (prefix 
with '//') it should get rid of the parse error.

It looks as though I did away with the variable 'ppSliceCentre' using the 
calculation 'ppWaistBandEndPos+(ppRayDirection*ppTraceLength)' in the 
preceding 'trace' command. So if it's just complaining about the missing 
variable, you could try substituting this calculation into the warning 
statement instead of commenting the statement out if you wished.

Basically the 'trace' command fires out rays to find points on an object 
along the line of the ray. The reason I mention this is that this command is 
what I used in the ppCrowd macros to detect points on a surface. You may 
wish to consider that technique as a way of implementing collision 
detection.

>
> I am hoping the rest of POV_person doc is going to allow me to learn how 
> to
> easily change the clothing and appearance of the person I would start
> animating.
>

The documentation should cover how to adjust the colours, surface normals 
and other attributes of the existing clothing. Each item of clothing is 
driven by a macro and has as many controls as I could think of building in, 
so, for example, the trousers allow you to control the length, whether it 
has seams, how wrinkly the material is etc. and these settings are described 
briefly in '06variables.html'. For example you can use ppHeelHeight to 
reduce the size of the heels on the boots.

> Might you have any design doc that pictorially outlines the calling 
> sequence.

I have a diagram, but it corresponds more closely to a later version which 
followed a significant reorganisation of the code that I never got round to 
publishing. I'm happy to send you a copy so long as it's not going to be 
confusing. Do you have PowerPoint?

> In
> a way, it appears to me, ppann, ppalf, ppbill, etc acting like instances 
> of
> pphuman0001.

Really ppann, ppalf, ppbabs and ppbill, (along with pprod and ppsanta) are 
just settings for predefined characters. The corresponding files contain 
settings that control the character. To create a new character you can just 
copy a file and change the variable settings in your new file.  The file 
'pphuman001.inc' contains the anatomical definition on which all of these 
characters are currently based. However, it would be possible to create an 
alternative anatomy by copying 'pphuman001.inc' and adjusting the body parts 
and joint definitions. I've been meaning to define a quadraped for quite 
some time.

> I wonder if ppmale, ppfemale would have made sense, before
> instances?

The ppGender variable is used to stipulate the gender. This is set at the 
top of each character file.

> It also appears to me the MODEL of human is a skelatal being made
> up of joints and segments.  It appears to me you partioned the space of
> humanoid object properties into properties that define
>  (a) the character (b) the style, (c) the expression, (d) the "pose", and 
> (e)
> the outfit
>
> Which happened to be the parms one passes to ppFigure.

That's true in this version. Later on I realised that this was too 
restrictive because a pose could be made up of several poses (e.g. one for 
the body, one for the right hand and one for the left hand), an outfit could 
be made up of an indeterminate number of items of clothing etc. I therefore 
started working on an alternative syntax that enables chains of properties 
files to be specified. For example, in this later version I can specify a 
walking pose followed by a pose that just adjusts the right arm to hold a 
cup.

>
> From my OOP days, I hope you will forgive me if I attempt to partition 
> your
> design entities along MVC paradidgm lines:

MVC is really an architectural pattern for server design (common in OO 
solutions). It's not particularly easy to map to it in this context but I'll 
try :-).

> Model is (a) the human. Hopefeully as a tree.  Any skeletal being could be
> modeled using this joint-segment approach.  Humanoid is just one instance.

Although conceptually it can usually be visualised as representing a 
tree-like structure, it's actually stored as a set of arrays accessed 
through macros. The main macro is 'ppAddJoint' which is used to 'describe' 
how the different body parts fit together and what constraints are 
applicable to each joint.

Yes, this system can be used to describe any anatomy (even one with closed 
loops that would depart from a tree-like structure). It can even support 
multiple humanoid definitions. For example, I've been looking at the 
MakeHuman anatomy recently. It uses a more sophisticated shoulder 
construction which could potentially be reproduced in POV-Person by creating 
pphuman002.inc.

>
> View: (b) all visual attributes of our model some male some female 
> dependent?
> Then at the model we could have divided it in male and female?,

It would certainly be possible to define separate models for male and 
female. Indeed, Alf and Bob both use the ppm1 definition. Ann uses 'ppf1' 
and Babs uses 'ppf2'. At the moment a lot of the body parts referenced by 
these different figures use the same body part definitions just scaled up or 
down depending upon the gender settings (and other settings). For example, 
one finger nail definition serves for all fingers and toes for both male and 
female figures. Likewise the eyes, teeth, forearm etc. are reused for all 
models.

The 'Style' settings (b) control attributes like hair and makeup, most of 
which are not defined to be gender specific. Although clearly certain 
hairstyles and patterns of makeup are more frequently associated with a 
particular gender, I've intentionally avoided imposing any such constriants 
in the code. The main exception I can think of is with the beard growth 
macro which, by default takes account of gender when deciding whether or not 
to add facial hair.

>
> Controller: (c) + (d) assuming they both give users means of making the 
> being
> laugh, walk, talk, etc. etc.  As I read about character animation, I learn 
> that
> facial expression and body expression are very closely related.  Like you 
> are
> sad, your face registers it as your shoulders sags, your walk changes, 
> etc.
>

There is indeed a lot of commonality between the expression (c) and the pose 
(d) and the reorganisation of code following on from the release of V2A1 
blurs that distinction completely. These later modifications enable multiple 
pose and multiple expression settings to be layered on top of one another in 
any required sequence. This makes it theoretically possible to create a 
'sad' file that reads the current joint settings and adds a little bit more 
slump to the shoulders and that also controls the definition of body parts 
to add a little bit of downturn to the mouth.

> I would not even thought of including (e) as part of Humanoid object, it 
> is an
> external entity.  Yes, there should be an easy way to apply that external
> entity on the Humanoid.

The intention of incorporating an outfit (e) into the definition was to 
enable the shape and form of the outfit to be determined by the anatomy and 
pose. So the size of the hat can be determined by the size of the head and 
the seam of the trousers can follow the line of the leg as it moves.

>>
>> P.S. I wonder if I could use a freebee high poly count character I found 
>> on
>> the internet and converted to .pov, as a skin, to your more robotic 
>> person, to
>> inherit its movements?  Well, never mind that poly character did not have 
>> a
>> head, only an anatomically acurate body, but then I discovered a paper 
>> that
>> talked about how to create a head only using CSG.  Still too much to do.
>>

If you can convert body parts to objects that POV-Ray understands, such as 
mesh objects (PoseRay is usually good for doing such conversions) then the 
existing body parts can quite easily be selectively replaced. You could 
therefore potentially use the existing heads with the headless body you 
found.

If I'd have been able to find an open source figure around when I was 
writing POV-Person I'd have definitely been happier using that.

Regards,
Chris B.

Post a reply to this message

> > SNIP..  Parse error in ppshort1.pov at Line: 568.

Thanks for your work around, I will give this a whirl.  It was ppRod character
that brought me face to face with this error.  Now that I know a way around it,
I would get to see ppRod as well.
>
> Snip.. your  work around recommendations.

> Basically the 'trace' command fires out rays to find points on an object
> along the line of the ray. The reason I mention this is that this command is
> what I used in the ppCrowd macros to detect points on a surface. You may
> wish to consider that technique as a way of implementing collision
> detection.

Cool, pointer.  Let me  print this email, highlight it put it in front of me, I
have a feeling it might get me unstuck in trying to translare my humanoid
forward as he steps forward.

> > I am hoping the rest of POV_person doc is going to allow me to learn how
> > to
> > easily change the clothing and appearance of the person I would start
> > animating.
> >
>
> The documentation should cover how to adjust the colours, surface normals
> and other attributes of the existing clothing. Each item of clothing is
> driven by a macro and has as many controls as I could think of building in,
> so, for example, the trousers allow you to control the length

True, not knowing the length of Characters' legs, or upper legs, down to middle
of calves, etc.. how could one pick up reasonable values for trouser lengths?

> whether it
> has seams, how wrinkly the material is etc. and these settings are described
> briefly in '06variables.html'.

> For example you can use ppHeelHeight to
> reduce the size of the heels on the boots.

While I was looking at the ppboot1.inc, I noticed a global scoped variable for
heel size, but, was afraid shortening heels won't be enough to turn a boot into
a sneaker.  How about Legging, part? this and that.  Being a very visual person
I am, I was hoping for a visual reference of a boot that showed how so mny pp
variable names mapped to different parts of the boot, so, I could begin the
disection.  There comes my limited knowledge of POV-RAY, I guess a POV-RAY
expert could use a torus object to create the ties on the sneakers in a snap.

And I sort felt clueless where to start in creating a form fitting sweartshirt,
better yet, I have a picture of a Chinese fabric that could make the front
panels of the Gi top.  With Chineese writing.  Well, the character I want to
create has to represent the Yin-Yang, energy principals of the culture it was
born in.

I am a figuritive sculptress on my free times, I hope there is sofware that
would allow me to digitally mold my 3D characters.  Modo was mentioned as the
only modern 3D sculpting tool.  In the URL I had mentioned.
>
> > Might you have any design doc that pictorially outlines the calling
> > sequence.
>
> I have a diagram, but it corresponds more closely to a later version which
> followed a significant reorganisation of the code that I never got round to
> publishing. I'm happy to send you a copy so long as it's not going to be
> confusing. Do you have PowerPoint?

Yes, I do.
>
> > In
> > a way, it appears to me, ppann, ppalf, ppbill, etc acting like instances
> > of
> > pphuman0001.
>
> Really ppann, ppalf, ppbabs and ppbill, (along with pprod and ppsanta) are
> just settings for predefined characters. The corresponding files contain
> settings that control the character. To create a new character you can just
> copy a file and change the variable settings in your new file.  The file
> 'pphuman001.inc' contains the anatomical definition on which all of these
> characters are currently based. However, it would be possible to create an
> alternative anatomy by copying 'pphuman001.inc' and adjusting the body parts
> and joint definitions. I've been meaning to define a quadraped for quite
> some time.

Thanks for taking the time and responding.  I was just throwing in OOP
terminology, without making my thinking clear.  ppHuman0001.inc acted like your
Human object's class definition.  It knew about the anatomy of humanoid skeletal
being created.  It has bunch of class variables, and bunch of macros acting as
class methods, such as AddJoint, RotateJoint, MirrorPose, etc.

All of your characters, they defined specific values for the instances of the
human0001 variables, so that particular instance of class Human001 become
distinguisable from other instances of class Human001.

From my perspective, you used a language that offered no official OOP support in
a very sophisticated way as if it had.


>
> > I wonder if ppmale, ppfemale would have made sense, before
> > instances?
>
> The ppGender variable is used to stipulate the gender. This is set at the
> top of each character file.

Thanks, I noticed ppGender being a class attribute (=variable) after I wrote to
you my comments.  There is just so many ways to eat the cake.

I used to have Visio to diagram for my evolving design ideas.  Not anymore, I
want it now.  I wonder why people dread writing desing docs.  It has always
been one creative outlet for me.   Anyhow.  W/o diagramming here is a simple
textual class hierarcy I see

                    Skeletal Being
                   /        |     \
              Humanoid    Robot  Quadraped
              /       \      |     /   \
           Male      Female Rod  Quasy Legsie
           /  | \    /  |  \
         ppm1 |  Randy ppf1 ppf2
         /  | ppsanta   |     |
      Alf  Bob         Ann   Babs

I don't know if this will display correctly, we shall see.


> > It also appears to me the MODEL of human is a skelatal being made
> > up of joints and segments.  It appears to me you partioned the space of
> > humanoid object properties into properties that define
> >  (a) the character (b) the style, (c) the expression, (d) the "pose", and
> > (e)
> > the outfit
> >
> > Which happened to be the parms one passes to ppFigure.
>
> That's true in this version. Later on I realised that this was too
> restrictive because a pose could be made up of several poses (e.g. one for
> the body, one for the right hand and one for the left hand), an outfit could
> be made up of an indeterminate number of items of clothing etc. I therefore
> started working on an alternative syntax that enables chains of properties
> files to be specified. For example, in this later version I can specify a
> walking pose followed by a pose that just adjusts the right arm to hold a
> cup.

Are we talking about different KeyFrames here?  He is walking by holding a cup?
He is walking and grabbing a cup and holding it?   Yes, I can see the need for
reusability in various poses applied to various body parts, and how wonderful
it will be if users can combine them.

The challenge here is, IMHO, to think of users' skill level, power users vs new
comers to POV_RAY and Animation.  Layering, for various skill levels of users
might be a good idea?


> > From my OOP days, I hope you will forgive me if I attempt to partition
> > your
> > design entities along MVC paradidgm lines:
>
> MVC is really an architectural pattern for server design (common in OO
> solutions). It's not particularly easy to map to it in this context but I'll
> try :-).

In my working days, it was used for client-server application development, that
were applications, that had heavy GUI components (=Viever), that did all the
heavy duty computations in the back (=Model) on a powerful server, and that
provided end-users with means to control what got calculated and displayed
(=controller), the client-server communications middleware protocols, etc.

See, I am day-dreaming of a GUI application where end user specifies which body
part go where, that is, records in some simplified textual interface
how to move.  Or better yet, some point and click interface, picks the segments
s/he wants to move, rotation slider to help her move that segment picked.  As
soon as data is collected, the humanoid demonstrates how that move would looks
like.  See, it was always been hard for me to remember the moves as I learned
my katas as I studied martial arts.  I had sketched, and developed some short
hand to help me remember.  Now, with my incrased memory problems visual memory
retention got even harder.  I am sure I am not the only one with Visual memory
problems, and some way to easily record, and be reminded of exercises would be
very welcomed.

Well, I am dreaming again.

>
> > Model is (a) the human. Hopefeully as a tree.  Any skeletal being could be
> > modeled using this joint-segment approach.  Humanoid is just one instance.
>
> Although conceptually it can usually be visualised as representing a
> tree-like structure, it's actually stored as a set of arrays accessed
> through macros. The main macro is 'ppAddJoint' which is used to 'describe'
> how the different body parts fit together and what constraints are
> applicable to each joint.

Yes, I have learned that that was your implementation. while I stop myself for
the language constructs that POV-RAY does not support, I see how single minded
I have gotten.

>
> Yes, this system can be used to describe any anatomy (even one with closed
> loops that would depart from a tree-like structure). It can even support
> multiple humanoid definitions. For example, I've been looking at the
> MakeHuman anatomy recently. It uses a more sophisticated shoulder
> construction which could potentially be reproduced in POV-Person by creating
> pphuman002.inc.

Oh my.  Yet another mind that never rests.

> >
> > View: (b) all visual attributes of our model some male some female
> > dependent?
> > Then at the model we could have divided it in male and female?,
>
> It would certainly be possible to define separate models for male and
> female. Indeed, Alf and Bob both use the ppm1 definition. Ann uses 'ppf1'
> and Babs uses 'ppf2'. At the moment a lot of the body parts referenced by
> these different figures use the same body part definitions just scaled up or
> down depending upon the gender settings (and other settings). For example,
> one finger nail definition serves for all fingers and toes for both male and
> female figures. Likewise the eyes, teeth, forearm etc. are reused for all
> models.
>
> The 'Style' settings (b) control attributes like hair and makeup, most of
> which are not defined to be gender specific. Although clearly certain
> hairstyles and patterns of makeup are more frequently associated with a
> particular gender, I've intentionally avoided imposing any such constriants
> in the code. The main exception I can think of is with the beard growth
> macro which, by default takes account of gender when deciding whether or not
> to add facial hair.
>
> >
> > Controller: (c) + (d) assuming they both give users means of making the
> > being
> > laugh, walk, talk, etc. etc.  As I read about character animation, I learn
> > that
> > facial expression and body expression are very closely related.  Like you
> > are
> > sad, your face registers it as your shoulders sags, your walk changes,
> > etc.
> >
>
> There is indeed a lot of commonality between the expression (c) and the pose
> (d) and the reorganisation of code following on from the release of V2A1
> blurs that distinction completely. These later modifications enable multiple
> pose and multiple expression settings to be layered on top of one another in
> any required sequence. This makes it theoretically possible to create a
> 'sad' file that reads the current joint settings and adds a little bit more
> slump to the shoulders and that also controls the definition of body parts
> to add a little bit of downturn to the mouth.
>
> > I would not even thought of including (e) as part of Humanoid object, it
> > is an
> > external entity.  Yes, there should be an easy way to apply that external
> > entity on the Humanoid.
>
> The intention of incorporating an outfit (e) into the definition was to
> enable the shape and form of the outfit to be determined by the anatomy and
> pose. So the size of the hat can be determined by the size of the head and
> the seam of the trousers can follow the line of the leg as it moves.

Makes sense.
>
> >>
> >> P.S. I wonder if I could use a freebee high poly count character I found
> >> on
> >> the internet and converted to .pov, as a skin, to your more robotic
> >> person, to
> >> inherit its movements?  Well, never mind that poly character did not have
> >> a
> >> head, only an anatomically acurate body, but then I discovered a paper
> >> that
> >> talked about how to create a head only using CSG.  Still too much to do.
> >>
>
> If you can convert body parts to objects that POV-Ray understands, such as
> mesh objects (PoseRay is usually good for doing such conversions) then the
> existing body parts can quite easily be selectively replaced. You could
> therefore potentially use the existing heads with the headless body you
> found.

PoseRay? ah one more thing I donot know about.  I discovered 3dWin5 V5.6 that
could convert a lot of other 3D formats to .pov scenes and back via my Google
searches.  It has done great job converting.  Also searching the web for
freeware 3d poly models, i had lots of good hits.  Some hits from 3Dmax and
Maya generated characters.  I downloaded them, converted them, they were
patiently waiting my sphere+cone Humanoid to finish learning how to move. Well,
s/he failed them.  without doing Inverse Kinematics, and without keeping track
of joint locations, I won't be able to teach him to walk right.  Not to forget
spline interpolations.
>
> If I'd have been able to find an open source figure around when I was
> writing POV-Person I'd have definitely been happier using that.

Well blobman figure is pretty good.  This other figure I had found, seemed just
a bit more like an anatomical book insert.  I  hope I can figure out how to
place my energy meridian interpolations.

Regards,
meltem
>
> Regards,
> Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47e8501f9efbe653314b3d800@news.povray.org...
>> > SNIP..  Parse error in ppshort1.pov at Line: 568.
>
> Thanks for your work around, I will give this a whirl.  It was ppRod 
> character
> that brought me face to face with this error.  Now that I know a way 
> around it,
> I would get to see ppRod as well.

Rod is not too exciting I'm afraid, just a stick man (made of cylindrical 
'rods' and spheres).

>> I have a diagram, but it corresponds more closely to a later version 
>> which
>> followed a significant reorganisation of the code that I never got round 
>> to
>> publishing. I'm happy to send you a copy so long as it's not going to be
>> confusing. Do you have PowerPoint?
>
> Yes, I do.

I've emailed you a copy.

Regards,
Chris B.

Post a reply to this message