"Chris Huff" wrote:
> "Rune" wrote:
> > I thought this method could work for meshes only, since
> > it would do moving of vertices.
>
> Then it should probably be a specialized feature of meshes,
> not of a "deform" feature...

Whatever. Call it what you want... :)

> hmm, am I the only one who has noticed there seems to
> be a lot more mesh ideas/patch work being done lately?

And you think it's a coincidense?

> > The relative type would be useful for things like bone
> > systems, where every part of the mesh is deformed, and
> > the original locations of the vertices should not have
> > any affection at all. In this case you would want to
> > make sure that your entire mesh is enclosed by the
> > fields.
>
> It might be a better idea to just implement a bone system.
> Maybe a new kind of mesh..."boned_mesh"...would be the
> easiest way to do things.

I don't think that's a good idea. You said to me recently that you preferred
the flexible feature that could be used for many things over the specialized
feature. And I agree. To create a whole new object type just to be able to
pose figures seems odd to me.

> I'm not sure the "deform fields" idea will be very easy
> to use...

There are a whole lot of features in POV-Ray and MegaPov that are not very
easy to use. Usually people learn to use it eventually, especially with the
help from each other.

> but inverse kinematics features could be worked into a
> boned mesh feature,

I've been working with inverse kinematics for a while now, and if there's
one thing I've learned, it is that no general all-round IK solution can be
made. You can make so many different IK systems with different ways of
handling things. One system would never be satisfactory for all tasks. Some
3D software has acceptable solutions, but then, they have GUI too, and that
a completely different situation.

> > I still don't know what would be the best way to define
> > the fields with. Patterns, blob-like fields, maybe both
> > options, or maybe something entirely different?
>
> Patterns would be the most flexible way. Remember, you can
> make blob-like fields with a pattern, too. You might even
> be able to use the blob pattern. :-)

You're a bit late. I already mentioned that in my first message.
Did you bother to read that message?

:)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Tom Melly" wrote:
> "Warp" wrote:
>
> >   Usually people ask somethink like "is it possible
> > to _simulate_ motion blur with povray?".
>
> ...as opposed to hurling the monitor across the room
> or firing it out of a cannon?

LOL!

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a5de3eb@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > It might be a better idea to just implement a bone system.
> > Maybe a new kind of mesh..."boned_mesh"...would be the
> > easiest way to do things.
> 
> I don't think that's a good idea. You said to me recently that you 
> preferred the flexible feature that could be used for many things 
> over the specialized feature. And I agree. To create a whole new 
> object type just to be able to pose figures seems odd to me.

The flexibility argument is *why* I think a new object type would be 
useful...you could probably get more flexibility with an object designed 
for this purpose. There is potentially a lot of new data for this thing 
that wouldn't really fit with ordinary meshes.
However, that data is really only used in the parsing stage...maybe 
something that will generate a mesh:
mesh {
    // usual mesh stuff...triangles, etc
    boned_mesh {vertex and bone data}
}
The best of both worlds...it could let you define "ownership" of each 
individual vertex, or use "deformation fields" to do the job, and would 
result in a mesh, and not save irrelevant data or interfere with the 
existing mesh syntax. The boned_mesh keyword would take a mesh, deform 
it to fit the bones, and add it to the containing mesh. Similar to my 
idea of letting you add tesselations and triangle-based objects to a 
mesh...you would lose some object-specific optimizations when you use 
this feature, but could combine whatever objects you want, and use new 
mesh features on them.
mesh {
    tesselate {}
    height_field {}
    bicubic_patch {}
    mesh {}
    boned_mesh {}
}


> > but inverse kinematics features could be worked into a
> > boned mesh feature,
> 
> I've been working with inverse kinematics for a while now, and if 
> there's one thing I've learned, it is that no general all-round IK 
> solution can be made. You can make so many different IK systems with 
> different ways of handling things. One system would never be 
> satisfactory for all tasks. Some 3D software has acceptable 
> solutions, but then, they have GUI too, and that a completely 
> different situation.

The syntax would probably not be very useable anyway...better to add a 
general "bones" feature and let macros/includes do the IK.


> > Patterns would be the most flexible way. Remember, you can
> > make blob-like fields with a pattern, too. You might even
> > be able to use the blob pattern. :-)
> 
> You're a bit late. I already mentioned that in my first message.
> Did you bother to read that message?

Ouch... :-)
I did, but I must have misinterpreted what you were saying...I thought 
you meant blob-like fields controlled by something else, not the blob 
pattern.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> The flexibility argument is *why* I think a new object
> type would be useful...

> However, that data is really only used in the parsing
> stage...maybe something that will generate a mesh:
> mesh {
>     // usual mesh stuff...triangles, etc
>     boned_mesh {vertex and bone data}
> }
> The best of both worlds...it could let you define
> "ownership" of each individual vertex, or use
> "deformation fields" to do the job, and would result
> in a mesh, and not save irrelevant data or interfere
> with the existing mesh syntax.

Sounds better.

> The syntax would probably not be very useable anyway...
> better to add a general "bones" feature and let
> macros/includes do the IK.

I agree.

To define "ownership" of each individual vertex is exactly what I had been
thinking about. However, several bones should be able to own the same
vertex, controlled by weights. That would be a huge amount of data to
generate and to store. That's why I talked about letting strengths control
the weights, so calculations can be done on the fly and don't have to be
stored. This will probably be slower though than just reading stored data,
and identical calculations would have to be done for every frame, which is
kind of a waste. Experiments should be done to find the most advantageous
method.

Anyway, how would you define a bone? I've thought of it as a line between
two points. A field with a user-defined strength and radius would surround
this line segment and affect vertex points and normals near it. They would
be transformed by a transformation assigned to that bone. But actually it
would be better to have *two* transformations assigned to each bone. One for
each end. That's because in reality when we twist our limbs (for example our
wrist), the twisting actually occurs along the whole limb and not just at
the joints. So there should be two transformations assigned to each bone, or
maybe one transformation and one twist amount.

Have you had any thoughts on how a bone would work? I'd be very interested
in this.

> > You're a bit late. I already mentioned that in my
> > first message. Did you bother to read that message?
>
> Ouch... :-)
> I did, but I must have misinterpreted what you were
> saying...

Never mind! It was a joke kind-of... :)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a607978@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> To define "ownership" of each individual vertex is exactly what I had 
> been thinking about. However, several bones should be able to own the 
> same vertex, controlled by weights. That would be a huge amount of 
> data to generate and to store.

I was thinking of having each bone have an ID number. Maybe limit the 
number of bones to 255... So for each vertex, you just have to store a 1 
byte number and a floating point weight value for each bone that affects 
it. (ID 0 would be "no bone") Even the ID/weight pairs would be 
identical among many vertices, so they could share them. (there would be 
many vertices that only belong to one bone)


> That's why I talked about letting strengths control the weights, so 
> calculations can be done on the fly and don't have to be stored. This 
> will probably be slower though than just reading stored data, and 
> identical calculations would have to be done for every frame, which 
> is kind of a waste. Experiments should be done to find the most 
> advantageous method.

Also, how do you decide which bone affects the vertices when the fields 
intersect? I think this method would have problems individually 
controlling things like an arm resting next to a flexing leg.


> Anyway, how would you define a bone? I've thought of it as a line 
> between two points. A field with a user-defined strength and radius 
> would surround this line segment and affect vertex points and normals 
> near it. They would be transformed by a transformation assigned to 
> that bone. But actually it would be better to have *two* 
> transformations assigned to each bone. One for each end. That's 
> because in reality when we twist our limbs (for example our wrist), 
> the twisting actually occurs along the whole limb and not just at the 
> joints. So there should be two transformations assigned to each bone, 
> or maybe one transformation and one twist amount.

I was actually thinking of defining them with 4 points: two "home 
position" points and two "current position" points, and POV would 
compute the transformations. That should make things very easy to 
define. Maybe some kind of orientation vector would also be useful, so 
you could have a twisting from bone to bone, but that could probably be 
emulated with multiple parallel bones.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> I was thinking of having each bone have an ID number.
> Maybe limit the number of bones to 255...

That would be enough in most cases but eventually people would complain over
it like they currently do with the limit for color_maps.

> So for each vertex, you just have to store a 1 byte number
> and a floating point weight value for each bone that affects
> it. (ID 0 would be "no bone") Even the ID/weight pairs would be
> identical among many vertices, so they could share them. (there would be
> many vertices that only belong to one bone)

For a high quality mesh wouldn't that be a lot of data indeed?
(I'm not saying it is, I'm just asking.)

> how do you decide which bone affects the vertices when the
> fields intersect?

The fields would have S-curved strengths like blob components. For each
vector all weights would be adjusted to add up to 1 (or 100%).

> I think this method would have problems individually
> controlling things like an arm resting next to a flexing leg.

In the "home pose" limbs not affecting each other would have to be separated
with a little distance between them. For example the home pose could be
designed with the arms going to the sides instead of downwards. It would not
always be a perfect solution though.

I think the best approach is a combination of both methods (storing weights
and calculating weights based on fields). First the fields "roughly"
determine all the weights; then the individual weights can be adjusted and
fine-tuned by the user or by some tool.

I've read about a bone tool that used a similar approach. First fields were
used to assign all weights, then the user could adjust those weights. Seems
sensible.

> > Anyway, how would you define a bone?
>
> I was actually thinking of defining them with 4 points: two "home
> position" points and two "current position" points, and POV would
> compute the transformations.

Two points can't define an object's alignment in space. At least three
points are needed. With four points the twisting can be stored too. That
would be 4 points for the "home position" and 4 points for the current
position. However, the points for the current position doesn't have to be
stored, as they are only relevant for the current frame.

The 4-point alignment system is better than my idea with 2 matrix
transformations, as it's much more effective. The reason I thought of
matrixes is because that would be my own approach if I were to make a bone
system in POV-script. Actually my recent matrix question in p.a-u was about
this. I would use an inverse matrix for the "home pose" and then a forward
matrix for the "current pose".

> That should make things very easy to define. Maybe some kind of
> orientation vector would also be useful, so you could have a
> twisting from bone to bone, but that could probably be emulated
> with multiple parallel bones.

That seems to be an awkward way of doing it. When posing a figure it's
*always* relevant how the limbs are aligned. You can't just specify the
locations of the limbs and then hope they're facing in the right direction.
Go for two points plus two orientation vectors; that's the most sensible
approach.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a60e9e1@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > Maybe limit the number of bones to 255...
> 
> That would be enough in most cases but eventually people would 
> complain over it like they currently do with the limit for 
> color_maps.

Well, the memory requirements of the ID number would increase by 1 byte 
(I don't think people will complain about ~64K bones any time soon).


> For a high quality mesh wouldn't that be a lot of data indeed?
> (I'm not saying it is, I'm just asking.)

Yes, but much less than a bone ID and weight per vertex. Remember that 
as the number of vertices increases, the number of vertices that can 
share the same information also increases, so the extra storage could be 
a little over 2 extra bytes per vertex on average. Much less than 
per-vertex textures, for example.


> > how do you decide which bone affects the vertices when the
> > fields intersect?
> 
> The fields would have S-curved strengths like blob components. For each
> vector all weights would be adjusted to add up to 1 (or 100%).

That is what I had assumed.


> > I think this method would have problems individually
> > controlling things like an arm resting next to a flexing leg.
> 
> In the "home pose" limbs not affecting each other would have to be 
> separated with a little distance between them. For example the home 
> pose could be designed with the arms going to the sides instead of 
> downwards. It would not always be a perfect solution though.

True, it isn't as bad as I had thought...


> I think the best approach is a combination of both methods (storing 
> weights and calculating weights based on fields). First the fields 
> "roughly" determine all the weights; then the individual weights can 
> be adjusted and fine-tuned by the user or by some tool.
> 
> I've read about a bone tool that used a similar approach. First 
> fields were used to assign all weights, then the user could adjust 
> those weights. Seems sensible.

This would seem to be a modeller feature used to set up the bone 
data...it could be used to set "default" values in POV, but you should 
be able to override those values. It could be something that happens 
"behind the scenes" when that data isn't specified.


> > I was actually thinking of defining them with 4 points: two "home
> > position" points and two "current position" points, and POV would
> > compute the transformations.
> 
> Two points can't define an object's alignment in space. At least three
> points are needed. With four points the twisting can be stored too. That
> would be 4 points for the "home position" and 4 points for the current
> position. However, the points for the current position doesn't have to be
> stored, as they are only relevant for the current frame.

But we aren't defining an object's alignment. And some information could 
be inferred from the vertex's position relative to the bone's initial 
position...I think. Maybe. Anyone who actually knows something about the 
algorithms behind this stuff is welcome to chip in... ;-)


> That seems to be an awkward way of doing it. When posing a figure 
> it's *always* relevant how the limbs are aligned. You can't just 
> specify the locations of the limbs and then hope they're facing in 
> the right direction.
> Go for two points plus two orientation vectors; that's the most sensible
> approach.

I think this would be needed to do joints correctly anyway...when you 
rotate your arm, your elbow doesn't slide like a ball joint, your whole 
upper arm twists around the bone.
However, what should the orientation vectors be? Unit-length vectors 
indicating direction (maybe non-unit length to indicate some weighting 
value?), or a position vector indicating a point next to the bone?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
> Well, the memory requirements of the ID number would increase
> by 1 byte (I don't think people will complain about ~64K bones
> any time soon).

That's what I was thinking of too. :)

> > For a high quality mesh wouldn't that be a lot of data
> > indeed? (I'm not saying it is, I'm just asking.)
>
> Yes, but much less than a bone ID and weight per vertex.

But isn't that what we're talking about? I mean, sure optimisations could be
done, but we're talking about a bone ID and weight per vertex, as opposed to
field-based weights, right?

> > In the "home pose" limbs not affecting each other would
> > have to be separated with a little distance between them.
>
> True, it isn't as bad as I had thought...

What? When? Why?

> > I've read about a bone tool that used a similar approach.
> > First fields were used to assign all weights, then the user
> > could adjust those weights. Seems sensible.
>
> This would seem to be a modeller feature used to set up the
> bone data...it could be used to set "default" values in POV,
> but you should be able to override those values. It could be
> something that happens "behind the scenes" when that data
> isn't specified.

That's what I meant. You should be able to specify weights for just some of
the vertices, and for the rest of the vertices the fields would be used to
assign "default values".

> > Two points can't define an object's alignment in space.
>
> But we aren't defining an object's alignment.

Yes we are! That's what posing a character is all about!
Ask anybody who has posed a figure if it's enough to specify where the hand
is, or if it is also necessary to specify in which direction the palm is
facing.

> And some information could be inferred from the vertex's
> position relative to the bone's initial position...I think.

NO! These must be completely independent of each other!
If you rotate a whole pose 180 degrees its alignment relative to the home
pose is different, but that shouldn't make any difference! The home pose and
the current pose could be miles apart from each other and it should still
work.

> Maybe. Anyone who actually knows something about the
> algorithms behind this stuff is welcome to chip in... ;-)

I've worked a lot with things like this, although only in POV-script. I feel
I know something about it.

> > Go for two points plus two orientation vectors; that's
> > the most sensible approach.
>
> I think this would be needed to do joints correctly anyway...
> when you rotate your arm, your elbow doesn't slide like a
> ball joint, your whole upper arm twists around the bone.

As I said earlier. :)

"That's because in reality when we twist our limbs (for example
our wrist), the twisting actually occurs along the whole limb
and not just at the joints."

> However, what should the orientation vectors be? Unit-length
> vectors indicating direction

That's what I thought.

> (maybe non-unit length to indicate some weighting value?),

No, those two things have little to do with each other, so I think it's not
a good idea.

> or a position vector indicating a point next to the bone?

This is basically the same as the unit-length idea isn't it? I go for unit
lengths.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a6190cf@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > Yes, but much less than a bone ID and weight per vertex.
> 
> But isn't that what we're talking about? I mean, sure optimisations 
> could be done, but we're talking about a bone ID and weight per 
> vertex, as opposed to field-based weights, right?

But the bone ID and weight can be packaged into one piece of 
information. The vast majority of vertices will belong to a single bone 
and use the same weight, so the bone-ID/weight pairs can be kept in an 
array (with no duplicates) and accessed with ID numbers, so all you have 
to store per-vertex is a couble data-ID numbers (usually one, only more 
than one ID when multiple bones influence the vertex), and separately an 
array of bones, and an array of bone-ID/weight pairs. The total memory 
usage for an ordinary use of this feature will be far less than a list 
of bone-ID/weight pairs for each vertex.


> > True, it isn't as bad as I had thought...
> 
> What? When? Why?

I had been thinking there would be problems when the bone fields moved 
and intersected each other, but they wouldn't...


> > I think this would be needed to do joints correctly anyway...
> > when you rotate your arm, your elbow doesn't slide like a
> > ball joint, your whole upper arm twists around the bone.
> 
> As I said earlier. :)
> 
> "That's because in reality when we twist our limbs (for example
> our wrist), the twisting actually occurs along the whole limb
> and not just at the joints."

Hey, it was late, I was tired. :-)


> > (maybe non-unit length to indicate some weighting value?),
> 
> No, those two things have little to do with each other, so I think 
> it's not a good idea.

After more thought, this value wouldn't be necessary...


> > or a position vector indicating a point next to the bone?
> 
> This is basically the same as the unit-length idea isn't it? I go for 
> unit lengths.

One could be calculated from the other, the same information is being 
specified, but one might be easier to use than the other. Don't want 
people forced to use macros so they can input the data the way they 
want...but unit-length vectors seem to make more sense.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> The vast majority of vertices will belong to a single bone
> and use the same weight,

The weights are relative, so vertices belonging to one bone only means that
the weight of that bone is 100%.

> so the bone-ID/weight pairs can be kept in an array (with
> no duplicates) and accessed with ID numbers, so all you
> have to store per-vertex is a couble data-ID numbers
> (usually one, only more than one ID when multiple bones
> influence the vertex), and separately an array of bones,
> and an array of bone-ID/weight pairs.

I don't understand that method. Since the weight of a bone is relative to
the weights of other bones, it does't make sense to single out individual
bone-ID/weight pairs. Besides, the probability that several vertices share
the same bone-ID/weights is minimal except in the case where a vertex
belongs to just one bone. Perhaps this method could be used:

For vertices that are influenced by more than one bone, store all relevant
bone-ID/weight pairs for that vertex. For vertices that are influenced by
one bone only, just store the bone-ID. The weight is always 100% in those
cases, so it doesn't have to be stored.

Also, some vertices could have no bone information at all. In that case the
field-weights would be used. This would have the advange that much less bone
data would have to be stored, and the disadvantage that the field-based
weights would have to be calculated for every frame. I don't know if that
would be slow?

> I had been thinking there would be problems when the bone
> fields moved and intersected each other, but they wouldn't...

Correct.

> but unit-length vectors seem to make more sense.

I agree.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message