Re: [Algorithms] Representing Animation Key Frame with Quaternion + Translation Vector

[Florian A. S. <fst...@bl...>]

I've done a system like this in the past for PS2/GC/Wii and it worked
out well for us.  To cope with the potential explosion of combinations
of bone weightings, the palette of weightings required for the mesh was
quantised.  The default setting for entries in the palette was 1.5 times
the number of bones in the original mode, and this got good results
nearly all the time.  

The worst case for this (as with any sort of palletisation) was when
there was a gradient of weightings over a large area.  This case doesn't
occur on a human or animal type model, but can occur on other cases.  To
get around this, the quality could be increased (by changing the size of
the palette) and the artists could also specify verts that be given
greater importance during the quantization process.

The downsides are as have been mentioned on this thread: increase in the
number of meshes.

For hardware that has proper vertex shaders, this technique is probably
not as important, but I have been wondering if you could use a similar
approach to create morph targets without requiring extra meshes by
creating a bone per vert and then quantise down the palette of bones
(this would require a different quantizer from what I mentioned above).

-Florian

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...] On Behalf Of
Jon Watte
Sent: Saturday, 28 June 2008 3:32 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Representing Animation Key Frame with
Quaternion + Translation Vector

Cedric Pinson wrote:
> Hi,
> I was just curious if it's used mostly or not, and why.
>   

I vote for "not," because the CPU work to generate the matrices takes 
more time than the GPU shading work to combine the matrices per vertex. 
And I have better use for the CPU :-)
I don't write code for the more limited or esoteric platforms, though.

Also, NVIDIA apparently recommends using stream-out with scatter to do 
skinning on G80 hardware and up. This means that you store each vertex 
in bones space per bone, and then loop over the bones, and 
multiply-add-accumulate into an output array. Once all bones are 
processed, you take that stream-out and use as a transformed vertex 
array. I believe this is also how Doom III did it, although on the CPU 
instead. The benefit is that you can have certain vertices influenced by

30 bones if you want, and other vertices influenced by only 1, and you 
get no redundant calculation. The draw-back of this method are that you 
store vertices multiple times (so the size grows by your average bone 
influence count), and you require scatter-write, which means it doesn't 
work on most installed hardware (most current PCs, 360 or Wii).

Sincerely,

jw


------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t