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