Okay, I'm really curious how people do animations in POV-Ray, especially 
those not using Moray or Poser, etc.

Given that my animations are entirely written in SDL, there are tricks 
to that which I have learned (and some tricks I struggle to un-learn). 
Anyway, I'll propose some things which *I suggest* make it easier to 
script animations of complex scenes:

1) Separate the complex object definition ("character definition") from 
the motion definition ("animation script").  This will localize code and 
allow a "character" to be used in different works  -- even allowing 
different scenes in the same work to be developed separately.

2) Organize the motion chronologically, not by character.  This is 
important in the development process while time lines are being adjusted 
to get the action that is intended, especially when causality is to be 
implied.

3) Allow exceptions to suggestion #2, so that things which are not 
interrelated can be scripted separately, but happen in parallel.

Comments?
Marvin

PS: I'm familiar with ClockMod, but don't see how it could implement #2 
or #3, and #1 isn't trivial.

Post a reply to this message

I think that if you made some suggestion on how to actually implement
those abstract ideas, I (we?) could get a better understanding of what you
are talking about...

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

> Okay, I'm really curious how people do animations in POV-Ray, especially
> those not using Moray or Poser, etc.

What I mostly do is set a one global variable: Animation_Time. The POV-Ray
"clock"-value runs from 0 to 1 during my animations, so I wouldn't have to
supply Ini-Files with my Animations. Animation_Time then tells me the amount
of seconds I want to animate. Based on Animation_Time, I set when effects
start, how long they are, etc. I rarely base on frames, though I do take the
amount of time that passes between two frames as reference for different
calculations of course. In this manner, I can easily switch from 5 - 10 FPS
(rough cut) to 25 FPS (final).

As for the organization: First, there's the object definition. May it be
with Macros or just declared objects taking previously declared values (I go
more with Macros these days) I try to keep the object and the values that
animate it seperate, so that I may easily use different values.

Most of the times, my files are organized to take declarations and values
first, then come objects and macros, and finally, the use of the
macros/placement of objects.

Regards,
Tim
.
-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Warp wrote:
>   I think that if you made some suggestion on how to actually implement
> those abstract ideas, I (we?) could get a better understanding of what you
> are talking about...

Actually, I have implemented this as a set of 15-20 macros and am 
pondering polishing and documenting them up enough to "publish" them.

For example, the backhoe that I published in p.b.animations ("Diggin' 
It") use the code below.

Note that I use macros extensively, and pass all time-variant values 
into it (for point #1).  The TikTok macros (what I've called them) 
provide a solution for point #2 (time ordering).  In fact I wrap the TT 
macros in a macro just to make the code more readable.

And in this example point #3 (parallel scripts) isn't used because it's 
just a single character.

---------SNIP-------------

#include "tiktok.mcr"

#macro LinearClk(dt,dh0,dh1,dh2,dh3,dl0,dl1,dw,df1,df2)
   TT_dLinearClock(dt, hoe0, dh0) TT_dLinearClock(dt, hoe1, dh1)
   TT_dLinearClock(dt, hoe2, dh2) TT_dLinearClock(dt, hoe3, dh3)
   TT_dLinearClock(dt, ldr0, dl0) TT_dLinearClock(dt, ldr1, dl1)
   TT_dLinearClock(dt, ft1,  df1) TT_dLinearClock(dt, ft2,  df2)
   TT_dLinearClock(dt, whls, dw)  TT_dFinishTimeSlice(dt)
#end

//            Bucket   Fore  Upper  Shldr  FBkt  FArms  Whls   Feet
#declare hoe0 = 0;
#declare hoe1 =	      -100;
#declare hoe2 =		       60;
#declare hoe3 =			     -60;
#declare ldr0 =				    -20;
#declare ldr1 =					  0;
#declare whls =						 0;
#declare ft1  =						    41.5;
#declare ft2  =							 41.5;

LinearClk( 0.5,     0,    40,   -30,     0,    0,  20,   -10,  -10,  0 )
LinearClk( 0.4,   -60,   -60,     0,     0,   20,   0,	 0,    0,-10 )
LinearClk( 0.3,   -20,     0,    60,     0,    0, -10,	20,   -5,  0 )
LinearClk( 0.6,     0,     0,     0,   120,  -10,   0,	 0,    0, -5 )
LinearClk( 0.2,    60,    40,     0,     0,    0,   0,   -10,    0,  0 )
LinearClk( 0.6,    20,   -20,   -30,  -120,  -10, -10,	 0,   15, 15 )

Backhoe(hoe0, hoe1, hoe2, hoe3, ldr0, ldr1, whls, ft1, ft2)

Post a reply to this message

Marvin Taylor wrote:
> 
> 1) Separate the complex object definition ("character definition")
> from the motion definition ("animation script").  This will localize
> code and allow a "character" to be used in different works  -- even
> allowing different scenes in the same work to be developed separately.

I do this with all of my models.

> 2) Organize the motion chronologically, not by character.  This is
> important in the development process while time lines are being
> adjusted to get the action that is intended, especially when causality
> is to be implied.

I organize by shot.  I have a bit of code to specify which shot is
currently being rendered (based on the time since the start of the
animation).  Based on this shot, exactly one scene file is called.

For instance, I'm working on the 23rd Rusty animation.  The main file
is r#23.pov .  This file calls r#23_s00.inc for shot #0, r#23_s01.inc
for shot one, etc.  Everything that is peculiar to a shot is done or
called from that file.

> 3) Allow exceptions to suggestion #2, so that things which are not
> interrelated can be scripted separately, but happen in parallel.

The titling is called from a separate set of files, named r#23_t00.inc,
and so on.

Regards,
John

Post a reply to this message

In regards to your number three, you can declare any number of individual
time-varying control functions with the clockmod and autoclck extensions, so
things can easily be scripted separately and run in parallel (or vice
versa).
DM

#declare ROT = (From (0, 0) To (.8, 0) To (.83, 65)  To (3.0,0))  ;
#declare WRP = (From (0, 0) To (.544, 0)  To_Using (2.16, .50,"L")  To
(2.45,.51)  To_Using (2.71, .44,"A") To (2.866, .44)   To (3.0, 0)  )  ;

    warp {
    turbulence 0.671023*WRP
    octaves 10 *WRP
    lambda  3.19642*WRP
    omega 0.993743*WRP
    }
   scale <4/3, 1, 1> rotate y*ROT }


"Marvin Taylor" <pov### [at] maltasoftcom> wrote in message
news:403675e8$1@news.povray.org...
> Okay, I'm really curious how people do animations in POV-Ray, especially
> those not using Moray or Poser, etc.
>
> Given that my animations are entirely written in SDL, there are tricks
> to that which I have learned (and some tricks I struggle to un-learn).
> Anyway, I'll propose some things which *I suggest* make it easier to
> script animations of complex scenes:
>
> 1) Separate the complex object definition ("character definition") from
> the motion definition ("animation script").  This will localize code and
> allow a "character" to be used in different works  -- even allowing
> different scenes in the same work to be developed separately.
>
> 2) Organize the motion chronologically, not by character.  This is
> important in the development process while time lines are being adjusted
> to get the action that is intended, especially when causality is to be
> implied.
>
> 3) Allow exceptions to suggestion #2, so that things which are not
> interrelated can be scripted separately, but happen in parallel.
>
> Comments?
> Marvin
>
> PS: I'm familiar with ClockMod, but don't see how it could implement #2
> or #3, and #1 isn't trivial.
>

Post a reply to this message

in article 403675e8$1@news.povray.org, Marvin Taylor at
pov### [at] maltasoftcom wrote on 2/20/04 3:02 PM:
 
> 1) Separate the complex object definition ("character definition") from
> the motion definition ("animation script").  This will localize code and
> allow a "character" to be used in different works  -- even allowing
> different scenes in the same work to be developed separately.
 
> 2) Organize the motion chronologically, not by character.  This is
> important in the development process while time lines are being adjusted
> to get the action that is intended, especially when causality is to be
> implied.

I'm doing it the way those chumps in Hollywood do it; namely, I create the
set/location and shoot all the scenes that occur there, regardless of what
sequence the shot comes in.

For each shot, or "scene" (how I refer to it), I have one "main.pov" file,
which holds all the actors/sets/props include files & master debug control.
Example:

#include "colors.inc"
#include "danRand.inc"
#include "spline.mcr"
#include "danInc.inc"
#include "danAnim.inc"

//background { color White }

//-------------------------------
//    GLOBAL SETTINGS
//-------------------------------

global_settings {
    max_trace_level 5 // SET TO 8 FOR FINAL
}

//-------------------------------
//    GLOBAL CONSTANTS
//-------------------------------

#declare DEBUG         = 1;
#declare DEBUG_TEXT     = 2;
#declare DONT_SHOW     = 3;
#declare FINAL         = 4;

#declare PC        = 1;
#declare MAC        = 2;

//-------------------------------------
//    INCLUDE PROPS/SCENERY/ACTORS
//-------------------------------------

#include "work_room.txt"
#include "desk.txt"
#include "robot_1.txt"
#include "robot_4.txt"

//------------------------------
//    SET THE MODES
//------------------------------

#declare HERO_ROBOT_MODE = DEBUG_TEXT;
#declare DRONE_ROBOT_MODE = DEBUG_TEXT;
#declare FLOOR_MODE = DEBUG;
#declare LEFT_WALL_MODE = DEBUG;
#declare REAR_WALL_MODE = DEBUG;
#declare CEILING_MODE = DONT_SHOW;
#declare DESK_MODE = DEBUG;
#declare SCREEN_MODE = FINAL;

#declare CAMERA_OVERHEAD = false;
#declare SPLINE_PATH_DEBUG = false;    // flag for showing spline paths
#declare COMPUTER_MODE = MAC;         // PC, MAC

//-------------------------------
//    INCLUDE CONTROLS
//-------------------------------
#include "work_room_control.txt"
#include "hero_control.txt"
#include "drone_1_control.txt"
#include "drone_2_control.txt"

//-------------------------------
//    LIGHTS
//-------------------------------
#include "light_control.txt"

//-------------------------------
//    CAMERAS
//-------------------------------
#include "camera_control.txt"


Each of the "control" includes hold more include files; they control the
motion/movement of the character's or prop's individual components, like
arms, eyes, & so forth.

The MODE variables control the appearance of the character/prop during
production.  When I'm modelling, I rig the models with simple shapes that
the final object is based on (I'd show a picture, but binaries are frowned
upon here).  I also create a simple texture ( pigment { color rgb 1}) that I
use for default.  This speeds up the renderings when I'm in the process of
working out motion, splines, etc...

> PS: I'm familiar with ClockMod, but don't see how it could implement #2
> or #3, and #1 isn't trivial.
> 

I don't use ClockMod (or even clock) - I base it off frame_number.  I always
shoot at 24 fps (shooting on ones).  Granted, it would be a huge pain in the
arse if I have to convert to 25 or 30 (or 29.97), but I haven't had an issue
with that so far (*knocks on wood*).

----------
Dan
Goofy Graffix - http://www.huntel.net/goofygraffix

Post a reply to this message