Hildur K. wrote:


*Gasp* Incredible! Those ninja stills guys! Always around, 
but invisible right until they move :)

> Anyway, it seems like we have one problem in common. The IRTC server has

> though the stills round deadline ended on the 31st of December, a new topic


> either.

> ever.

Last animations round, it took three weeks plus (Oct. 15 - 
Nov. 10) for the next topic to appear.

I'm hoping for something to happen over the weekend... 
anyway, i wouldn't mind delays, if at least there'd be the 
occasional heads-up from the admins... the way it's right 
now, it feels like some kind of limbo.

Currently, i'm re-rendering my animation with the camera 10 
cm to the left and 1 degree turned right, and then i'll try 
to create a red-green anaglyph video version. I'd rather be 
dwelling on the new topic, though...
I've also had good success by cross-eyeing two playback 
windows side-by-side, it helps to hold the hand so that the 
left eye sees the right window and vice versa.

-Markus

Post a reply to this message

David Cuny wrote:
>>Why is it that the IRTC animation comp always seems so under-entered but the
>>stills typically has loads of entries?
> 
> 
> I can think of a lot of reasons that have very little to do with the
> competition itself:
> 
> * Animation is hard. Good animation is harder.

And designing a model that is easily animated is harder.  AFAIK, there 
is one mesh modeling program that exports an .INC containing a model 
that is posable by POV-Ray SDL.

> * POV doesn't have a GUI for animation.

But the author of the aforementioned app hopes to get that working 
sometime this year...

> * More models have to be made, for multiple scenes.
> * Models have to be articulated for animation, or they break in nasty ways.

Which ties in with the first item.

> * Animation needs a story with a beginning, middle and end.
> * Render times are much higher, because you need 24 frames for one second.

This is, indeed, the killer.  The stills side frequently has pictures 
that takes days to render.  One hour per frame limits animation entries 
to 90 seconds of animation, tops, minus one second for every day spent 
in modeling or test animating, or not rendering because nothing's ready 
for final render.

A lot of Rusty was rendered while I've been at work or asleep.

> Additionally:
> 
> * There aren't many free animation programs.
> * Animation programs have a large learning curve.
> * It's hard to compete against professional animation packages.
> 
> Now, John VanSickle scored all the animation rounds last year using "pure"
> POV-Ray, even against Markus Altendorff's excellent animations, which used
> Maxxon 3D. So take three with a grain of salt.

It's true that everything was rendered by POV-Ray, but two models were 
done with my modeler instead of hand-written SDL code.  One model 
probably could have been done with SDL code, but the other one 
definitely required my modeler.

> On the other hand, there were a number of submissions I was surprised to
> find didn't even make Honorable Mention:
> 
>    - Leroy Whetstone/October-January 2006
>    - M.A.c.v./October-January 2006
>    - Nimish Ajmani/July-October 2006
> 
> So why didn't these get Honorable Mentions? It's because the scoring doesn't
> actually follow the above guidelines.

And because due to low turnout, there haven't been Honorable Mentions 
since the April-July 2005 round.

Many of the times this has happened, there have been only six entries 
(or fewer).  The first time this happened, there was grumbling because 
it guaranteed that everyone would get at least an H.M., which did not 
sit well with some people.

> What if (like John VanSickle and his
> LionSnake modeler) you've actually written your own modeler or animator?
> Should you get extra points for that?

No, I should get a lifetime supply of Diet Coke!

> Making Honorable Mention a bit easier to get into might help (i.e. adding a
> "cheap tool" or "newbie" bonus), but that's awfully subjective.
> 
> Anyway, these can be factors in discouraging someone who submitted from
> submitting again. But I'm guessing the biggest barrier to people submitting
> animations in the first place is still my first point: Animation is Hard.

Yup.

Regards,
John

Post a reply to this message

>> * POV doesn't have a GUI for animation.

> But the author of the aforementioned app hopes to get that working
> sometime this year...

Heh. I wondered when you'd add that to LionSnake and join the dark side! ;-)

AFAIK, the early days of Pixar animation used a POV=SDL sort of approach.
They have a proprietary interface called 'Marionette.' Characters were
rigged with 'avars' (articulation variables), and characters were animated
using a spreadsheet sort of interface. Time (in frames) ran along the 'x'
axis, and 'avars' on the 'y' axis. To animate a character, you could either
click in a cell and enter a value, or click a cell and drag the mouse to
change the cell value.

A lot's changed since then, although if you check out the 'extras' in "The
Incredibles" video, you can see that same interface is being used.

There are only a handful of free animation programs that are capable of
supporting the features that are needed for character animation - bones,
morphs, and so on. By their nature, most have a pretty steep learning
curve. Although it's subjective, it's generally safe to say that the more
features an application has, the more difficult it is to learn.

Problematically, most don't support POV. Here are the ones that I'm aware
of:

* Blender: Very functional. They've added an internal raytracer as well as
export to Yafray and Sunflow, so I don't know if POV is supported anymore.

* Art of Illusion: This is another nice program, written in Java. It has
it's own advanced raytracer, so there's no export to POV.

* Anim8or: Pretty easy to use, and more animation functionality has been
added. Because of licensing issues, POV is not supported.

* K3D: Renderman only. I've never seen an animation done with this.

In the 'beta' category, I'll add the following, since they both support POV:

* JPatch: Still in beta. Exports to POV for rendering, not POV-SDL.

* LionSnake: Still in development.

So not only is animation hard, but animation using POV is harder, because
it's decades behind other programs. It'll be interesting to see how
LionSnake turns out.

Personally, I'm using JPatch, but with Inyo (my own raytracer) instead of
POV. You've got to eat your own dogfood, right?

Post a reply to this message

David Cuny wrote:
>>>* POV doesn't have a GUI for animation.
> 
>>But the author of the aforementioned app hopes to get that working
>>sometime this year...
> 
> Heh. I wondered when you'd add that to LionSnake and join the dark side! ;-)

I've been scheming it for a while (since 2003 at least).

> AFAIK, the early days of Pixar animation used a POV=SDL sort of approach.
> They have a proprietary interface called 'Marionette.' Characters were
> rigged with 'avars' (articulation variables), and characters were animated
> using a spreadsheet sort of interface. Time (in frames) ran along the 'x'
> axis, and 'avars' on the 'y' axis. To animate a character, you could either
> click in a cell and enter a value, or click a cell and drag the mouse to
> change the cell value.
> 
> A lot's changed since then, although if you check out the 'extras' in "The
> Incredibles" video, you can see that same interface is being used.

Been there, done that, still considering the idea.  My present ambition 
is to have that view and the scene view, and to allow edits in either 
view, with the edit being translated over to the other view.  I hope it 
works.

> There are only a handful of free animation programs that are capable of
> supporting the features that are needed for character animation - bones,
> morphs, and so on. By their nature, most have a pretty steep learning
> curve.

My hope is to have a user interface with one rule:  "When in doubt, 
right-click."  The idea is that a right-click should bring up a context 
menu that covers everything the user can do with the object over which 
the mouse pointer is hovering at the time.  The features can be accessed 
in other ways, true, but the learning curve is simplified if newbies 
have one-stop shopping for their info.

> * LionSnake: Still in development.

And I made a design decision a couple weeks ago that's going to delay 
things.  For some reason I decided that supporting only 3- and 4-sided 
faces was too limiting, so I'm adding support for faces with unlimited 
number of sides[1].  This means:

*  Just about every function that deals with faces has to be rewritten[2];
*  The save format has to be changed [3];
* My surface subdivision macros have to be completely rewritten, because 
the export POV SDL files use the macros [4].

So except for bugfixes to the current version (1.6), there won't be 
anything released in a while.

Regards,
John

[1] Well, okay, the number of sides for a given face is limited to 
32767.  You got a problem with that?

[2] I still have to rewrite the functions to subdivide a portion of the 
mesh; split edges; and to join two vertices together.  The subdivision 
preview is back down to one preview step, and the child faces are flat, 
not smoothed, to the results are still kind of rough.  And of course all 
of the file operations have to be rewritten to support the new features, 
too.

[3] I decided to abandon the save format I developed (since the world 
really did not need a new 3d model format) and have the app use OBJ and 
MTL files for saving and loading geometry and texturing data; the 
animation data will go into a separate file, format to be determined. 
As I write this I am downloading a spec that uses XML :P, but if it's 
too complicated, or if I don't like the way it supports things, I won't 
use it.

[4] This is because the modified Loop scheme I'm presently using doesn't 
support the higher-sided faces.  The Catmull-Clark scheme supports any 
number of sides in a face, so that's what will be forthcoming.

Post a reply to this message