[x3d-public] HAnim Blender Exporter review board
Joe D Williams
joedwil at earthlink.net
Fri Oct 13 13:29:31 PDT 2023
>From going through this, I think we see the reason for a standard. We have an authortime and runtime standard so 'it is composable by a human with a text editor' and 'it just runs' meaning nothing out of the ordinary is in the thing. The standard means it can be validated for content and security. The standard means that anything you learn about the topic is not wasted time, because you are learning best accepted practices for structuring data in a way that humans can understand, create, and publish in a private or public web-based environment.
We can see that as the standards-based approach produced by organizations like WWW, Kronos and Web3D Consortium has greatly improved author, producer, provider, and consumer access to realtime anytime, interactive nD+2 content. This all improves when hobby and commercial implementers engage with the standards involved in their product. From the bottom up, there is no doubt we are seeing great advancements for the community by standardization of actual executable structures. It can be pointed out that x3d data structures are completely compatible with these constructions in that x3d user code can be processed to produce those forms, and can import/export directly from authortime/runtime.
> It sounds like one shouldn’t tack on animations in meters to a file in centimeters.
Not only is it should sound like that, but it is actually written like that.
The Humanoid is expected to be produced in human scale, and since we all know or will learn that it is all going to work best when the items that make up the humanoid are drawn in place in human scale using minimum transforms. Please observe that no matter what the authortime coordinate system, the root runtime is the perfectly defined x3d default coordinate system for space and time. Next, we know that no matter what the units authored by the user, the runtime resolution is the same, a floating point value.
So, animations transform one or more values of a node. The basic functionality of the Humanoid, the Joint, Segment, and Site nodes is a Transform. The Transform can include translation, rotation, and scale, relative to the parent system. Experimentation will show that rotations are not affected directly by change of scale and a given rotation will produce the expected motion (provided you know its parent system). Translation, though, will depend on Humanoid parent, Humanoid, and child node scale. If your animation produces translations in units of m, and your Humanoid has been drawn x100 then scaled to fit in human space then the translation may be off by the scaling factor applied to the Humanoid. Your mileage may vary and all you can do is experiment to see.
> How to integrate Blender scenes in different units? Simple answer:Don't. Work it out in blender, then export it. If you get any geometry with points (verts) and/or translations in other than x3d HAnim coordinate space, just move the item to put 0 0 0 between the feet, find the fix everything to 1:1 zero button to draw the item at default meters scale and then output when you get the thing drawn like x3d HAnim wants. No matter what the claim or the tools defaults, any tool with any class can do this. >We would need x3d.py support for angleUnits. Any browser that can do HAnim Part 2 does that. Just know that angleUnits is not a reliable way to define an animation.> Armature
The historic general-purpose term could mean same as HAnim skeleton, or a complete Humanoid, ready for animation.
> - if you want to scale up or down the humanoid to/from centimeters, should the surrounding scene also be scaled up/down to go with it / is the whole scene in cm?
Yes, but why bother? For best most reliable results and best opportunity to reuse, draw the thing for action in X3D HAnim space.
> - if it's for Motion.values, currently freewrl is expecting degrees, so I need to change freewrl, perhaps adding a Motion.angleUnits or .degrees field to allow either. HAnim Appendix D Motion values example was in degrees (as are .bvh files), but the specification doesn't explicitly say degrees or radians for Motion, only mentioning all angles are in radians for the OrientationInterpolator method.
Degrees are junk and should not be allowed in the x3d HAnim user code. Part 2 shows how to convert to axis-angle. Yes, the motion node can work directly in angles but never show it as actual x3d user code. Better to work on allowing quaternion as that is actual recommended code for machine. However axis-angle is much easier to hand author.
Also consider that bvh files might have been generated by mocap, or just by folks using a random skeleton they found or created without any rules. Thus, animation may have been made using keyframes made with snag and drag ik technique using a skeleton that you know almost nothing about. You must discover hierarchy and default before animation pose by experimentation using animations that should have known effect. Anything from bvh is valuable only if can be adapted to HAnim skeleton.
I guess you can tell that I am saying to get the thing working in HAnim space before export. Not (as) reliable to rescale stuffs to fit, even accessories. Its not worth importing to x3d HAnim if you still have to do compensation for transform issues. Sure you can get away with it for awhile until you want to do something that requires a bit of detail.
All Best and Good Luck,
Joe
-----Original Message-----
From: John Carlson <yottzumm at gmail.com>
Sent: Oct 13, 2023 9:47 AM
To: GPU Group <gpugroup at gmail.com>, Joe D Williams <joedwil at earthlink.net>, Katy Schildmeyer KS APPAREL DESIGN <katy at ksappareldesign.com>
Subject: Re: HAnim Blender Exporter review board
Good points, Doug.
It sounds like one shouldn’t tack on animations in meters to a file in centimeters.
Further investigation is required. Perhaps changing the Blender units would work long term, or applying unit conversion to whole scene in the exporter.
How to integrate Blender scenes in different units?
Agreed that I’ve just been focusing on HAnim.
We would need x3d.py support for angleUnits. I’m not sure what’s there.
I guess I’m back to fixing textures instead of Blender exports. I will try validating the final product against input data, perhaps with new code. Or I will work on texture (image, UV) export from Blender. Or I will port Lily to new scheme and see what happens.
Thanks for the review, very helpful.
John
On Fri, Oct 13, 2023 at 8:14 AM GPU Group <gpugroup at gmail.com (mailto:gpugroup at gmail.com)> wrote:
1. Scaling x hard to 'check and approve code' by skim reading snippets.
Does it work for all scenes?
Is it simple (not glitchy)?
- I thought bone.head_local, tail_local were in Armature coords already. And matrix_local might do something similar, for example
armature_space = matrix_local x bone_space. But don't take my word for it -- check blender docs and test
- if you want to scale up or down the humanoid to/from centimeters, should the surrounding scene also be scaled up/down to go with it / is the whole scene in cm?-- if so the scene author can wrap all the scene nodes in a group and scale the group in the transform tab, and Object > apply > Scale
1.b flipZ options depends on what's not working
if the scene animates correctly in blender, then in theory its not a flipZ problem, its a rotation problem.
Export > mocap bvh has some export panel options for XYZ, ZYX etc permutations, and the python code for it has some details
Import > mocap bvh has an option for Y-up and how they deal with it
1.c rotation units in motion data
- if it's for Motion.values, currently freewrl is expecting degrees, so I need to change freewrl, perhaps adding a Motion.angleUnits or .degrees field to allow either. HAnim Appendix D Motion values example was in degrees (as are .bvh files), but the specification doesn't explicitly say degrees or radians for Motion, only mentioning all angles are in radians for the OrientationInterpolator method.
- and/or it could be an option on the export panel
1.d freewrl normal indexes
- I fixed some of those crashes in the last few weeks by testing for null pointer
- do you have version 6.4?
> Gramps hands ..
- that could be a sign something is wrong with the math
On Thu, Oct 12, 2023 at 9:17 PM John Carlson <yottzumm at gmail.com (mailto:yottzumm at gmail.com)> wrote:
1. I am scaling the skeleton according to the obj.matrix_local, perhaps I need to apply full matrix matrix multiplication, or take out the matrix stuff?
+ obj_matrix = obj.matrix_local
+ if obj_matrix is not None:
+ loc, rot, sca = obj_matrix.decompose()
+ rot = rot.to_axis_angle()
+ rot = (*rot[0], rot[1])
+ center = sca * obj.head_local
+ chicenter = sca * obj.tail_local
In addition, I am scaling by units conversion (I may need to swap Y and Z here, need to test. I don't see anything out of the ordinary). I may also need to negate Z.
vec = mathutils.Vector((center[0], center[1], center[2])) # in Blender space
+ center = (vec[0]*lengthUnitConversion, vec[1]*lengthUnitConversion, vec[2]*lengthUnitConversion) # in X3D space
chivec = mathutils.Vector((chicenter[0], chicenter[1], chicenter[2])) # in Blender space
+ chicenter = (chivec[0]*lengthUnitConversion, chivec[1]*lengthUnitConversion, chivec[2]*lengthUnitConversion) # in X3D space
In addition, I am converting units in the Blender animations (no scaling yet), I haven't been able to test this successfully yet. Note Y, Z swap.
+ bone.rotation_mode = 'XYZ'
+ values.append(bone.location[0]*lengthUnitConversion) # location
+ values.append(bone.location[2]*lengthUnitConversion) # location reverse Y and Z for X3D
+ values.append(bone.location[1]*lengthUnitConversion) # location reverse Y and Z for X3D
+ eul = bone.rotation_euler
+ if bpy.context.scene.unit_settings.system_rotation == 'DEGREES':
+ values.append(math.radians(eul.x)) # rotation_euler
+ values.append(math.radians(eul.y)) # rotation_euler
+ values.append(math.radians(eul.z)) # rotation_euler
+ else:
+ values.append(eul.x) # rotation_euler
+ values.append(eul.y) # rotation_euler
+ values.append(eul.z) # rotation_euler
I am adding a normalIndex (FreeWRL needed this):
for i in poly_verts:
ifs.coordIndex.append(i)
+ ifs.normalIndex.append(i)
ifs.coordIndex.append(-1)
+ ifs.normalIndex.append(-1)
# --- end coordIndex
I am unit converting the mesh and negating z:
+ v.co (http://v.co)[0] = v.co (http://v.co)[0]*lengthUnitConversion
+ v.co (http://v.co)[1] = v.co (http://v.co)[1]*lengthUnitConversion
+ v.co (http://v.co)[2] = -v.co (http://v.co)[2]*lengthUnitConversion
Then I am rotating and default scaling the skin (overriding existing scaling):
+ x3dnode.scale = (1, 1, 1)^M
+ x3dnode.rotation = (0, 1, 0, 3.1416)
Taking the skin rotation out leaves Gramps facing backwards.
Gramps hands are slightly wonky during the walk.
Not related, but I'm going to start looking into Rust. Apparently there's a WebGPU package, which can probably be used with either Rust or Node.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231013/6d55410c/attachment-0001.html>
More information about the x3d-public
mailing list