[x3d-public] Local rotation of node in blender object hierarchy. X3DJSAIL: Replace nodes

John Carlson yottzumm at gmail.com
Sat Jun 1 08:39:18 PDT 2024


Note, I have not been able to yet to do absolute local keyframe rotation in
Blender.  Non-local rotation works.  I want rotation like joints, but
without HAnimJoint.  I did see that local rotation was a feature of
keyframing, but I haven’t figured out the right python incantations.

I’m thinking a replace node list with node list at the root node level may
be useful in X3DJSAIL.   Or just apply a node-to-node mapping.  Statements
too.  I’ll see what I can do in the removal code generator.  I realize this
may violate some fundamentals of SAI, so I’m not asking for an
enhancement.  I’m not even sure replace element is possible in Java SDK.
It may be possible in DOM.  I don’t have a current use for this if I can
get setters working.  Analyzing more differences are necessary before
filing a bug report.

On Sat, Jun 1, 2024 at 1:26 AM John Carlson <yottzumm at gmail.com> wrote:

> This is how I think.  This email may be ignored.
>
> On Fri, May 31, 2024 at 11:32 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> I notice, in particular, that Boxes and Spheres appear outside the
>> hierarchy, which may be indicative that the importer code does not handle
>> those properly. Joe, I really think that defining the geometry *once*
>> outside the hierarchy is a good idea.
>>
>
> From what I see though, there are over 100 pieces of geometry being
> created outside the HAnim hierarchy in Blender, and I've spotted similarly
> named shapes inside the hierarchy.  I think this is because they are linked
> to the overall Blender Python collection.  I don't know why the
> IndexedFaceSets (there aren't that many in the latest Jin) and LineSets are
> not similarly linked. From what I've seen, there are copies of shapes being
> made if the node.blendObject is already set (when retrieving from the DEFed
> node). What's going on, I think, is that the DEFed object is outside the
> humanoid.  Which is entirely intentional.
>
> What I think we could *try* is DEFing the shape, group or transform,
> etc. the first time it appears *inside* the humanoid. Then proceed as
> normal with following USEs.
>
> There is obviously no guarantee that this would work, but it may erase the
> extraneous geometry, or "Mini-me" we see, and allow me to focus on a pure
> humanoid model.
>
> I am fairly sure that Joe has reasons for doing what he is doing, so I
> suggest that we take several paths towards the ultimate Jins, one with
> DEFed geometry inside the humanoid (but still USEd), and one with geometry
> outside the humanoid. I know it's twice the work.  I may be able to help
> with some Java code.  I will try translating Jin to JavaScript like I did
> Leif to enable node removal. I also seem to not be able to apply setters,
> even though I can remove the USE attribute.  More debugging is required.
>
> I will work with the new Jin, trying to get the transform hierarchy
> offsets working; *it looks like local rotations are not working,* and the
> whole transform structure is rotating around a root object (or moving
> origin).  So *I need to look at how to create local rotations*, at
> least.  I was hoping to do that with Blender bones, but with them out of
> the picture, I'll have to do something else.
>
> There's something I don't understand in Blender about collections versus
> parents.  I don't know why all objects linked don't all appear at the top
> level, since they are all linked to one collection. I know that there *may*
> be ways to link objects (geometry) to both the object hierarchy and
> armature, but I don't know as I've been successful at that, except for
> continuous skin that is connected to the armature with skin weights/vertex
> groups.
>
> I'm guessing the issue is that some geometry are extra copies that are not
> parented to the humanoid.  What do you think?
>
> I would think that trying to animate such geometry would lack the
> humanoid/transform/object hierarchy (the DEF/USE names are similar,
> perhaps), so they would animate around the origin. Hmm.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240601/a49e5411/attachment.html>


More information about the x3d-public mailing list