Currently it's practically impossible to animate detailed characters in
POV-Ray efficiently.

I propose an addition to the mesh2 object that will allow a mesh2 object to
be "boned".
The idea is to apply different transformations to different parts of the
mesh.
This way you could have a character where the torso is aligned with one
transformation,
the thigh with another transformation, the shin with a third and so on.

Generation of those transformation could be done in any way transformations
can normally be created, for example using a custom include file. So forward
kinematics, inverse kinematics and all kinds of animation systems could be
created in POV-Script, which would output transformations which are used by
the mesh2 object.

In order to get smooth bending some parts of the mesh should be transformed
not by one transformation, but by a weighted average of several
transformations.
The extension I propose is to add three new blocks to the mesh2 object. They
are of course optional, but if you use them, you must specify all three.
They are: transform_indices{}, transform_combinations{}, transform_list{}.

Here is the proposed syntax:

transform_indices
      {
        number_of_faces,
        <combination_a, combination_b, combination_c>,
        <combination_d, combination_e, combination_f>,
        ...
      }

transform_combinations
      {
        number_of_combinations,
        {index_a},
        {index_b, weight1},
        {index_c, weight2, index_d, weight3},
        {index_e, weight4, index_f, weight5, index_g, weight6 ...},
        ...
      }

transform_list
      {
        number_of_transformations,
        transform { Transform1 },
        transform { Transform2 },
        ...
      }


transform_list is a list of transformations, semewhat similar to the
texture_list block.

transform_combinations is a bit special. Each combination is wrapped in { },
as it can contain any number of items. The items in a combination are pairs
of indices to transformations, and weights for those transformations. The
number of items must be even, except if there is only one index specified,
in which case the weight can be left out and will default to 1.0.

transform_indices are a list of indices that points to the combinations. It
is somewhat similar to the normal_indices.

A average of several transforms is calculated this way:
A matrix can describe any transformation, so I'll use that to explain it.
matrix <a,b,c, d,e,f, g,h,i, j,k,l>
let's call a,b,c for X, d,e,f for Y, g,h,i for Z and j,k,l for P.
The averaged transformation 3 is the averaged of the transformations 1 and
2:
P3 is simply a weighted average of P1 and P2.
X3 is the weighted average of vnormalize(X1) and vnormalize(X2) multiplied
with the weighted average of vlength(X1) and vlength(X2).
Y3 and Z3 is calculated like X3. The method also works for a weighted
average of more than two transformations.

I suggest that if the weights specified in a combination do not add up to
1.0, then they're *not* corrected. There may be situations where it can be
useful to add transformations together. Who knows? Better not to make an
unnecessary limitation.

Any way, what do you think of this proposed feature?
Do you see any problems with it?
Are anyone willing to program it?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
: I propose an addition to the mesh2 object that will allow a mesh2 object to
: be "boned".

  I think this is the duty of the modeller, not the renderer.

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

Post a reply to this message

"Warp" wrote:
> Rune wrote:
> : I propose an addition to the mesh2 object that
> : will allow a mesh2 object to be "boned".
>
>   I think this is the duty of the modeller, not the renderer.

A mesh object can easily be rather big. To have a separate mesh object for
every frame in the animation is completely nuts. Furthermore, if the
animation is handled in the mesh modeler, it becomes extremely difficult to
integrate it into POV-Ray. How can you make sure the mesh object interacts
correctly with its surroundings? Even the smallest tweaking means that you
have to do several steps of conversions before you can check the result in
POV-Ray.

Please support your opinion with more arguments.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> A mesh object can easily be rather big. To have a separate mesh object for
> every frame in the animation is completely nuts. Furthermore, if the
> animation is handled in the mesh modeler, it becomes extremely difficult to
> integrate it into POV-Ray. How can you make sure the mesh object interacts
> correctly with its surroundings? Even the smallest tweaking means that you
> have to do several steps of conversions before you can check the result in
> POV-Ray.
> 

I think you can do quite a lot with Povray's scripting features, for
example replace the vertices with macro calls like:

mesh2 {
  vertex_vectors {
    ...
    Transform1(<0.3, 0.7, 2.9>)
    ...

With a macro containing a vtransform().  Weighted transforms are also
possible with this method.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> I think you can do quite a lot with Povray's scripting features,
> for example replace the vertices with macro calls like:
>
> mesh2 {
>   vertex_vectors {
>     ...
>     Transform1(<0.3, 0.7, 2.9>)
>     ...
>
> With a macro containing a vtransform().

This has numerous problems:

* Its extremely slow for big meshes.

* Transforming the corresponding normals correctly is very difficult if
possible at all.

* It's very difficult to keep track of all the vertices this way.

> Weighted transforms are also possible with this method.

* vtransform don't give access to the different parts of the transformation
(which I named X, Y, Z and P), and thus the correct weighted average cannot
easily be performed. If you insist that it can be done, please provide a
macro that takes a weighted average of any number of transforms.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> [...]
> 
> * Transforming the corresponding normals correctly is very difficult if
> possible at all.
> 
> [...]
> 
> * vtransform don't give access to the different parts of the transformation
> (which I named X, Y, Z and P), and thus the correct weighted average cannot
> easily be performed. If you insist that it can be done, please provide a
> macro that takes a weighted average of any number of transforms.
> 

I don't see a reason why it's more difficult to do this in Pov SDL than in
c code.   Implementing your idea directly in Povray does require the same
calculations.

I do not say a function like you suggested is nonsense, but before writing
a patch for that it would be useful to try it in Pov SDL and see how it
works.  

Concerning transforms: a method for weighting several of them could surely
be useful in many cases, something like:

transform {
  average { 
    MyTrans1 weight 0.3 
    MyTrans2 weight 0.5 
  }
}

(although i'm not really content with the syntax)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> > * vtransform don't give access to the different parts of the
transformation
> > (which I named X, Y, Z and P), and thus the correct weighted average
cannot
> > easily be performed. If you insist that it can be done, please provide a
> > macro that takes a weighted average of any number of transforms.
>
> I don't see a reason why it's more difficult to do this in
> Pov SDL than in c code. Implementing your idea directly in
> Povray does require the same calculations.

Internally POV-Ray has access to the different parts of the transformation
matrix (X,Y,Z,P), while this can't be accessed directly from the SDL. An
average of transformations can only be taken if those parts are known.

But anyway, I've just remembered the ultimate argument why it can't be done
in SDL, at lest not for smooth meshes:

In order to transform a normal, one has to know the corresponding vertex.
However, in mesh2 each normal can be assigned to several vertices. Thus it
is impossible to transform the normals of mesh2 in the SDL.

> I do not say a function like you suggested is nonsense,
> but before writing a patch for that it would be useful
> to try it in Pov SDL and see how it works.

I guess it would be possible for a low-resolution non-smooth mesh, where
each vertex is assigned to one transformation only, not an average.

I'll do some experiments.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

in news:3bb70b9a@news.povray.org Rune wrote:

> But anyway, I've just remembered the ultimate argument why it can't
> be done in SDL, at lest not for smooth meshes:
> 
> In order to transform a normal, one has to know the corresponding
> vertex. However, in mesh2 each normal can be assigned to several
> vertices. Thus it is impossible to transform the normals of mesh2
> in the SDL. 
> 

 Yes, they can be assigned to several vertices, but they don't have to 
be! Nothing stops you from writing a mesh that specifies a normal per 
vertex in the normal_vectors / normal_indices. Also it shouldn't 
be too difficult to 'un-optimise' a given mesh, using a script.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

"ingo" wrote:
>  Yes, they can be assigned to several vertices, but they
> don't have to be! Nothing stops you from writing a mesh
> that specifies a normal per vertex

Ok, but that's rather inefficient.

I think there's plenty of good reasons to implement the feature I've
proposed.

Is there anybody besides me who thinks it would be a good idea?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:

> I think there's plenty of good reasons to implement the feature I've
> proposed.
> 
> Is there anybody besides me who thinks it would be a good idea?

Actually I don't think it is a good idea. I haveno use for it. This is
one of those features that would benefit only a handful of people and
99.9% of the other users would never use it. The POV-Team can't even
come up with a simple spline function that satisfies you and now you
want something 20 times more difficult to implement. I don't see it
happening.

-- 
Ken Tyler

Post a reply to this message

in news:3bb719c3@news.povray.org Rune wrote:

> Ok, but that's rather inefficient.

 Don't think so, it doesn't matter much wether you have a mesh with 10 
normals in the normal_vertices and a normal_indices list with 10.000 
entries, or 10.000 normals, most identical, in the normal_vertices and 
no need for a normal_indices list. The first one may be a bit smaller 
in size, the second one may parse a bit faster (untested).

> I think there's plenty of good reasons to implement the feature I've
> proposed.

> Is there anybody besides me who thinks it would be a good idea?

 I think it is too specific for a direct POV-Ray implementation, but it 
is very interesting as macro implementation. The latter for two 
reasons, first, we'll have a nice animation possibility.
 Second, in writing the macros you'll probably run into some problems 
with array manipulation. The speed of looping through arrays. There is 
no direct way to search in the content of an array. There is no way you 
can 'directly' manipulate all of the content of an array, say apply a 
function to each vector in it. Now if you can define this kind of 
problems accurately and can convince the Team that these should be 
possible to do from inside POV, without the need of macros, there would 
be a 'bigger gain' than by implementing what you proposed.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

"Ken" wrote:
> Rune wrote:
> > I think there's plenty of good reasons to
> > implement the feature I've proposed.
> >
> > Is there anybody besides me who thinks it would be a good idea?
>
> Actually I don't think it is a good idea. I haveno use for it.

I'm sure you don't. I haven't seen many animations from you. I haven't seen
very much POV-Ray work from you at all... ;)

But almost all serious computer animation includes character animation and
that's currently the weakness of POV-Ray. If it would be possible to animate
poser characters and the like rather easily from within POV-Ray it could
really revolutionize POV-Ray animation I think.

> This is one of those features that would benefit only a handful
> of people and 99.9% of the other users would never use it.

I don't think so. What makes you think that?

> The POV-Team can't even come up with a simple spline function
> that satisfies you and now you want something 20 times more
> difficult to implement. I don't see it happening.

FYI this group is povray.unofficial.patches

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> But almost all serious computer animation includes character animation and
> that's currently the weakness of POV-Ray. If it would be possible to animate
> poser characters and the like rather easily from within POV-Ray it could
> really revolutionize POV-Ray animation I think.
> 

But Povray is certainly not a character animator and not a modeller.  What
you suggest is a specialized capability for manipulating mesh data.  It
has of course advantages to implement this in Povray - take the cloth
simulation patch as an example for this - but the purpose is quite special
so it probably won't become part of a general Povray version.  

On the other hand if some new general 'hooks' are required for efficiently
implementing it in SDL (like 'weighting transforms') i see no problem of
those becoming part of a future (megapov) version.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Rune wrote:
>
> But almost all serious computer animation includes character animation and
> that's currently the weakness of POV-Ray. If it would be possible to animate
> poser characters and the like rather easily from within POV-Ray it could
> really revolutionize POV-Ray animation I think.

All the serious computer animations have been done with a system that has a
GUI. Very few people can do Toy Story by writing "...<34,234.23,2343>} blah{
1231,2132,<234,2334,853>..." 

When there is GUI to back it up then it's a good idea.
 
_____________
Kari Kivisalo

Post a reply to this message

I proposed something like this in my wish-list for 4.0, but I'm afraid that
it will remain a wish with the attitude most POVers have about keeping
modeller and renderer separate, something which I don't really mind
combining. The only way to really get a receptive audience for a patch is to
just sit down and program it yourself. If they like it, they will come.

Post a reply to this message

"Tony[B]" wrote:
> 
> ...with the attitude most POVers have about keeping modeller and renderer
> separate, something which I don't really mind combining.

Heretic!

-- 
Ken Tyler

Post a reply to this message

Rune <run### [at] mobilixnetdk> a écrit dans le message :
> If it would be possible to animate
> poser characters and the like rather easily from within POV-Ray
> it could really revolutionize POV-Ray animation I think.

Animating Poser characters can be already be done within Poser and the
results can be exported to Povray. I did a test with a few hundred running
horses some time ago.
You're right in saying that character animation is a weakness of POV-Ray,
but I fail to see how a POV-Ray-only solution could be useful from a
practical point of view (I mean for creating full animations, not just tests
to prove a point).

G.


**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

"Tony[B]" wrote:
> 
> I proposed something like this in my wish-list for 4.0, but I'm afraid that
> it will remain a wish with the attitude most POVers have about keeping
> modeller and renderer separate, something which I don't really mind
> combining.

Apart from personal preferences this has clear practical reasons.

> The only way to really get a receptive audience for a patch is to
> just sit down and program it yourself. If they like it, they will come.

Oh, come on.  This is not a 'ask for a feature and someone will program it
within a day'-club.  A few critical opinions and suggestions for
alternatives and someone starts thinking you are ignorant and not
constructive... ;-)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Rune wrote:
> 
> "Ken" wrote:
> > Actually I don't think it is a good idea. I haveno use for it.
> 
> I'm sure you don't. I haven't seen many animations from you. I haven't seen
> very much POV-Ray work from you at all... ;)

Huh?

Just because I don't let you see it does not mean that I am not still
using POV-Ray for both stills and animations. In fact just three weeks
ago I was working on using ISOs to model the effects of rain drops
hitting a pool of water complete with photon generated caustics. Didn't
quite get the effects I wanted so I moved on to something else. I have
a long history of half finished projects that seldom get to the point
where I feel they are worthy of sharing with others.

-- 
Ken Tyler

Post a reply to this message

"Ken" wrote:
> Huh?
>
> Just because I don't let you see it does not mean
> that I am not still using POV-Ray for both stills
> and animations.

I didn't mean to offend you in any way - I've seen a few of your images and
they're very nice.

Yet still you're not the person I'd expect to make animations of the kind
I'm thinking of. Which also seems to be what you say yourself. That doesn't
mean though that others won't have any use of the feature in question.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Gilles Tran" wrote:
> Animating Poser characters can be already be done within
> Poser and the results can be exported to Povray. I did a
> test with a few hundred running horses some time ago.

How was this done? One mesh per frame? How long was the animation? And how
much disc space did it take?

Would it have been possible to make the horses run over a height field and
other such demanding interactions with the surroundings?

> You're right in saying that character animation is a
> weakness of POV-Ray, but I fail to see how a POV-Ray-only
> solution could be useful from a practical point of view
> (I mean for creating full animations, not just tests to
> prove a point).

With the feature I propose combined with the right macros, it would be
possible to animate characters using POV-Script, just like other things can
be animated in POV-Ray.

And yes, I *do* believe quality character animation can be done writing
numbers in a text editor. With the proper macros of course.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Kari Kivisalo" wrote:
> All the serious computer animations have been done
> with a system that has a GUI. Very few people can
> do Toy Story by writing "...<34,234.23,2343>} blah{
> 1231,2132,<234,2334,853>..."

And very few people can model anything at all that way. But lots of POV
users can. I don't think you should underestimate them.

> When there is GUI to back it up then it's a good idea.

GUI is fine for some, but not a necessity.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Christoph Hormann" wrote:
> But Povray is certainly not a character
> animator and not a modeller.

People use it to model, so it is a modeller.

I'd like it to be a character animation program too.

> What you suggest is a specialized capability for
> manipulating mesh data.

No, a capability for deforming meshes in a certain way.

> the purpose is quite special

It could be used for bending, stretching, lip-synchronization, boning, and
many other things. The way I've proposed it is rather general.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Tony[B]" wrote:
> I proposed something like this in my wish-list for 4.0,
> but I'm afraid that it will remain a wish with the
> attitude most POVers have about keeping modeller and
> renderer separate, something which I don't really mind
> combining.

I feel that way too. Well, thanks for your understanding...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> [...]
> 
> > What you suggest is a specialized capability for
> > manipulating mesh data.
> 
> No, a capability for deforming meshes in a certain way.
> 

What's the difference?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> Rune wrote:
> > [...]
> >
> > > What you suggest is a specialized capability for
> > > manipulating mesh data.
> >
> > No, a capability for deforming meshes in a certain way.
> >
>
> What's the difference?

Well, it's a matter of definition I guess but I choose not to call it mesh
data manipulation since the mesh data (in the file) remains constant. "Mesh
data manipulation" leads my thoughts to changing the written mesh data,
which it is not what happens. But of course all computations involve
internal manipulation of data but that's needless to say.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

On Sun, 30 Sep 2001 18:04:20 +0200, "Gilles Tran" <tra### [at] inapginrafr>
wrote:

>You're right in saying that character animation is a weakness of POV-Ray,
>but I fail to see how a POV-Ray-only solution could be useful from a
>practical point of view (I mean for creating full animations, not just tests
>to prove a point).

I'd like to see some sort of boning features available for the meshes
I use with POV, and I don't even do animations. I'd like the ability
to accurately deform 3rd party meshes for still images. 

Of course I *could* buy Poser, Rhino, or any one of several other
commercial 3D packages, but POV-Ray is free. It would be terrific if
there were some sort of practical way to accurately deform meshes
(boning comes to mind in particular), without spending a lot of money
on some external modeler.

Later,
Glen

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3bb719c3@news.povray.org...
> "ingo" wrote:
> >  Yes, they can be assigned to several vertices, but they
> > don't have to be! Nothing stops you from writing a mesh
> > that specifies a normal per vertex
>
> Ok, but that's rather inefficient.
>
> I think there's plenty of good reasons to implement the feature I've
> proposed.
>
> Is there anybody besides me who thinks it would be a good idea?
>
I think it's a good idea, considering there are so few Pov animation entries on
IRTC. It might just help to get more animations on there.

 - Nekar

Post a reply to this message

On Sun, 30 Sep 2001 15:06:59 +0200, "Rune"
<run### [at] mobilixnetdk> wrote:

>I think there's plenty of good reasons to implement the feature I've
>proposed.
>
>Is there anybody besides me who thinks it would be a good idea?

I don't know the technical details of the best way to implement boning
in meshes, but I would definitely like to be able to use meshes with
bones in my renderings. I'd love to be able to deform and tweak
meshes,  instead of using them as static objects, as I do now.

Later,
Glen

Post a reply to this message

Glen Berry wrote:
> 
> I'd like to see some sort of boning features available for the meshes
> I use with POV, and I don't even do animations. I'd like the ability
> to accurately deform 3rd party meshes for still images.
> 
> Of course I *could* buy Poser, Rhino, or any one of several other
> commercial 3D packages, but POV-Ray is free. It would be terrific if
> there were some sort of practical way to accurately deform meshes
> (boning comes to mind in particular), without spending a lot of money
> on some external modeler.
> 

Just like to point out that deforming meshes (meaning translating the
vertices in a certain defined way) is really not much problem in current
pov/megapov.  Just define a vector field in a user defined function or
pigment and use it to translate the vertices.  It will work like displace
warps for patterns.

I haven't used any character modelling packages at all therefore i can't
say much about 'boning' and the things required for that, but looking at
Rune's first proposal i think implementing a transform weighting method
would really be the first step (either in SDL or as a patch) Having this
function limited to meshes would be a major restriction (just imagine
blobs could be nicely 'boned' too)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Rune <run### [at] mobilixnetdk>
> How was this done? One mesh per frame? How long was the animation? And how
> much disc space did it take?

The horse movement was created in Poser. It's cyclical and uses 24 frames.
Each mesh was exported and converted (using the batch procedure of 3DWin).
There was 50 Mb of meshes. The POV procedure loads each mesh and puts it
where it should be. I never finished it for time reasons and the best I did
was a 400 frame animation of the whole herd which is far from perfect. I
plan to redo it with a mocap file anyway.

> Would it have been possible to make the horses run over a height field and
> other such demanding interactions with the surroundings?

Running on a height field can be possible using the trace function. Other
interactions could be simulated within Poser using dummy props and then
exported.

> And yes, I *do* believe quality character animation can be done writing
> numbers in a text editor. With the proper macros of course.

My own *** limited *** experience with animation indicates that it's already
very difficult to do with a GUI, as you need precise visual references to
adjust the speed and movements, and for the most complicated stuff a mo-cap
file becomes necessary. A Povray-only boning system could certainly be
implemented and fun to use but only for a limited number of users in a
limited number of situations (movements that can be described
algorithmically). For starters, I suggest that you try animating a
walking/running dog-like quadruped (not a biped !) using simple cylinders to
see what I mean. And make it a system flexible enough to be adaptable and
usable by other people...

Now, if Povray was able to communicate smoothly with apps providing this
sort of service, that would open very different perspectives.

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

"Nekar Xenos" wrote:
> I think it's a good idea, considering there are so few
> Pov animation entries on IRTC. It might just help to get
> more animations on there.

Exactly, that was one of my considerations too.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Christoph Hormann" wrote:
> Just like to point out that deforming meshes
> (meaning translating the vertices in a certain
> defined way) is really not much problem in current
> pov/megapov.  Just define a vector field in a user
> defined function or pigment and use it to translate
> the vertices.  It will work like displace warps for
> patterns.

While that kind of mesh deformation can be use for very simple deformations,
it definitely can't be used for things like character animation. I'd like to
see you define a pigment or function that deforms a character mesh so that
the right arm bends in this way, the left arm in this, the legs in that way,
and the head looks to the right!

Besides, it doesn't work for smooth meshes.

> just imagine blobs could be nicely 'boned' too

No they couldn't. But bezier pathes could perhaps.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Gilles Tran" wrote:
> The horse movement was created in Poser. It's cyclical and
> uses 24 frames. There was 50 Mb of meshes.

50 MB for just one second of animation seems like a pretty inefficient
solution to me!

> Running on a height field can be possible using the trace function.

Well, didn't mean a smooth flat height field but one with a rather bumpy
ground so each foot have to adapt to the ground...

> Other interactions could be simulated within Poser using
> dummy props and then exported.

Again, I think this works only in a limited extent...

> My own *** limited *** experience with animation indicates
> that it's already very difficult to do with a GUI, as you
> need precise visual references to adjust the speed and
> movements, and for the most complicated stuff a mo-cap
> file becomes necessary. A Povray-only boning system could
> certainly be implemented and fun to use but only for a
> limited number of users

Well, users could choose to animate the bones in a different program and
then export the animation of the bones to an include file. The mesh
deformation in POV-Ray would then be controlled by the bones in that include
file. The advantage here is that it would only require about 10 to 50 lines
of code per character per frame, much much less than exporting a whole mesh
per frame.

I'm sure the proper converter programs would pop up over time.

> in a limited number of situations (movements that can be
> described algorithmically).

Splines are available in POV-Ray.

> For starters, I suggest that you try animating a walking/running
> dog-like quadruped (not a biped !) using simple cylinders to see
> what I mean. And make it a system flexible enough to be adaptable
> and usable by other people...

I've already made a walk and a running cycle for a biped, but not yet for a
quadruped. To make it usable by other people is something I'm working hard
on.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> Besides, it doesn't work for smooth meshes.
> 

No problem with some extra calculations.

There are many cases BTW, where a field based deformation is much more
convenient than something based on transforms.

> > just imagine blobs could be nicely 'boned' too
> 
> No they couldn't. But bezier pathes could perhaps.
> 

What's so different about blobs (the blob component coordinates can be
compared to the mesh vertices)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Rune <run### [at] mobilixnetdk> a écrit dans le message :
> 50 MB for just one second of animation seems like a pretty inefficient
> solution to me!

Absolutely. But nice enough in the present case (and I hope impressive if I
manage to finish it one day).

> I've already made a walk and a running cycle for a biped, but not yet for
a
> quadruped. To make it usable by other people is something I'm working hard
> on.

My point exactly. What I'm suggesting is that this sort of large-scale
proposal would be much more convincing and "saleable" to other people if
you'd do first some sort of feasability study of what you propose and
demonstrate it on a smaller scale. After all, there's an infinity of
features that one would like to find into POV-Ray and I could post one of
them every day, with every detail of how I would like to see them
implemented.

So, making a working, usable include file of a generic (bones only)
quadruped (not biped) walking/running animation would be a first step in
that direction. It will show you the various problems involved, and, if
successful and appreciated by other Povers (not just the "wow cool!"
reaction, I mean something actually used like Chris Colefax' macros are),
will constitute a basis for a larger project that would get developers
interested.

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

"Gilles Tran" wrote:
> What I'm suggesting is that this sort of large-scale
> proposal would be much more convincing and "saleable"
> to other people if you'd do first some sort of
> feasability study of what you propose and demonstrate
> it on a smaller scale.

Quite understandable. That's what I'm working on, I just wanted to seed a
discussion and awareness of the possible potential at an early stage. Then
when I post my animated demonstrations people will already have this in
mind.

> So, making a working, usable include file of a generic
> (bones only) quadruped (not biped) walking/running
> animation would be a first step in that direction.

While I can understand that a quadruped will be a greater challenge, I can't
see why a biped would be about equally useful. But in the long run I'll have
a try with both.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Christoph Hormann" wrote:
> Rune wrote:
> > Besides, it doesn't work for smooth meshes.
>
> No problem with some extra calculations.

Deforming the normals too involves knowing the positions of the accompanying
vertices, after which for each normal at least 4 samples must be taken to
estimate the normal, and then various vcross operations are performed to get
the final result.

While it is possible if the number of normals specified is equal to the
number of vertices, it sure is not a simple operation, and it's extremely
computationally expensive for large meshes. I estimate a deformation of a
smooth mesh would take about six times as long as a deformation of a
non-smooth mesh.

> There are many cases BTW, where a field based deformation
> is much more convenient than something based on transforms.

Sure, but not for character animation which is the primary goal here.

> What's so different about blobs (the blob component
> coordinates can be compared to the mesh vertices)

The surface of a mesh is entirely dependent on the vertices. The surface of
a blob is dependent on many other things than just the center coordinates.
This is also why you can't UV-map a blob.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> a écrit dans le message :
> While I can understand that a quadruped will be a greater challenge, I
can't
> see why a biped would be about equally useful. But in the long run I'll
have
> a try with both.

There have been many bipeds animated successfully in Povray. I even did a
basic walking stick figure in 1993 with Povray 1. So it's difficult, but
it's been done before, at least partially (see the anim "For a claw full of
gold" http://www.irtc.org/anims/2001-01-15.html).
However, I've never seen a Povray-made quadruped trotting or galloping
(which was why I used Poser to do it, BTW). So I guess that solving such a
problem in a way that's appealing to users would be a much better proof of
Povray's ability to support a native, flexible character animation system.

G.
--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

Rune wrote:
> 
> The surface of a mesh is entirely dependent on the vertices. The surface of
> a blob is dependent on many other things than just the center coordinates.
> This is also why you can't UV-map a blob.
> 

Sorry, but i don't see a reason for limiting new, more sophisticated
transformation capabilities (which is what this is all about as far as i
understand from your proposal) to mesh2 objects.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> Sorry, but i don't see a reason for limiting new, more
> sophisticated transformation capabilities (which is what
> this is all about as far as i understand from your
> proposal) to mesh2 objects.

The feature I'm proposing is not a new type of transformation. It is a
deformation. Only objects made of triangles can be deformed this way. Sorry.

More details can be found in the POV-Ray 3.5 documentation
section "9.1.1.11  How can I bend a object?"

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> escribió en el mensaje
news:3bb86a38@news.povray.org...
> No they couldn't. But bezier patches could perhaps.

I got 2 little utilities in my HD that do that with bezier patches.
First you export your bezier patches in the initial position in pov format
Second you export your bezier patches in the final position in pov format
Third the utility creates the meedle frames.
(IIRC you can insert different meedle steps before getting to the final
position).
If you're interested I can do a search thru' my HD and backups to find them.

Anyway, it's a great challenge to make what you're trying to do, but, form
what I've seen from your work, I believe you'll find a solution.

(In Rune we trust ;-)

--
Txemi Jendrix
tji### [at] euskalnetnet
http://www.geocities.com/txemijendrix

Post a reply to this message

"Txemi Jendrix" wrote:
> I got 2 little utilities in my HD that do that with
> bezier patches. First you export your bezier patches
> in the initial position in pov format. Second you
> export your bezier patches in the final position in
> pov format. Third the utility creates the meedle frames.

> If you're interested I can do a search thru' my HD and
> backups to find them.

Thanks for the offer, but that's not quite what I'm after.

> Anyway, it's a great challenge to make what you're
> trying to do, but, from what I've seen from your work,
> I believe you'll find a solution.

Thanks. I hope you're right! ;)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3bb719c3@news.povray.org...
> "ingo" wrote:
> >  Yes, they can be assigned to several vertices, but they
> > don't have to be! Nothing stops you from writing a mesh
> > that specifies a normal per vertex
>
> Ok, but that's rather inefficient.
>
> I think there's plenty of good reasons to implement the feature I've
> proposed.
>
> Is there anybody besides me who thinks it would be a good idea?
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
> POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
> POV-Ray Webring: http://webring.povray.co.uk
>
>

Personally, I would like POVRay to switch to a plug-in architecture.  Where
different functionality could be attained by seperate modules.  Adding more
and more functionality to POVRay simply bloats it.  Those that simply want a
fast single frame raytracer wouldn't have to contend with the added memory
overhead of a animation system built in to it.  Those that want animation
would simply add the animation dlls to the system.

Post a reply to this message

khaver wrote:
> 
> Personally, I would like POVRay to switch to a plug-in architecture.  Where
> different functionality could be attained by seperate modules.  Adding more
> and more functionality to POVRay simply bloats it.  Those that simply want a
> fast single frame raytracer wouldn't have to contend with the added memory
> overhead of a animation system built in to it.  Those that want animation
> would simply add the animation dlls to the system.

Concerning the problems of this you might want to have a look at the 'POV
4 philosophy' thread quite recently in this group.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

khaver <kha### [at] netzeronet> wrote:
: Personally, I would like POVRay to switch to a plug-in architecture.  Where
: different functionality could be attained by seperate modules.

  And how do you make portable then?

  And don't come up with the typical "all OS's have dynamically loaded
libraries" answer. That's not the problem.

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

Post a reply to this message