From: quinn at agora.ugcs.caltech.edu (Quinn Dunkan)
Date: 12 Apr 1999 22:08:58 GMT
Subject: povray.py
References: <__YN2.30200$FZ5.11443@news.rdc1.sfba.home.com> <y0jpv5hx606.fsf@vier.idi.ntnu.no> <m3bth1wk8b.fsf@solo.david-steuber.com> <slrn7go62n.f5i.quinn@cruzeiro.ugcs.caltech.edu> <370E4F3E.F9C2CD07@lockstar.com> <slrn7gsick.14q.quinn@necro.ugcs.caltech.edu> <joe-090419991348467996@chinacat.salk.edu>
Message-ID: <slrn7h4rnu.9c6.quinn@agora.ugcs.caltech.edu>
Content-Length: 2155
X-UID: 1136                                                  

On Fri, 09 Apr 1999 13:48:46 -0700, Joe Strout <joe at strout.net> wrote:
>In article <slrn7gsick.14q.quinn at necro.ugcs.caltech.edu>, Quinn Dunkan
><quinn at necro.ugcs.caltech.edu> wrote:
>
>> pov.py v0.0:
>> http://www.calarts.edu/~elaforge/pov/
>> 
>> I guess it's released now :)
>
>Cool!  Looks very neat.  I'm not quite clear on how you're planning to
>handle animations.  Will your Python script spit out a different
>POV-Ray script for each time point?  Or will it spit out a whole series
>of them?  Some things, like flocking behavior, are really hard to
>implement in a clock-independent way.

Um, I guess I'm not understanding what you mean... "will it spit out a bunch of
pov scripts or will it spit out a bunch of pov scripts?"  Er, yes :) (different
script for each time point).  I see no reason to use pov's animation features
(clock, etc) we can do all that from python better.  One of my original
frustrations with animation under pov was that you couldn't keep a state
between frames.  While it's an elegant approach in theory, I don't want to do
calculus to drop a ball, and huge #case #range etc. to have it bounce :)  So I
think my approach to clock independence would be to have stateful objects that
when you tell them advance time_interval they modify their velocity and advance
themselves.  Pre-Newtonian physics, I guess, but I'm still a physics idiot :)
I'm sure someone more math-minded than myself could come up with some cool
ideas / code.

>Also, I see matrix transforms are on your to-do list.  I suggest you
>use the Numeric module.  Use dot(m1,m2) or dot(m1,v) to combine
>matrices or apply a transformation matrix to a vector, respectively.

Hmm... I'd rather not require external packages if it can be avoided.  If
the matrix stuff is trivial, I'll reinvent it.  But it's a good idea to look
at NumPy anyway because there's probably some stuff in there that will be
useful in other ways too.  I've already made my own vectors, but it was a
Learning Experience :)


BTW, the initial release had some minor code rot that made it non-functional
(transforms in the wrong place, etc.) but I replaced it pretty quickly.




