Quaternion lookat was it changed Jme 3.3

smith · July 18, 2020, 4:55pm

I keep getting this even though it “seems” to be still part of the Quaternion class, just flushed and reinstalled all the libs and no go

java.lang.NoSuchMethodError: ‘com.jme3.math.Quaternion com.jme3.math.Quaternion.lookAt(com.jme3.math.Vector3f, com.jme3.math.Vector3f)’
at hks.test.TestCharacterMoveToLocation.simpleUpdate(TestCharacterMoveToLocation.java:252)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:242)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.base/java.lang.Thread.run(Thread.java:832)

pspeed · July 18, 2020, 8:46pm

It was definitely in 3.3.2-stable:

github.com

jMonkeyEngine/jmonkeyengine/blob/v3.3.2-stable/jme3-core/src/main/java/com/jme3/math/Quaternion.java#L1363


 * the rotation to transform the z-axis to point into 'direction'
 * and the y-axis to 'up'.
 *
 * @param direction
 *            where to look at in terms of local coordinates
 * @param up
 *            a vector indicating the local up direction.
 *            (typically {0, 1, 0} in jME.)
 * @return this
 */
public Quaternion lookAt(Vector3f direction, Vector3f up) {
    TempVars vars = TempVars.get();
    vars.vect3.set(direction).normalizeLocal();
    vars.vect1.set(up).crossLocal(direction).normalizeLocal();
    vars.vect2.set(direction).crossLocal(vars.vect1).normalizeLocal();
    fromAxes(vars.vect1, vars.vect2, vars.vect3);
    vars.release();
    return this;
}

public void write(JmeExporter e) throws IOException {

So your classpath must be some kind of messed up. Maybe you are compiling against 3.3.2 but running against 3.2? The method was there in 3.2 but had a ‘void’ return type so not the same method.

smith · July 19, 2020, 12:03am

is there an example that refactor being used somewhere, I get the same crash with everything I have tried but I would have dealt with all of the build path issues as far as I can tell

pspeed · July 19, 2020, 12:05am

That crash indicates that you are running against an older jme-core.jar. That’s all I can tell you from here. It’s not a “usage” problem.

NoSuchMethodError is always the result of code being run against incompatible jars.

Are you using the SDK? Gradle? insert-other-thing-here?

Edit: let me expand on the “not a usage problem” statement.
This code:

Quaternion q = new Quaternion();
q.lookAt(Vector3f.UNIT_X, Vector3f.UNIT_Y);

Will work if you compile it on 3.2 and run it on 3.2… but will fail if you run it on 3.3 (but with a slightly different error message, same exception).
Will work if you compile it on 3.3 and run it on 3.3… but will fail if you run it on 3.2 with the error message you provided.

smith · July 19, 2020, 12:23am

I will check my setup again I did “upgrade” a copy of my projects to 3.3 but again I have tried to deal with the path issues both through eclipse and manually even re-downloaded jme332 release today because I recognized that there could be a conflict somewhere but with no success, I dumped the bin and rebuilt everything, all references to jme3.2 libs as far as I can tell are gone.

pspeed · July 19, 2020, 12:26am

All I can say is that the only way you will see this problem is if you compiled against 3.3 but are running against an older JME.

It’s the only reason this error would happen. Not “just one of the possible reasons”… but literally the only reason.

So that’s what’s happening. Probably some Eclipse garbage is getting in your way I guess. This would be way easier to sort out from the command line + gradle, for example. But I don’t know anything about Eclipse except how to spell it and that I hate it… so others may be able to provide better debugging approaches.

smith · July 19, 2020, 12:47am

Well in that case I’ll try recreating the setup with my source only, My work and interests can take me away for months even years, I didn’t even know normen and others left the project, I am reluctant to get in build systems and such the like because they have changed often over the life of jme and I always have a “mess” to clean when I have to go on hiatus for what ever reason

pspeed · July 19, 2020, 12:49am

I’m not suggesting that you switch. I think there are others here that use eclipse.

I just personally can’t help debug eclipse build problems.

Is there some way of creating a self-contained application of your project? Then at least you could look in there to see what versions of jars are in and so on. (you may have to look into the jars themselves but it’s still possible).

smith · July 19, 2020, 12:57am

Well it’s all manually put together" by hand" as stated I feel the best approach is the draft my sources into a new project and rebuild the properties if eclipse is indeed the culprit

pspeed · July 19, 2020, 1:02am

I think gradle is the current ‘state of the art’ and while it has a learning curve it’s probably not as steep as maven or ANT (back in the day).

There are some sample projects around that you can look at if that’s the direction you want to take. The biggest sea-change is that transitive dependencies will be gathered for you rather than all having to be specified explicitly.

There are a few of my own examples here:

…simple-jme is the “blue cube” app with gradle. It’s a little out-dated in some ways (still links to jme 3.1, based on older gradle syntax, etc.) But may be good for reference.

smith · July 19, 2020, 1:42am

noted thanks, I think I will look into gradle I have touched on it a bit for minie so I am already kind of familiar

smith · July 21, 2020, 9:25pm

Ok I think I am going to stick to 3.2 until I get this figured out, pulled a core jar from jme3 bintray removed my local copy from my cp made sure that my app actually crashed just to be certain that jme3-core is nowhere before attaching the bintray one and no go, probably move to node lookAt for now because I have no clue at this stage what the issue is and I am not going to drive my self crazy over it removing the call to lookAt in 3.3 and the class runs, though obviously not as intended below is the offending line ( @pspeed I know there is rule for presenting code but my hydrocephalus been annihilating my short term hard these days)

Blockquote
targetRotation.lookAt(targetMarker.getLocalTranslation().subtract(characterNode.getWorldTranslation()).normalize(), Vector3f.UNIT_Y);

pspeed · July 21, 2020, 10:24pm

That code is valid on both 3.2 and 3.3.

But:
If it’s compiled on 3.2 then it will only run on 3.2.
If it’s compiled on 3.3 then it will only run on 3.3.

So as mentioned… not a usage issue but a classpath issue.

mitm · July 21, 2020, 10:47pm

If you have a cache, it could still be referencing the wrong class, try clearing it.

I have seen that happen in netbeans. Removing imports for the file and importing them individually may also help see whats going on if you have autocomplete since it may show more than one option for the same class.

smith · July 22, 2020, 12:51am

@mitm will try that thanks

smith · July 22, 2020, 12:54am

that’s just it I don’t why it is doing that if true, unless as @mitm suggests its some kind of caching issue. will look into that

pspeed · July 22, 2020, 12:57am

I can’t tell you why it’s happening. I can only tell you the facts of the only way you get that particular error.

If there is no way for you to export your project as something that will run stand-alone then you are limiting your game to only be run by you. If there is a way to export something that will run stand-alone then you should be able to look into the package to see what jars are there.

If you use that same classpath and use javap against Quaternion, you will see which version of lookAt() that it has.

sailsman63 · July 22, 2020, 2:58am

When you replaced the core jars, did you re-compile your application against the replacement version? If not, you will definitely see this sort of issue…

smith · July 22, 2020, 3:22am

several times I actually watched the clean build process delete and repopulate the class bin just to be sure, even deleted the bin a couple times manually

I normally back up my workspace I’ll check against an archived version

smith · July 24, 2020, 1:09am

ok node and Quat lookAt works 3.2 project

node look at works and Quat lookAt fails 3.3 in project, no clue how to address this issue again there is no classpath issues that I could detect, and the code is correct for both I will just run with what works