POV-Ray : Newsgroups : povray.general : Inverse Kinematics, etc.... Server Time
12 Aug 2024 17:12:31 EDT (-0400)
  Inverse Kinematics, etc.... (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
From: Rudy Velthuis
Subject: Re: Inverse Kinematics, etc....
Date: 23 Feb 1999 08:14:17
Message: <36d2a9a9.0@news.povray.org>
Anthony Bennett schrieb in Nachricht
<36D1DBBE.EE209389@panama.phoenix.net>...
>Hello all. I found this great (or so I think) page that explains how to
>model all kinds of real world events; string, cloth, gel, spherical
>heighfields, fire, water, wu particles, etc. etc.

I've been browsing this. Good tutorials and examples. You can even download
them as zip files. Very good indeed. Translating the pseudo code to POV
script would be a bit harder though. Would better fit in a patch or two
(cloth, gel, etc.).

--
Rudy Velthuis


Post a reply to this message

From: Anthony Bennett
Subject: Re: Inverse Kinematics, etc....
Date: 23 Feb 1999 09:45:01
Message: <36D2C060.A0FDC915@panama.phoenix.net>
> This linke is very useful. I searched for a link like this!
>
> Thanks!

I'm glad I could help, Marc. =)


Post a reply to this message

From: Anthony Bennett
Subject: Re: Inverse Kinematics, etc....
Date: 23 Feb 1999 09:47:25
Message: <36D2C0E3.482B859F@panama.phoenix.net>
> I've been browsing this. Good tutorials and examples. You can even download
> them as zip files. Very good indeed. Translating the pseudo code to POV
> script would be a bit harder though. Would better fit in a patch or two
> (cloth, gel, etc.).
>

I think that the Inverse Kinematics could be converted into a macro (I have no
idea how, I just guess that it could). A patch with these things would be
extremely cool. The spherical heightfields would be interesting too.


Post a reply to this message

From: The Crazy Mule
Subject: Re: Inverse Kinematics, etc....
Date: 24 Feb 1999 04:57:51
Message: <36D3CC5E.7AB1E450@paradise.net.nz>
Anthony Bennett wrote:
> 
> > I've been browsing this. Good tutorials and examples. You can even download
> > them as zip files. Very good indeed. Translating the pseudo code to POV
> > script would be a bit harder though. Would better fit in a patch or two
> > (cloth, gel, etc.).
> >
> 
> I think that the Inverse Kinematics could be converted into a macro (I have no
> idea how, I just guess that it could). A patch with these things would be
> extremely cool. The spherical heightfields would be interesting too.

Putting IK into a macro, and a great many other things, are currently
inefficient in POVRay w/ animations as for each you need to recalculate
everything from the start of the animation.  Does anyone know of a patch (or is
someone interested in making one) where you can have global variables, that hold
their value from frame to frame?
-- 
Sam
    mailto:smi### [at] paradisenetnz
    http://www.geocities.com/SiliconValley/Horizon/4152/

"Someday we'll look back on this moment and plow into a parked car." 
  -- Evan Davis


Post a reply to this message

From: Thomas Willhalm
Subject: Re: Inverse Kinematics, etc....
Date: 24 Feb 1999 09:36:11
Message: <qqmu2wb3m3o.fsf@goldach.fmi.uni-konstanz.de>
The Crazy Mule <smi### [at] paradisenetnz> writes:

> Anthony Bennett wrote:
> 
> Putting IK into a macro, and a great many other things, are currently
> inefficient in POVRay w/ animations as for each you need to recalculate
> everything from the start of the animation.  Does anyone know of a patch 
> (or is someone interested in making one) where you can have global 
> variables, that hold their value from frame to frame?

How about writing them to a file with the new #read and #write directives?
There is also a new clock_delta constant. In my opinion, this should be
all that you need. (No, I don't have the time to try to write such macros.)

Thomas


-- 
http://www.fmi.uni-konstanz.de/~willhalm


Post a reply to this message

From: Margus Ramst
Subject: Re: Inverse Kinematics, etc....
Date: 24 Feb 1999 13:22:36
Message: <36d4436c.0@news.povray.org>
Thomas Willhalm wrote:
>
>How about writing them to a file with the new #read and #write directives?
>There is also a new clock_delta constant. In my opinion, this should be
>all that you need. (No, I don't have the time to try to write such macros.)
>


This would be plausible, if these directives were a bit more configurable.
Right now #read just reads a number of params from the start, you can't
specify an offset to the read. This severely limits its possibilities.
Believe me, I've tried.

Margus


Post a reply to this message

From: BC
Subject: Re: Inverse Kinematics, etc....
Date: 25 Feb 1999 00:46:05
Message: <01be6082$951be1c0$010b010a@angela>
The possibilities aren't really that limited. For example, if you want to
read the Nth item in a file, just close it, re-open, and read till you get
there. It may be slow, but it works!

In the early days of computers, almost all data processing was done on
serial access devices. There were all sorts of clever algorithms created to
do this as efficiently as possible. (Merge Sort is one that comes to mind.)

Have a read of the Knuth "Art of Computer Programming" series for example.
I actually really enjoy the challenge of working around the limits of the
language. But maybe I'm a masochist.

Regards
Gordon
<gbe### [at] birdcameroncomau>

Margus Ramst <mar### [at] peakeduee> wrote in article
<36d4436c.0@news.povray.org>...
> 
> Thomas Willhalm wrote:
> >
> >How about writing them to a file with the new #read and #write
directives?
> >There is also a new clock_delta constant. In my opinion, this should be
> >all that you need. (No, I don't have the time to try to write such
macros.)
> >
> 
> 
> This would be plausible, if these directives were a bit more
configurable.
> Right now #read just reads a number of params from the start, you can't
> specify an offset to the read. This severely limits its possibilities.
> Believe me, I've tried.
> 
> Margus
> 
> 
>


Post a reply to this message

From: Margus Ramst
Subject: Re: Inverse Kinematics, etc....
Date: 25 Feb 1999 03:32:19
Message: <36D50A92.8B882231@peak.edu.ee>
BC wrote:
> 
> I actually really enjoy the challenge of working around the limits of the
> language. But maybe I'm a masochist.
> 

To a certain point, it's fun. From then on, it's tedious and just plain
impractical. Some projects I've worked on have required very extensive and
very dynamic data processing, tens of thousands of data lookups and
stores. Thank God (or the POV team) for arrays - but these are useless for
animation.
Mine may be an extreme case, but I'd rather just specify an offset to the
read/write. This shouldn't be too difficult to implement (and is one of
the top items in my wishlist).

Margus


Post a reply to this message

From: Ron Parker
Subject: Re: Inverse Kinematics, etc....
Date: 25 Feb 1999 08:23:38
Message: <36d54eda.0@news.povray.org>
On 25 Feb 1999 00:46:05 -0500, BC <bir### [at] iinetnetau> wrote:
>Have a read of the Knuth "Art of Computer Programming" series for example.
>I actually really enjoy the challenge of working around the limits of the
>language. But maybe I'm a masochist.

If you can actually read TAOCP all the way through, yes, you're a masochist.
I'm about halfway through volume 1, following the algorithm in the front of
the book (read all volumes, repeat indefinitely) and I had to take a break.


Post a reply to this message

From: BC
Subject: Re: Inverse Kinematics, etc....
Date: 25 Feb 1999 23:25:34
Message: <01be6140$85e60c80$010b010a@angela>
If you want to keep the values of an array (or several) between frames, why
not save the whole array sequentially to a file at the end of the parse of
each frame and then load the whole thing at the start of the next frame.
You can then just use the arrays as you are at the moment.

This should only need a couple af simple Macros and the process is
essentially automatic from there on.

Good Luck and Regards
Gordon

PS
I do agree it would be a very useful feature though. I would also like to
be able to read general text files. Like the Readln function in pascal for
example. Just read the whole line, delimiters and all into a string
variable and leave it to the program to decode the data. I came up against
this when I tried to write a routine to read two identically structured
POVRay source files and interpolate the values for animation.

Any way, no doubt the POV-Team will suprise us with many neat new features
in the next version.

Margus Ramst <mar### [at] peakeduee> wrote in article
<36D50A92.8B882231@peak.edu.ee>...
> BC wrote:
> > 
> > I actually really enjoy the challenge of working around the limits of
the
> > language. But maybe I'm a masochist.
> > 
> 
> To a certain point, it's fun. From then on, it's tedious and just plain
> impractical. Some projects I've worked on have required very extensive
and
> very dynamic data processing, tens of thousands of data lookups and
> stores. Thank God (or the POV team) for arrays - but these are useless
for
> animation.
> Mine may be an extreme case, but I'd rather just specify an offset to the
> read/write. This shouldn't be too difficult to implement (and is one of
> the top items in my wishlist).
> 
> Margus
>


Post a reply to this message

<<< Previous 2 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.