Solved - SkinningControl weird behaviour

[Zoltan85]

Hello,

sometimes, when animations are changed, the model attached to the attachmentsNode is displayed as if it was attached to the parent model root node instead of the attachment node.

I am using SkinningControl to attach a cap to my model. the code is:
skinningControl?.getAttachmentsNode("jointName")?.attachChild(myModel)

the model is animated and from time to time it changes animations based on game rules:
animComposer.setCurrentAction(intendedAnimation, "Default", true)
also, sometimes the root node of the model is translated and rotated around.

I noticed two things, if they can help with troubleshooting:

• This happens more frequently when the animation is very still or the root node does not move.
• If the animation changes, the model returns to the attachment node position.

What am I doing wrong?
thanks in advance to whoever will help!!

[pspeed]

Things that would help others help with this problem:

1. knowing what version of jme you are using.
2. a simple stand-alone application (preferably a single class) that exhibits the issue.

For what it’s worth, I do not see this issue personally on the version of JME that I use.

[Zoltan85]

Hello,

I’m using the jme “3.6.1-stable”.

what’s the version you’re using ?

[pspeed]

I’m running a local fork of 3.6.

However, you may want to try a newer version and see if that fixes your problem.

If not then it will probably be helpful to post a simple test application that illustrates the issue. Two reasons: 99% of the time the test application will work fine for you and then you can figure out the difference between it and your code… many times that points to the real problem. In the other 1% of cases, it’s a ready to go example for someone to find and fix the problem in JME.

[Zoltan85]

Solved! thanks for the advice.
Actually the problem was due to the root node of the model having an non valid rotation quaternion in some cases.
I would prefer the code to throw an exception in those cases instead of behaving unexpectedly.

I’ve seen that in video game programming, throwin exceptions on unexpected input values is usually not preferred or avoided even by game engines and I’m struggling to understand why.

should I change the title of the topic to indicate that the issue was solved?

[pspeed]

@Zoltan85

I would prefer the code to throw an exception in those cases instead of behaving unexpectedly.

So like every quaternion modification should add code to check to see if it’s still valid? What does “valid” mean in every possible case?

In general, JME chooses not to slow down every program just to detect relatively rare errors.

@Zoltan85

I’ve seen that in video game programming, throwin exceptions on unexpected input values is usually not preferred or avoided even by game engines and I’m struggling to understand why.

Because a significant reduction in performance is not deemed worth it for isolated incidents that experienced developers will just avoid 99% of the time… and/or learn to spot quickly.

It’s also tough to predict what ‘valid’ is in all cases. Perhaps loading a model with a NaN, NaN, NaN value somewhere is intentional for something the application intends to do with that later.

@Zoltan85

should I change the title of the topic to indicate that the issue was solved?

Yes. Usually just put “Solved:” in front of the title.

[richtea]

@Zoltan85

I’ve seen that in video game programming, throwin exceptions on unexpected input values is usually not preferred or avoided even by game engines and I’m struggling to understand why.

In the general case because of performance. And games are unusually performance sensitive. Checking if things are wrong takes some cpu cycles. A solution can be asserts, then the checks are only there at development time; but even that can be a problem if it makes the game unplayably slow in dev mode. Assuming there really is no legitimate case for these “wrong” values

Edit; jinx