[x3d-public] Can you get this X3D animation imported into Blender?
John Carlson
yottzumm at gmail.com
Fri Jun 7 17:11:49 PDT 2024
As I thought I said, the HAnim examples without animation is pretty useless
to me right now. Small examples with animation are helpful. If someone
has a magical type that does HAnim without Blender bone types and/or
Objects in Blender, fess up.
There’s no issue that i know of loading HAnim into a
matrix+transform+object hierarchy statically. The issue right now is
getting animations right. We have a hierarchy, now let’s get the numbers
right.
One thing that might work is attaching MESH objects to EMPTY objects to
Blender bones. But we’re currently focusing on MESH and EMPTY objects.
Blender bones will be optional in my plan.
John
On Fri, Jun 7, 2024 at 4:55 PM Joe D Williams <joedwil at earthlink.net> wrote:
> > Major point: both Blender bones and Skeleton as Transforms should be
> supported for maximum flexibility. What are your thoughts?
>
>
>
> Treat that model as it should have been treated years ago and abandon it.
>
> That is just a simplified convention they adopted in days of yore
> duplicating mechanical armature and making stop motion videos with no or
> minimum computer thus should be updated to use terminology and hierarchy of
> x3d hanim.
>
> Number 1 is creating fullhanim skeleton by using the blender gui or by
> importing the minimum skeleton I last sent into blender then adjusting that
> data to be able to export to x3d.
>
> Then a user can use the example hanim to start with.
>
> The way we expose the hanim skeleton hierarchy of Joint, Segment, Site is
> simply to create the hierarchy with names that can be recognized and
> organize a system of data for export to x3d.
>
>
>
> So, recall that if they talk bone orientation, it is the same as joint
> rotation and vertex weights by bone is same as weights by Joint, when
> rigged correctly. Same for all, even Unity, because it is a just better way
> to deal with details. Under the covers the data is the same
>
>
>
> The mission is to update blender to hamin from their archaic current
> abstractions to terms and structures of x3d hanim, or, alternately, get
> tools like castle, x3dom, xcite, freewrl and others to become more than
> just a player and add some even simple ways to create and edit the skeleton
> and geometry and animations and work more directly with authors to create a
> complete x3d scene. A great example of the old days was viz3d and flux and
> BS Content studio. The x3d sai is capable of producing a native x3d
> authoring tool.
>
>
>
> Thanks,
>
> Joe
>
>
>
>
>
> .
>
>
>
> -----Original Message-----
> From: John Carlson <yottzumm at gmail.com>
> Sent: Jun 6, 2024 1:59 PM
> To: GPU Group <gpugroup at gmail.com>, Joe D Williams <joedwil at earthlink.net>
> Cc: Katy Schildmeyer KS APPAREL DESIGN <katy at ksappareldesign.com>, X3D
> Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: Can you get this X3D animation imported into Blender?
>
>
> Sorry TL;DR. Major point: both Blender bones and Skeleton as Transforms
> should be supported for maximum flexibility. What are your thoughts?
>
> Replying to Joe:
>
> Understood. AFAIK, I still need blender bones to export weights right
> now, but Blender bones only provide for Joints, not segments or sites (can
> I attach EMPTYs to Blender bones in a particular mode?). I will
> experiment with attaching weights to EMPTYs (joints), then on export, I
> will move weight detection from Blender bones to EMPTYs, we can do limited
> mapping on export, but asking someone to map an entire LOA4 skeleton is
> unrealistic. I don’t even like LOA1-LOA2 in VRM and BVH. Such
> user-specified mapping should be saved for reuse. I can already do MoMask
> BVH joint mapping on export (but not “End Site” yet). We probably won’t be
> able to save HAnim to VRM skeletons, and I think that USDSkel may do
> armature/bones as well, so I’m not seeing X3D to USD Skel particularly
> working. *I think Doug suggested a separate skeleton mapping app*,
> perhaps this feasible. It’s just not realistic with glTF files exported to
> 8GB-14GB X3D files 200 times the size of a Blender file.
>
> The good news is, I got small Transform hierarchies import mostly working
> in Blender with matrix_local and translation. Now to follow through with
> centers and HAnim. Moving like molasses, but with simple examples, things
> are easier and moving faster without waiting years for import and tons of
> logging.
>
> *Katy can comment on rigging and armature in Blender, *as what might be
> missing if we don’t import Blender bones, this may severely impact the
> apparel workflow in Blender.
>
> *Most likely, both paths should be supported.* I hope you are in
> agreement. Perhaps separating out the import/export into separate addons
> would make decisions easier.
>
> Your additional thoughts are welcome.
>
> On Thu, Jun 6, 2024 at 2:48 PM Joe D Williams <joedwil at earthlink.net>
> wrote:
>
>> > Can we use the same transform code in Blender for both Transform and
>> HAnim?
>>
>>
>>
>> Yes, if blender transform operation can use 'center', which Joint needs.
>> Just name the objects so the Humanoid, Joint, Segment, Site transforms can
>> be transcoded at export into into HAnim hierarchy.
>>
>> Joe
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: John Carlson <yottzumm at gmail.com>
>> Sent: Jun 6, 2024 5:03 AM
>> To: Joe D Williams <joedwil at earthlink.net>
>> Cc: Katy Schildmeyer KS APPAREL DESIGN <katy at ksappareldesign.com>, X3D
>> Graphics public mailing list <x3d-public at web3d.org>
>> Subject: Re: Can you get this X3D animation imported into Blender?
>>
>>
>> Okay, Joe. Now to get this working in Blender, since you’ve confirmed
>> the behavior. Thanks!
>>
>> Can we use the same transform code in Blender for both Transform and
>> HAnim?
>>
>> John
>>
>> On Thu, Jun 6, 2024 at 5:35 AM Joe D Williams <joedwil at earthlink.net>
>> wrote:
>>
>>> Hi John,
>>>
>>>
>>>
>>> You sent this:
>>>
>>>
>>>
>>> <Transform DEF="TransformRoot1" center="0 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> <Transform DEF="TransformTargetParent1" center="4 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> <Transform DEF="TransformTargetChild1" center="8 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> </Transform>
>>> </Transform>
>>> </Transform>
>>>
>>>
>>>
>>> Not shown here is the interpolator that sends rotations to both Parent
>>> and Child Transforms
>>>
>>> For this animation code you sent this did exactly what it should have
>>> done.
>>>
>>> The boxes start at 0 0 0 then are swept along the axis according to the
>>> Parent and Child Transform nodes animation input.
>>>
>>> Note that the initial position of all three boxes is 0 0 0, then they
>>> move along the radius from where you set the parent centers.
>>>
>>>
>>>
>>> Please have a look at this:
>>>
>>>
>>>
>>> First, slight change from what you sent.
>>>
>>> Again, a important understanding is that "center" value of the Transform
>>> represents the center of rotation of that Transform, and may have nothing
>>> much to do with the value for translation, which is 0 0 0 for the parent
>>> Transform for each Shape.
>>>
>>>
>>>
>>> <Transform DEF="CenterRoot1" center="0 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> <Transform DEF="CenterParent1" center="4 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> <Transform DEF="CenterChild1" center="8 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> </Transform>
>>> </Transform>
>>> </Transform>
>>>
>>>
>>>
>>> So again, all Shapes start at 0 0 0 then are swept through the arc
>>> defined by each parent Transform center.
>>>
>>>
>>>
>>> This version operates like the hanim model.
>>>
>>> The parent Transform is a "Joint" with center defined, then the Shape
>>> has its own Transform to place it at the parent center value.
>>>
>>> (The first center="0 2 0" translation='0 2 0' just moves the is example
>>> up above the first example.)
>>>
>>>
>>>
>>> <Transform DEF="TransformRoot2" center="0 2 0" translation='0 2 0'>
>>> <Transform DEF="MoveToCenterRoot" translation="0 2 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> </Transform>
>>> <Transform DEF="CenterTargetParent2" center="4 0 0">
>>> <Transform DEF="TranslateTargetParent2" translation="4 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> </Transform>
>>> <Transform DEF="CenterTargetChild2" center="8 0 0">
>>> <Transform DEF="TranslateTargetChild2" translation="8 0 0">
>>> <Shape>
>>> <Box size='0.5 0.5 0.5'/>
>>> </Shape>
>>> </Transform>
>>> </Transform>
>>> </Transform>
>>> </Transform>
>>>
>>>
>>>
>>> In Humanoid space, once the connection between using center to set the
>>> Joint center of rotation and then a child Transform to position any
>>> associated stuff in Humanoid space just makes it work wonderful for what we
>>> need in hanim.
>>>
>>>
>>>
>>> I can recall a day when there were sincere discussions over whether to
>>> include the 'center' field in Transform.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240607/e855bd1e/attachment-0001.html>
More information about the x3d-public
mailing list