<div dir="auto"><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2024 at 4:07 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I think what you're saying is break a bone into 2 pieces, one with head plus center (now tail) and one with center (now head) plus tail.   This seems like an excellent idea.  I'm going to think on it a bit.<br>
> My question is, what do I name the 2 pieces?  I'm guessing something that I can combine on export.<br>
<br>
Indeed.<br>
<br>
As for new bone names: "Leg1_center" (when you need to add new Blender<br>
bone when "Leg1" joint has non-zero center in X3D/H-Anim) would look<br>
reasonable for me (and code can figure out what happened and invert<br>
it, so you can have round-trip that later exports it back into one<br>
"Leg1" joint with non-zero center). But that's just a suggestion.<br>
<br>
> This sounds like Zeno's paradox where I'm just trying to put weights where they don't go.  The weights go on the joints.  We only have weights for joints on import. ((well, I don't know all of X3D).<br>
<br>
Weights describe how much each joint influences each vertex. This is<br>
equal in Blender, X3D/H-Anim, glTF.</blockquote><div dir="auto"><br></div><div dir="auto">This is what confuses me.  I don’t see joints in Blender anywhere, and weights are distributed along the length of the bone according to documentation (yes, I do read bits and pieces of documentation).  If I’m wrong, please submit a pull request to change the documentation to clarify which end of the bones get the weights.</div><div dir="auto"><br></div><div dir="auto">Yes, I understand that the ends of the bones could share the weights, but that’s not clear in the documentation.</div><div dir="auto"><br></div><div dir="auto">Please quote documentation.  If Joe is saying Blender is messed up, maybe it actually is.  </div><div dir="auto"><br></div><div dir="auto">Bones work in blender whether corresponding heads and tails are at the same location or not.  There are no real joints, just parent-child relationships.</div><div dir="auto"><br></div><div dir="auto">Thanks!</div><div dir="auto"><br></div><div dir="auto">John </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir="auto"><br>
<br>
I'm not sure if what you're saying is equivalent, but if yes -> OK :)<br>
<br>
> Remember I'm doing this in python, not in the Blender GUI.<br>
<br>
Sure, but it should be similar. That is, Blender's Python API exposes<br>
a superset of things that you can do from GUI and it uses the same<br>
terminology, mostly. And you can observe in Blender's console what<br>
your interactive operation "means" in Python, it's a valid way to<br>
learn Blender's Python API.<br>
<br>
> It sounds like I should give up on ever trying to import site or segment geometry, and *try* to do Joints and skin.<br>
<br>
I'm not sure what do you mean here :)<br>
<br>
The H-Anim "skin" (one mesh, with joints and weights) should map to<br>
Blender, because it is exactly the same concept in Blender. (OK, not<br>
*exactly* the same, e.g. Blender, because of history, calls "bones"<br>
what X3D/H-Anim and glTF call "joints"; but it is close to equivalent,<br>
for 3D graphic artists these are the same things).<br>
<br>
You don't need to "give up" on anything, from what I can see. Just<br>
import/export X3D/H-Anim skin to Blender's skin (Armature). This is<br>
what 3D artists would expect.<br>
<br>
Other features (like attaching rigid objects to sites, without skin)<br>
are a separate thing. They can be imported/exported e.g. as bones'<br>
children. But these are separate things, I'd advise to focus on the<br>
hard case (skin) first :)<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div></div>