RE: animation

Hello!

> 
> To the others: experiences or opinions please ...
> 

Experience I don't have much, but opinions, man, do I have a lot of
opinions! ;)

Beware it's long winded. People with exams to study for, dissertations to
write or any other important thing to do in real life, like brushing your
teeth, please keep in mind that that is more important than the ramblings of
a spare time kde programmer with a lot of free time on his hands. This can
wait.

That said...

I think the problem we're facing here is that kpovmodeler is inherently a
static image modeller. Povray is a static image renderer and kpovmodeler
followed it.

We can look at animation in two ways:

1. Much like a movie an animation is a series of fotographs or static scene
renderings. 
      In that case, the scripts, given a fotogram, compute the position of
the object in that fotogram. 
      In this modelling style, each script can be seen as a series of f(x),
where x is the fotogram, one for each parameter of the object.
	The user draws the first fotogram of the animation and defines a
script that calculates the values for each fotogram from then on.
      If the user needs to change the position of an object in the middle of
the animation he just goes to that fotogram and changes it. The script
changes so that the position is different as well.
	In this case, what gets saved is the first fotogram and the script
of changes, or we can forget the scripts and just append complete scenes one
after the other. A pain in the *** to model.

2. Real life
	In real life objects interact with each in sometimes unforseen ways.
	The scripts will model how objects interact with each other (a
physics model more or less). 
      In this case, the next fotogram to be computed depends of the current
one.
	To render or preview this you have to step through every fotogram so
that you get to the current position
	In this case, it is not possible to edit a certain fotogram if it's
not a base fotogram.
      What gets saved? Again the base scene and the script.

As you can see, in the most simple case, with one base scene and no tweaking
of the animation, both ways are the same.
The problem is that, in some animations, you don't want a perfect model. For
effect you need that a certain object bounces in a strange way that you
can't quite model mathematically. Call it artistic freedom.

In that case, in the first option you can edit the fotogram easily. In the
second case you can't do it as easily.

Personally, I see the animation much like mpeg. MPEG has complete frames,
then it has changes to frames. Once in a while another complete frame
appears, to solve possible noise due to the differences being inacurate.
So to animate you have a scene and changes to that in a script, up to some
point in time. Then you have another complete scene, that you can edit and
more changes in a script, and so on, and so on.

Here's what I'd do:

An animation is a collection on scenes.
Each scene has it's own objects, a start time and an end time.
Each object can have one or more scripts.
Each script defines start time, end time, and if it needs the previous state
to compute the next one.
The script indicates it's variables, with default values, or an
initialization procedure.
It also has a procedure to compute fotogram x.

Editing of the scene can only be done to the base scene.

I liked that PNG showing a timetable where, for each object it shows the
scripts applied to it. 
Through there you can choose what script you want to edit.

We could refine this model having not only scripts but, more generally,
animation effects. When you click an animation effect, you have the
animation properties in the dialog view. Be it a path in the scene with
speed and acceleration, a text widget to edit the python script, explosion
parameters, stretch effects, whatever.

Another thing we could do is have a special kind of scene called scenery.
The scenery will be used through out the entire animation. It's just walls
and static furniture, buildings, whatever.

You asked for my opinion... here it is.
Luis

List archive and information: http://mail.kde.org/mailman/listinfo/kpovmodeler-devel