[x3d-public] Can you get this X3D animation imported into Blender?

[John Carlson]

I now have a solution that seems to work like X3D (I will test
other browsers to compare with castle-model-viewer)!  Yay! Enjoy!

Here's the new method (note that there's no return value).  Further HAnim
testing is now required.

[image: image.png]

def getFinalMatrix(node, mtx, ancestry, global_matrix):



 transform_nodes = [node_tx for node_tx in ancestry if node_tx.getSpec() in
('Transform', 'HAnimHumanoid', 'HAnimJoint', 'HAnimSegment', 'HAnimSite')]
    if node.getSpec() in ('Transform', 'HAnimHumanoid', 'HAnimJoint',
'HAnimSegment', 'HAnimSite'):
        transform_nodes.append(node)
    transform_nodes.reverse()

    if mtx is None:
        mtx = Matrix()

    bpyob = node.blendObject

    if bpyob.type == 'EMPTY' and len(transform_nodes) > 0:
        mat = translateTransform(transform_nodes[0], ancestry)
        bpyob.matrix_local = mat

On Tue, Jun 4, 2024 at 11:50 PM John Carlson <yottzumm at gmail.com> wrote:

> Followup, not solved yet.
>
> For the base Blender .wrl importer, I made the following changes:
>
> diff --git a/io_scene_x3d/import_x3d.py b/io_scene_x3d/import_x3d.py
> index 4c215516..0d8337a1 100644
> --- a/io_scene_x3d/import_x3d.py
> +++ b/io_scene_x3d/import_x3d.py
> @@ -3347,9 +3347,9 @@ def translateOrientationInterpolator(node, action,
> ancestry):
>
>          mtx = translateRotation((x, y, z, w))
>          eul = mtx.to_euler()
> -        rot_x.keyframe_points.insert(time, eul.x)
> -        rot_y.keyframe_points.insert(time, eul.y)
> -        rot_z.keyframe_points.insert(time, eul.z)
> +        rot_x.keyframe_points.insert(time * 250, eul.x)  # end to 250
> frames so we can see the motion
> +        rot_y.keyframe_points.insert(time * 250, eul.y)
> +        rot_z.keyframe_points.insert(time * 250, eul.z)
>
>      for fcu in (rot_x, rot_y, rot_z):
>          for kf in fcu.keyframe_points:
> @@ -3611,7 +3611,7 @@ def load_with_profiler(
>      import cProfile
>      import pstats
>      pro = cProfile.Profile()
> -    pro.runctx("load_web3d(context, filepath, PREF_FLAT=True, "
> +    pro.runctx("load_web3d(context, filepath, PREF_FLAT=False, "
>                 "PREF_CIRCLE_DIV=16, global_matrix=global_matrix)",
>                 globals(), locals())
>      st = pstats.Stats(pro)
> @@ -3628,7 +3628,7 @@ def load(context,
>
>      # loadWithProfiler(operator, context, filepath, global_matrix)
>      load_web3d(context, filepath,
> -               PREF_FLAT=True,
> +               PREF_FLAT=False,
>                 PREF_CIRCLE_DIV=16,
>                 global_matrix=global_matrix,
>                 )
>
> ===============================================================================
> The latter allows Object EMPTYs to be created (Transforms) so there can be
> local rotations (looks like  a Blender requirement).  This also offsets the
> box on the right too much, and there's an extra bend due to the EMPTY.  But
> looking at the object hierarchy (not the transforms) looks okay.  But look
> closely at the location.  Those have not changed, so everything is locally
> transformed.
>
> What I am seeing is 2 ninety degree rotations.  Two systems treat them
> differently.  One rotates the objects by 90 degrees, and children, but in
> Blender, Transforms are given an actual location.  So one can subtract the
> offset between the Transform and the box, but then first and third cubes
> land on top of each other.
>
> It's still an interesting puzzle to look at.  This is by no means solved.
> I think it's similar to the rotation/revolution problem around the sun:
>
> https://www.youtube.com/watch?v=FUHkTs-Ipfg (Veritasium)
>
> Ideally, there would be no offset between the "TransformTargetChild" and
> the Shape in Blender.  Somehow, the shape is inheriting the offset of its
> parent, and offseting 4 m from the transform.  Hmm
>
>                         <Transform DEF="TransformTargetChild"
> translation="4 0 0">
>                                 <Shape>
>                                         <Box/>
>                                 </Shape>
>                         </Transform>
>
> I am also attaching my current test files, the major change was to change
> set_rotation to rotation in two places to match the importer (oops, extend
> the importer).
>
> If someone wants to play with my "improved" Blender addon, let me know,
> otherwise, I'd like to see this fixed in the original Blender plugin.  I
> don't have a solution yet.
>
> John
>
>
>
> On Tue, Jun 4, 2024 at 9:45 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> One thing you will notice right away, perhaps, is that the ROUTEs aren’t
>> imported.  Perhaps converting to VRML97 will work, I’ve not tried that, I
>> just went full steam ahead at importing XML.
>>
>> John
>>
>> On Tue, Jun 4, 2024 at 8:37 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> Challenge:
>>>
>>> Can you get this X3D animation and box translations imported into
>>> Blender properly?
>>>
>>> If you can, I'll give you a big fat kiss  (kidding!).
>>>
>>> Looks simple, right?
>>>
>>> Please provide any diffs to your favorite X3D Blender importer.
>>>
>>> Attached example (run in your favorite X3D browser to see
>>> desired results).
>>>
>>> Thanks!  This will likely help out my efforts a lot!
>>>
>>> John
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240605/1a8665f7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 44455 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240605/1a8665f7/attachment-0001.png>