Problem with generating AttachmentNodes

So, I was creating attachment nodes (nodes attached to a bone) in the SceneComposer, and everything was fine.

Until the moment I save the file, close it and reopen. In that moment, the node is not attached anymore to the bone and, as such, doesn’t move when I play the animation.

This wasn’t happening to me until I switched from jME’s SDK 3.0 to 3.1-beta2, and if I create the attachment node in code, it works fine.

So, does anyone know about this problem, and how to fix it?

Hey @Ev1lbl0w,

I have the same issue and also created a new topic about that, but nobody could help yet.

I tried to look for similar problems but couldn’t find anything. Well, at least there are already 2 of us xD.

For some reason I don’t remember seeing the other thread. Strange.

Three were some changes to how things were cloned at some point… I think near one of the last alphas(?). It would be interesting to know if it stopped working at that point or if it was related to some other change.

A lot of times when I notice something breaks and no one seems to know why, I end up having to step through the changes, building JME locally, until I find which commit broke things. Painful to be sure… but it often points to the issue right away. There were enough alphas that maybe you could more easily at least narrow it down that way.

1 Like

Note: it’s also completely fair to put an issue in the bug tracker if you don’t get a response in a reasonable time… “reasonable” being a judgment call but certainly after a month of nothing is definitely a reasonable amount of time. :slight_smile:

2 Likes

If you’ve got more than a few commits between HEAD and a known good build, bisect it.

If there’s a simple scriptable way to test for the bug, you just let the system do its thing. If you need to manually test, git takes care of tracking where you are at in the test process. 1024 commits should take only 10 tests.

To be clear,
So if you create attachment node in code and save .j3o then load it (all in code without using SDK) does it still work ?

It would be good to confirm but my read on it is not the above.

From the explanation so far, my interpretation was that saving a j3o with an attachment node in it never works. But if you load a j3o and then manually grab the attachment node then it works.

The SDK isn’t doing anything special that the code wouldn’t be… neither is the blender loader in this case.

But it’s quite likely that something during load is not getting ‘fixed up’ like it used to and leaving these attachment nodes dangling. The new cloning would be the most obvious potential culprit. Someone could short-circuit a lot of testing just be trying JME before that commit.

This was the commit that started it all:

…though that was back even before alpha4 so there may have been other changes much later that could affect this also I guess. I haven’t really looked at the evolution of attachment nodes at all.

1 Like

I can try to test this tonight.

I think the issue is that skeleton and bone don’t use the new cloner stuff so there is no automatic fix-up.

Skeleton probably needs to be modified to use the new cloning stuff to clone the bones. That code would get a lot simpler.

Else, we need to port the old bone attachment fixup code from SkeletonControl.cloneForSpatial() … and that’s pretty ugly.

The only thing making it slightly tricky to implement is that Bone’s child array list is ‘final’ so we can’t just use super.clone() and fix it up after.

I don’t have an ready-made test for this issue. If someone is building from the 3.1 branch then maybe they can test my changes? …or if there is a ready-made test project + j3o then I can do the fix.

I will at least confirm that I don’t break what’s working up to now.

1 Like

I have what is hopefully a fix committed to the v3.1 branch and to master… the v3.1 commit is here:

I have confirmed that at least in my own testing, cloned animations work at least as well as they did before. In theory, attachment nodes should now also be fixed. Well, at least they have a reasonable chance. There is no way they’d have worked before this change.

3 Likes

I compiled jme3-core.jar with new commit @pspeed made to master.
I tested to create attachment node and save it to j3o then load it and play it in code and it worked successfully.

I also created a SDK test project + j3o and pushed it to github for testing.

Edit: edited post.

I was hoping one of the original reporters might also get a chance to test this before I make beta 3.

…but I’m getting antsy and may tag it tonight.