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

[John Carlson]

 Corrected

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

> Note, I have not been able to yet to do *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/a88f53ab/attachment-0001.html>