 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] mobilixnet dk> 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
|
|
| |
| |
|
|
|
|
| |
|
|
