Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #1419 > unrolled thread

How to make a stickman

Back to article view | Back to comp.lang.postscript

Contents

  How to make a stickman Cecil Westerhof <Cecil@decebal.nl> - 2013-07-12 19:03 +0200
    Re: How to make a stickman ashley willis <"s/^.*/valid/&&print' address'"@hostscript.org> - 2013-07-13 04:28 +0000
      Re: How to make a stickman luser- -droog <mijoryx@yahoo.com> - 2013-07-12 22:07 -0700
        Re: How to make a stickman Cecil Westerhof <Cecil@decebal.nl> - 2013-07-13 15:46 +0200
          Re: How to make a stickman luser- -droog <mijoryx@yahoo.com> - 2013-07-13 16:55 -0700
            Re: How to make a stickman Cecil Westerhof <Cecil@decebal.nl> - 2013-07-14 14:59 +0200
              Re: How to make a stickman ashley willis <"s/^.*/valid/&&print' address'"@hostscript.org> - 2013-07-14 18:37 +0000
              Re: How to make a stickman luser- -droog <mijoryx@yahoo.com> - 2013-07-15 01:06 -0700
                Re: How to make a stickman Cecil Westerhof <Cecil@decebal.nl> - 2013-07-15 12:34 +0200
                  Procedure argument comments   (was Re: How to make a stickman) luser- -droog <mijoryx@yahoo.com> - 2013-07-16 09:31 -0700
          Re: How to make a stickman luser- -droog <mijoryx@yahoo.com> - 2013-07-13 18:22 -0700
            Re: How to make a stickman Cecil Westerhof <Cecil@decebal.nl> - 2013-07-14 15:09 +0200

#1419 — How to make a stickman

It will not be very difficult to make a stickman, but I would suppose
that people already made functions for this. So where could I find
functions to draw different style stickmans?

Resources to draw other type of figures are welcome also of-course.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#1420

On Fri, 12 Jul 2013, Cecil Westerhof wrote:

> It will not be very difficult to make a stickman, but I would suppose
> that people already made functions for this. So where could I find
> functions to draw different style stickmans?
>
> Resources to draw other type of figures are welcome also of-course.

i have something i did a few years ago in 3D. it's designed for second 
life avatars (i was trying to get inverse kinematics in there, and i had a 
formula for 2D, but couldn't figure out the 3D for some reason).

-ashley

[toc] | [prev] | [next] | [standalone]

#1421

On Friday, July 12, 2013 11:28:15 PM UTC-5, ashley willis wrote:
> On Fri, 12 Jul 2013, Cecil Westerhof wrote:
> 
> 
> > It will not be very difficult to make a stickman, but I would suppose
> > that people already made functions for this. So where could I find
> > functions to draw different style stickmans?
> >
> > Resources to draw other type of figures are welcome also of-course.
> 
> 
> i have something i did a few years ago in 3D. it's designed for second 
> life avatars (i was trying to get inverse kinematics in there, and i had a 
> formula for 2D, but couldn't figure out the 3D for some reason).
> 

There's a chapter in Jim Blinn's A Trip Down the Graphics Pipeline about "Blobby Man" that focuses on the hierarchical transformations needed for moving figures.

[toc] | [prev] | [next] | [standalone]

#1422

Op zaterdag 13 jul 2013 07:07 CEST schreef luser:

> On Friday, July 12, 2013 11:28:15 PM UTC-5, ashley willis wrote:
>> On Fri, 12 Jul 2013, Cecil Westerhof wrote:
>>
>>
>>> It will not be very difficult to make a stickman, but I would
>>> suppose that people already made functions for this. So where
>>> could I find functions to draw different style stickmans?
>>>
>>> Resources to draw other type of figures are welcome also
>>> of-course.
>>
>>
>> i have something i did a few years ago in 3D. it's designed for
>> second life avatars (i was trying to get inverse kinematics in
>> there, and i had a formula for 2D, but couldn't figure out the 3D
>> for some reason).
>>
>
> There's a chapter in Jim Blinn's A Trip Down the Graphics Pipeline
> about "Blobby Man" that focuses on the hierarchical transformations
> needed for moving figures.

That is a ‘little’ above my current state of knowledge. But I think it
will be an interesting read.


I have made an initial routine to draw a stick man:
    % Places a stickman at x, y. Two units wide, seven units high.
    /stickman { % x y unit
        3 dict begin
            /unit exch def
            /y    exch def
            /x    exch def
    
            gsave
            newpath
            % start top center
            x unit add  y unit 7 mul add  translate
            % draw head
            0  unit neg  unit  0  360  arc closepath
            % draw body
            0  unit 2 mul neg  moveto
            0  unit 6 mul neg  lineto
            % draw arms
            unit neg  unit 3 mul neg  moveto
            0         unit 4 mul neg  lineto
            unit      unit 3 mul neg  lineto
            % draw legs
            unit neg  unit 7 mul neg  moveto
            0         unit 6 mul neg  lineto
            unit      unit 7 mul neg  lineto
    
            stroke
            grestore
        end
    } def

I would not mind feedback on it. :-D For example: are the ratios
correct?


By the way, I want to expand this function, so that I can draw a range
of stick mans:
    - the default one
    - happy one
    - angry one
    - sad one
    - kneeling
    - …

What is the best way to do this? I mean graphically, but also
programmatically: how to write it so it is easy to use.


I used it to make:
    https://www.facebook.com/photo.php?fbid=593050714080840

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1426

On Saturday, July 13, 2013 8:46:37 AM UTC-5, Cecil Westerhof wrote:
> Op zaterdag 13 jul 2013 07:07 CEST schreef luser:
> > On Friday, July 12, 2013 11:28:15 PM UTC-5, ashley willis wrote:
> >> On Fri, 12 Jul 2013, Cecil Westerhof wrote:
> >>
> >>> It will not be very difficult to make a stickman, but I would
> >>> suppose that people already made functions for this. So where
> >>> could I find functions to draw different style stickmans?
> >>>
> >>> Resources to draw other type of figures are welcome also
> >>> of-course.
> >>
> >> i have something i did a few years ago in 3D. it's designed for
> >> second life avatars (i was trying to get inverse kinematics in
> >> there, and i had a formula for 2D, but couldn't figure out the 3D
> >> for some reason).
> >
> > There's a chapter in Jim Blinn's A Trip Down the Graphics Pipeline
> > about "Blobby Man" that focuses on the hierarchical transformations
> > needed for moving figures.

> That is a ‘little’ above my current state of knowledge. But I think it
> will be an interesting read.

I kind of thought so. That comment was more for Ashley. :D

> [snip]

> I would not mind feedback on it. :-D For example: are the ratios
> correct?
> By the way, I want to expand this function, so that I can draw a range
> of stick mans:
>     - the default one
>     - happy one
>     - angry one
>     - sad one
>     - kneeling
>     - …
> What is the best way to do this? I mean graphically, but also
> programmatically: how to write it so it is easy to use.
> I used it to make:
>     https://www.facebook.com/photo.php?fbid=593050714080840

I've only looked at the "programmatically" part, so far.
For the ratios, it's probably best to steal from Da Vinci's Vitruvian Man.

I've re-written your function to be more "Reid"-style (cf. the green book):
no dictionary, no variables, re-order the parameters so they're used
straight off the stack.


%!

% unit x y  fig  - 
/fig {
    gsave translate % unit
    dup dup scale   % unit
    1 exch div setlinewidth

    0 0 moveto
    1 1 lineto %left leg
    2 0 lineto %right leg

    1 1 moveto
    1 2 lineto %body
    currentpoint
        0 1.5 lineto %left arm
    moveto
    currentpoint
        2 1.5 lineto %right arm
    moveto
    0 .2 rlineto %neck

    currentpoint .5 add
    .5 -90 270 arc %head

    stroke
    grestore
} def

50 100 100 fig


For the variations of posture, Blobby-Man should really help.
But you can simplify it a lot. Basically, instead of positions
for the arms and legs, use Polar Coordinates.

    (x,y) = (r*cos(t), r*sin(t))

Then you can modify the angle (t) independently.

[toc] | [prev] | [next] | [standalone]

#1431

Op zondag 14 jul 2013 01:55 CEST schreef luser:

[snip]

>> I would not mind feedback on it. :-D For example: are the ratios
>> correct? By the way, I want to expand this function, so that I can
>> draw a range of stick mans: - the default one - happy one - angry
>> one - sad one - kneeling - … What is the best way to do this? I
>> mean graphically, but also programmatically: how to write it so it
>> is easy to use. I used it to make:
>> https://www.facebook.com/photo.php?fbid=593050714080840
>
> I've only looked at the "programmatically" part, so far. For the
> ratios, it's probably best to steal from Da Vinci's Vitruvian Man.

It was not to bad. Da Vinci says a man is 8 times his head, I had 7
times. ;-)


> I've re-written your function to be more "Reid"-style (cf. the green
> book): no dictionary, no variables, re-order the parameters so
> they're used straight off the stack.

That is frowned upon? I will read the book. But first I should read
the blue and red book I understood. Below I have a modified version
from the logo out of the green book.

What certainly is a lot better, is the way before and after stack is
done. I will do that in the future also.


> %!
>
> % unit x y  fig  - 
> /fig {
> gsave translate % unit
> dup dup scale   % unit
> 1 exch div setlinewidth
>
> 0 0 moveto
> 1 1 lineto %left leg
> 2 0 lineto %right leg
>
> 1 1 moveto
> 1 2 lineto %body
> currentpoint
> 0 1.5 lineto %left arm
> moveto
> currentpoint
> 2 1.5 lineto %right arm
> moveto
> 0 .2 rlineto %neck
>
> currentpoint .5 add
> .5 -90 270 arc %head
>
> stroke
> grestore
> } def
>
> 50 100 100 fig

Does not the same. The legs look to long for me, but your neck is a
lot better as mine. My arms and legs should also be longer. I'll
tinker with it.


> For the variations of posture, Blobby-Man should really help.
> But you can simplify it a lot. Basically, instead of positions
> for the arms and legs, use Polar Coordinates.
>
> (x,y) = (r*cos(t), r*sin(t))
>
> Then you can modify the angle (t) independently.

That is a very good idea. Thanks.


My modified logo function:
    % hasBorder x y  logoCW  -
    /logoCW {
        gsave
        moveto
        {
            currentpoint 87 56 rectstroke
        } if
        currentpoint
        /Times-Roman findfont
        48 scalefont setfont
        4 18 rmoveto
        (C) show
        -8.5 -14.5 rmoveto
        (W) show
        moveto
        4 8 rmoveto
        /Helvetica findfont 11 scalefont setfont
        (Cecil) show
        8 30 rmoveto
        (westerhof) show
        grestore
    } bind def


    false  100  100  logoCW
    true   200  100  logoCW

There where a few bugs in the green book version:
- The logo was not placed at current point
  (I prefer to give the coordinates as parameters.)
- It did not leave the graphical state untouched

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1436

On Sun, 14 Jul 2013, Cecil Westerhof wrote:

> Op zondag 14 jul 2013 01:55 CEST schreef luser:
>
<snip>
>> I've re-written your function to be more "Reid"-style (cf. the green
>> book): no dictionary, no variables, re-order the parameters so
>> they're used straight off the stack.
>
> That is frowned upon? I will read the book. But first I should read
> the blue and red book I understood. Below I have a modified version
> from the logo out of the green book.

defining things is certainly easier than doing pure stack manipulation, 
both when developing and maintaining. various library procedures i write 
that are stable (math functions, for example), i will often write the easy 
way, and then convert to pure stack based for performance reasons. or if 
the library procedure is simple enough, i will use pure stack from the 
beginning. but if performance is not a concern, just write it however you 
want.

it is certainly good practice (as in learning-practice) to do things 
purely on the stack, though, so that you can more easily read other 
postscript code, or even debug that damn CS3 file that seems to be 
corrupted and OS X Preview won't open it and gs throws an error.

-ashley

[toc] | [prev] | [next] | [standalone]

#1439

On Sunday, July 14, 2013 7:59:56 AM UTC-5, Cecil Westerhof wrote:
> Op zondag 14 jul 2013 01:55 CEST schreef luser:
> 
> >> I would not mind feedback on it. :-D For example: are the ratios
> >> correct? By the way, I want to expand this function, so that I can
> >> draw a range of stick mans: - the default one - happy one - angry
> >> one - sad one - kneeling - … What is the best way to do this? I
> >> mean graphically, but also programmatically: how to write it so it
> >> is easy to use. I used it to make:
> 
> >> https://www.facebook.com/photo.php?fbid=593050714080840

> > I've only looked at the "programmatically" part, so far. For the
> > ratios, it's probably best to steal from Da Vinci's Vitruvian Man.
> 
> 
> It was not to bad. Da Vinci says a man is 8 times his head, I had 7
> times. ;-)
> 

Congrats!

> > I've re-written your function to be more "Reid"-style (cf. the green
> > book): no dictionary, no variables, re-order the parameters so
> > they're used straight off the stack.
> 
> 
> 
> That is frowned upon? I will read the book. But first I should read
> the blue and red book I understood. Below I have a modified version
> from the logo out of the green book.

Actually, I'd recommend going straight to the green book after you get
through the tutorial part of the blue book. Just use the red book as
reference to look up details. The red book is not really written to 
be read straight-through.

> 
> What certainly is a lot better, is the way before and after stack is
> done. I will do that in the future also.
> 

Eliminating variables in favor of stack manipulation is sometimes good,
sometimes not-so-good. I've written a function for determinants that 
was really hard to read and understand until it was re-written with
variables.

http://stackoverflow.com/posts/14784818/revisions
(choose the 'side-by-side' view)

> 
> 
> > %!

> > [snip]

> 
> Does not the same. The legs look to long for me, but your neck is a
> 
> lot better as mine. My arms and legs should also be longer. I'll
> 
> tinker with it.
> 

Yeah, I apologize. I didn't try to make it the same. I just made a 
doodle on graph paper and counted the boxes.

> 
> 
> > For the variations of posture, Blobby-Man should really help.
> > But you can simplify it a lot. Basically, instead of positions
> > for the arms and legs, use Polar Coordinates.
> 
> 
> > (x,y) = (r*cos(t), r*sin(t))
> 
> 
> > Then you can modify the angle (t) independently.
> 
> 
> 
> That is a very good idea. Thanks.
> 

You're welcome. 

> 
> My modified logo function:
> 
>     % hasBorder x y  logoCW  -
> 
>     /logoCW {
>         gsave
>         moveto
>         {
>             currentpoint 87 56 rectstroke
>         } if
> 
>         currentpoint
>         /Times-Roman findfont
>         48 scalefont setfont
>         4 18 rmoveto
>         (C) show
> 
>         -8.5 -14.5 rmoveto
>         (W) show
> 
>         moveto
>         4 8 rmoveto
>         /Helvetica findfont 11 scalefont setfont
>         (Cecil) show
> 
>         8 30 rmoveto
>         (westerhof) show
> 
>         grestore
>     } bind def
> 
> 
> 
>     false  100  100  logoCW
>     true   200  100  logoCW
> 
> 
> 
> There where a few bugs in the green book version:
> 
> - The logo was not placed at current point
>   (I prefer to give the coordinates as parameters.)
> - It did not leave the graphical state untouched
> 

That's something I still have trouble with. Keeping
the graphics state safe. I rarely use `newpath`, I think
because I often use lots of little procedures to build-up
a path. And then what if you want to `fill` instead of `stroke`?

[toc] | [prev] | [next] | [standalone]

#1440

Op maandag 15 jul 2013 10:06 CEST schreef luser:

>> That is frowned upon? I will read the book. But first I should read
>> the blue and red book I understood. Below I have a modified version
>> from the logo out of the green book.
>
> Actually, I'd recommend going straight to the green book after you
> get through the tutorial part of the blue book. Just use the red
> book as reference to look up details. The red book is not really
> written to be read straight-through.

That is exactly what I thought. You prevented a question from me. ;-)
The blue book did not tell me much news until now, so I expect to
start soon with the green book. :-D


>> What certainly is a lot better, is the way before and after stack
>> is done. I will do that in the future also.
>>
>
> Eliminating variables in favor of stack manipulation is sometimes
> good, sometimes not-so-good. I've written a function for
> determinants that was really hard to read and understand until it
> was re-written with variables.

I was not clear: what I meant, I wrote:
    % Places a stickman at x, y. Two units wide, seven units high.
    /stickman { % x y unit

and it is better to write:
    % x y unit  stickman  -
    % Places a stickman at x, y. Two units wide, seven units high.
    /stickman {

What would be better, first stack effect and then description (if
any), or the other-way around?

I all-ready peeked in the green book, what I also find a good idea:
    { % ifelse
        .
        .
        .
    } { % else
        .
        .
        .
    } if


> http://stackoverflow.com/posts/14784818/revisions
> (choose the 'side-by-side' view)

I'll examine it.


>> Does not the same. The legs look to long for me, but your neck is a
>>
>> lot better as mine. My arms and legs should also be longer. I'll
>>
>> tinker with it.
>>
>
> Yeah, I apologize. I didn't try to make it the same. I just made a 
> doodle on graph paper and counted the boxes.

No problem. And it made clear that my version was not good anyway.


>> There where a few bugs in the green book version:
>>
>> - The logo was not placed at current point
>> (I prefer to give the coordinates as parameters.)
>> - It did not leave the graphical state untouched
>>
>
> That's something I still have trouble with. Keeping
> the graphics state safe. I rarely use `newpath`, I think
> because I often use lots of little procedures to build-up
> a path. And then what if you want to `fill` instead of `stroke`?

Well, I also have functions where I sometimes want to do a fill and
sometimes a stroke (or both.) Of-course you then cannot keep the
graphic state save (or you should use a parameter to tell what to do).
But in case of a logo in my opinion the state should be saved. Even
more damaging: the logo was not placed where you would think, but
below and to the left. But hey, it is easy to point on the fault of
someone else his code, it is a completely different thing to write
code without faults yourself. :-D

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1460 — Procedure argument comments (was Re: How to make a stickman)

On Monday, July 15, 2013 5:34:36 AM UTC-5, Cecil Westerhof wrote:
> 
> I was not clear: what I meant, I wrote:
> 
>     % Places a stickman at x, y. Two units wide, seven units high.
>     /stickman { % x y unit
> 
> 
> and it is better to write:
> 
>     % x y unit  stickman  -
>     % Places a stickman at x, y. Two units wide, seven units high.
>     /stickman {
> 
> 
> What would be better, first stack effect and then description (if
> any), or the other-way around?
> 

I think the second way is better in general,
but sometimes the first is "good enough".

There is a third way I sometimes use, 
when I'm too lazy to type the name twice. :)

     % x y unit  .  -
     % Places a stickman at x, y. Two units wide, seven units high.
     /stickman {

[toc] | [prev] | [next] | [standalone]

#1428

On Saturday, July 13, 2013 8:46:37 AM UTC-5, Cecil Westerhof wrote:
 
> By the way, I want to expand this function, so that I can draw a range
> of stick mans:
>     - the default one
>     - happy one
>     - angry one
>     - sad one
>     - kneeling
>     - …
> 
> 
> What is the best way to do this? I mean graphically, but also
> programmatically: how to write it so it is easy to use.
> 

Here's an idea. Inspired by Sherlock Holmes and the Dancing Men.
The arms and legs are procedure bodies passed to the primary procedure.

%!

/up {
    currentpoint
    gsave newpath
    moveto
    .5 .5 rlineto
    stroke
    grestore
} def

/up-flag {
    currentpoint
    gsave newpath
    moveto
    .5 .5 rlineto
    0 .2 rlineto
    .1 0 rlineto
    0 -.1 rlineto
    -.1 0 rlineto
    stroke
    grestore
} def

/straight {
    currentpoint
    gsave newpath
    moveto
    0 -.8 rlineto
    .15 0 rlineto
    stroke
    grestore
} def

/bent {
    currentpoint
    gsave newpath
    moveto
    .4 -.3 rlineto
    -.3 -.4 rlineto
    .1 -.05 rlineto
    stroke
    grestore
} def

% left-leg right-leg left-arm right-arm unit x y
/fig {
    gsave newpath
    moveto
    dup dup scale
    1 exch div setlinewidth
    currentpoint .1 -90 270 arc
    currentpoint fill  %head
    moveto
    0 -.5 rlineto  %neck
    exec -1 1 scale  %right-arm
    exec -1 1 scale  %left-arm
    0 -.5 rlineto  %body
    exec -1 1 scale  %right-leg
    exec -1 1 scale  %left-leg
    stroke
    grestore
} def

//straight //bent //up //up-flag 50 100 200 fig

[toc] | [prev] | [next] | [standalone]

#1429

Op zondag 14 jul 2013 03:22 CEST schreef luser:

> On Saturday, July 13, 2013 8:46:37 AM UTC-5, Cecil Westerhof wrote:
>
>> By the way, I want to expand this function, so that I can draw a
>> range of stick mans: - the default one - happy one - angry one -
>> sad one - kneeling - …
>>
>>
>> What is the best way to do this? I mean graphically, but also
>> programmatically: how to write it so it is easy to use.
>>
>
> Here's an idea. Inspired by Sherlock Holmes and the Dancing Men. The
> arms and legs are procedure bodies passed to the primary procedure.

Thank you very much. That is very useful. I do not have to be afraid
to get bored. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web