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

[John Carlson]

Note that I am *importing* not exporting.

Thanks,

John

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

>  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/3d908d30/attachment.html>