Skip to content

Conversation

@riccardobl
Copy link
Member

@riccardobl riccardobl commented Jul 22, 2018

This PR fixes some issues in the AudioNode that caused wrong velocity calculation when using velocityFromTranslation.

In short, when cloning the node, previousWorldTranslation wasn't reset to its initial value but cloned as reference, and the first velocity update was a subtraction with a NaN.

I've also modified the cloneFields method to reset the velocity to 0 if velocityFromTranslation is set, to prevent cloned nodes from preserving the velocity of the original in case they are never moved.

Copy link
Contributor

@Nehon Nehon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the author of AudioNode, but looking at the code, the velocityFromTranslation flag was supposed to change the behavior of the node during the update.
Now it's not anymore. So either it's relevant and the flag should be completely removed, and the setter getter deprecated, either it's an oversight and the flag should be added back. It's seems that the original issue is just a clonning issue.

Also the changes should follow the engines formatting scheme.

super.updateGeometricState();

if (channel < 0) {
if(channel<0||this.getParent()==null||!velocityFromTranslation) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please follow the formatting scheme of the rest of the engine? This line should be
if (channel < 0 || this.getParent() == null || !velocityFromTranslation) return;


if(!previousWorldTranslation.equals(currentWorldTranslation)){
getRenderer().updateSourceParam(this,AudioParam.Position);
velocity.set(currentWorldTranslation).subtractLocal(previousWorldTranslation).multLocal(1f/lastTpf);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the velocityFromTranslation flag?
If it's not here it's now completely useless.

@riccardobl
Copy link
Member Author

I moved the flag up to line 725, but on second thought this was going to skip the position update for nodes that do not use velocity from translation...

It's seems that the original issue is just a clonning issue.

See rows 732 and 738 in the original code, if velocityFromTranslation is enabled, the first update will always turn velocity into NaN.

I've made some changes, it should be fine now.

Copy link
Contributor

@Nehon Nehon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok good for me.
I must have missed the flag in previous review.

@stephengold stephengold merged commit f12d7e4 into jMonkeyEngine:master Sep 6, 2018
joliver82 pushed a commit to joliver82/jmonkeyengine that referenced this pull request Nov 14, 2018
…actoring (jMonkeyEngine#875)

* Fix AudioNode issues when using velocityFromTranslation and small refactoring

* Fix audionode fix
@stephengold stephengold added this to the v3.2.2 milestone Dec 20, 2018
@pspeed42
Copy link
Contributor

Why does this have a getParent() == null check? That doesn't make sense to me... and seems like a big change in behavior (I almost never attach my AudioNodes to anything, for example). Definitely too risky for 3.2.2... and the check should maybe be removed. (Or at least explained.)

@pspeed42 pspeed42 removed this from the v3.2.2 milestone Dec 21, 2018
@riccardobl
Copy link
Member Author

riccardobl commented Dec 21, 2018

I think the null check can be removed, tbh i don't remember if there is a reason for it to be there in the first place.

@pspeed42
Copy link
Contributor

Position worked before and now it doesn't, right. Velocity may have been broken before but position definitely wasn't... at least not when I've used it in the past.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants