[X3D-Ecosystem] [x3d-public] Tests for Blender->X3D exporter utilizing texture transformation and per-vertex colors

[joedwil at earthlink.net]

>  (transforming Blender object's location/rotation/scale exported to X3D animatingTransform.translation/rotation/scale would be my suggestions)
  
First, Please recall that that the hanim import and export need transform,translation/rotation/center/scale 
All four, at least, not to mention scaleOrientation and any other x3d Transform fields. 
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/grouping.html#Transform
  
Joint has some added to std x3d Transform but it is just a special Transform with a couple of added fields.. 
   
Next, please understand that the Blender so called Bone center is never the center of the bone. 
 (hint: unless a bone is a cheerleader's baton), 
The field is coded and animated as the Joint center of the parent Joint as given by the bone begin default location. 
  
Yes, that is really how it works. At some point in the past Blender decided to expose the Transform center detail to the armature author using that empty Transform and illegal by x3d DEF/USE coding.  
  
So, with these two facts in hand we can actually think about exporting from blender true x3d hanim without the extra fake transforms that blender current api apparently needs to accomplish an hanim skeleton using Joint nodes rather than bones as the target authoring and animation interfaces. 
  
This leads to the, to me, obvious that blender should join the big leagues and evolve its archaic skeleton (armature) authoring interface so as to obsolete the "Bone" hierarchy and evolve to the Joint hierarchy. Might as well since under the covers that is how it actually works.  
  
Thanks for all the great work on blender x3d import/export and Best Regards,
Joe
  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20241229/0ccd02a7/attachment.html>