"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

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

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

The vast majority would have a weighting of 1, then...but that 1 will 
only need to be stored once per bone.


> 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.

That would...not be easy to code. You would have to make room for the 
data anyway. If the ID/weight pair method is used, each vertex could 
store an array of IDs of those pairs.
The method you suggest would require all vertices to have 2 pointers, 
one to an array of bone IDs and one to an array of weights, actually 
more memory for the simplest case vertices (you will have to allocate a 
pointer to the array of weights whether you use it or not).

While the weight for the single-bone case isn't needed, because it is 
always 1, it would only have to be stored once for each bone, so the 
memory usage would be quite low for meshes with lots of single-bone 
vertices. Say n vertices share a single bone: storing one bone-ID/weight 
pair, n pointers to a pair ID, and a n ID's (one of each per vertex) is 
less than storing n bone IDs, n pointers to those IDs, and n unused 
pointers to a nonexistent weight value. One wastes 1 float value, the 
other wastes n pointers to float values.


> 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 was thinking all the information would be stored, and the fields would 
simply initialize the data...this would make cleaner code and be a 
little (maybe a lot) faster. The information wouldn't have to exist for 
long (it wouldn't be needed in the rendering stage, just in the parse 
stage), and I don't think it will be a lot anyway (an average of a 
little over 1 ID and 1 pointer per vertex, plus lists of bones and 
bone-ID/weight pairs).

-- 
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

Let me see if I understand your storing system.
There's an array full of bone-id/weight pairs with no duplicates.
Each element in the array stores exactly one bone-id/weight pair.
For each vertex in the mesh there's one or several pointers bone-id/weight
pairs.
Is that right?

What I don't understand is how it makes sense to store individual weights.
The weights are *relative to other weights* so storing just one
bone-id/weight pair at a time makes no sense.
Or does it? Can you explain?

> I was thinking all the information would be stored, and
> the fields would simply initialise the data...this would
> make cleaner code and be a little (maybe a lot) faster.

Yes, maybe that is better.

> The information wouldn't have to exist for long (it wouldn't
> be needed in the rendering stage, just in the parse stage)

I know! I already mentio- ... Never mind.

Anyway, the data would be stored as a part of the scene/include file, just
like mesh vertices are, right? But how would the data be generated?

We agree that fields could initialise the data, but how would this be done?
External utility? I don't think that's a good idea.

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 <3a6227e4$1@news.povray.org>, "Rune" 
<run### [at] inamecom> wrote:

> Let me see if I understand your storing system.
> There's an array full of bone-id/weight pairs with no duplicates.
> Each element in the array stores exactly one bone-id/weight pair.
> For each vertex in the mesh there's one or several pointers 
> bone-id/weight pairs.
> Is that right?

Close. There is also an array of bones themelves, the bone IDs are just 
indexes for this array. And each vertex has an array of indexes for the 
array containing the bone ID/weight pairs.


> What I don't understand is how it makes sense to store individual 
> weights.
> The weights are *relative to other weights* so storing just one
> bone-id/weight pair at a time makes no sense.
> Or does it? Can you explain?

The weights for each vertex will always total to 1, is that what you 
mean?
The weight value determines the influence of a specific bone, right? So 
it makes sense to pair them up..."xx% of the influence comes from y 
bone". There will be duplicates in this information, especially when 
several vertices belong to one bone and only that bone, so those 
duplicates can be eliminated by making a separate list of data pairs and 
referring to the pairs in that list by ID number.
I'm not really certain what you are asking...each vertex is affected by 
each bone that "owns" it by a specific amount depending on proximity to 
that bone and other bones that "own" it, right? POV would calculate the 
effect of each bone, and add the bone ID and weight to the array for 
that vertex.


> I know! I already mentio- ... Never mind.

Er, ok. :-)


> Anyway, the data would be stored as a part of the scene/include file, 
> just like mesh vertices are, right? But how would the data be 
> generated?
> 
> We agree that fields could initialise the data, but how would this be 
> done?
> External utility? I don't think that's a good idea.

No, it would be done in the parsing stage. The bone and vertex 
information would be parsed in, and the bone fields would be used to 
"fill in" the unspecified weights. The data would then be passed to the 
code that actually moved the vertices, which won't care *how* the data 
was generated. That bit of code (and the one-field code) may be useful 
somewhere else separately, no real reason to make them integral with 
each other. It should also be a little easier to maintain.
From the user's perspective, it just lets them specify everything, 
nothing, or just a few points, while POV automatically computes anything 
they leave out with no extra syntax.

-- 
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

Let's see if we understand each other so far.

In the scene file there will be a block of bone information.
Maybe like this (like you suggested):

mesh {
   boned_mesh {
      mesh_data...
      bone_data...
   }
}

Or maybe like this (as I find more logic):

mesh {
   mesh_data...
   bone_deform {bone_data...}
}

A bone consists of an ID number, two times two points and two vectors and a
radius and a strength. Maybe like:

bone_deform {
   bone {
      ID-number,
      home_end1, home_dir1, home_end2, home_dir2,
      curr_end1, curr_dir1, curr_end2, curr_dir2,
      radius, strength
   }
   bone {...}
}

The fields defined by the strengths and radii of the bones will control how
much each vertex is influenced by each bone.

> From the user's perspective, it just lets them specify everything,
> nothing, or just a few points, while POV automatically computes
> anything they leave out with no extra syntax.

Yes, the user can specify the weights for individual vertices to gain
greater control. But what would the syntax for this be?

bone_deform {
   weights {
      ???
   }
}

One way or the other we will end up having one weight for each bone for each
vertex. This information may be stored in a compact way as we've discussed
earlier.

This information will be used to deform the mesh by moving the vertices
according to the bones and the weights. After the deformation has happened,
all the bone information can be deleted again. In the rendering stage the
mesh will render just like any other mesh.

As you see, the only real question I have now is about the user-defined
weight data. But this is only provided that we agree about all the rest,
which I doubt... :)

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

Suddenly the discussion stopped and I wondered why.

I wrote:
> As you see, the only real question I have now is about the
> user-defined weight data. But this is only provided that we
> agree about all the rest, which I doubt... :)

Oops, I realise now that this could be completely misunderstood!

What I meant was that in case we didn't agree about the rest, I would have
not just one, but many questions left. I certainly *didn't* mean that I only
wanted to discuss further if we agreed!

So if you have anything to say, I'd be glad to continue the discussion :)

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 <3a644a6a@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Oops, I realise now that this could be completely misunderstood!
> 
> What I meant was that in case we didn't agree about the rest, I would 
> have not just one, but many questions left. I certainly *didn't* mean 
> that I only wanted to discuss further if we agreed!

That wasn't it...yesterday was Monday. School. ;-)

-- 
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

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

> Let's see if we understand each other so far.
> 
> In the scene file there will be a block of bone information.
> Maybe like this (like you suggested):
...snip...

I would prefer the boned_mesh syntax, because it will let you specify 
data along with each vertex instead of separating it all out into a 
deform:
boned_mesh {
    bone_list {bone{} bone{} ...}
    triangle {P1, P2, P3// normals when smooth_triangle is used
        bones {[Bone1, Weight] [Bone2, Weight] [Bone3...}
        // the Weight values would be optional
    }
}

And this would be useable as a independant object and as a "mix in" for 
meshes. (This is a separate idea I have been thinking of...letting you 
mix triangle-based objects like height fields or bezier patches along 
with the triangles.)
A more compact syntax for machine generation could also be added 
(analogous to mesh2).


> A bone consists of an ID number, two times two points and two vectors 
> and a radius and a strength. Maybe like:
> bone_deform {
>    bone {
>       ID-number,
>       home_end1, home_dir1, home_end2, home_dir2,
>       curr_end1, curr_dir1, curr_end2, curr_dir2,
>       radius, strength
>    }
>    bone {...}
> }
> 
> The fields defined by the strengths and radii of the bones will 
> control how much each vertex is influenced by each bone.

That is something I haven't thought much about...the simplest way would 
be to let the user specify the ID number, but I would prefer a cleaner 
method letting the user name each bone (the names would only be valid 
within the boned_mesh block, of course) and refer to them by name, the 
names would then be translated to ID numbers by the parser. I don't know 
how to implement this, though...


> This information will be used to deform the mesh by moving the 
> vertices according to the bones and the weights. After the 
> deformation has happened, all the bone information can be deleted 
> again. In the rendering stage the mesh will render just like any 
> other mesh.

Exactly.


> As you see, the only real question I have now is about the user-defined
> weight data. But this is only provided that we agree about all the rest,
> which I doubt... :)

Well, I can't think of a good way to do it with the bone_deform 
syntax...maybe specify the weights in the same order as the triangles, 
but that seems to be a really ugly and problem-prone solution.

-- 
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 would prefer the boned_mesh syntax, because it will let
> you specify data along with each vertex instead of separating
> it all out into a deform

Ok.

> I would prefer a cleaner method letting the user name each bone

Fine with me.

I feel we have reaches a point where our exchanging of thoughts and ideas
has resulted in us agreeing about mostly everything about the bone feature.
That's nice!

So now we just need someone to code it. Hehe...

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

"Chris Huff" wrote:
> yesterday was Monday. School. ;-)

:)

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