<div dir="auto">Note that I am *importing* not exporting.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 1, 2024 at 11:03 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"> Corrected</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 1, 2024 at 10:39 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Note, I have not been able to yet to do <b>local keyframe rotation</b> 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.</div></blockquote></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br></div><div dir="auto">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.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 1, 2024 at 1:26 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>This is how I think. This email may be ignored.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 31, 2024 at 11:32 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>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.</div></div></div></blockquote><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I will work with the new Jin, trying to get the transform hierarchy offsets working; <b>it looks like local rotations are not working,</b> and the whole transform structure is rotating around a root object (or moving origin). So <b>I need to look at how to create local rotations</b>, 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.</div><div><br></div><div>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.</div><div><br></div><div>I'm guessing the issue is that some geometry are extra copies that are not parented to the humanoid. What do you think?</div><div><br></div><div>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.</div></div></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>