"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