Spatial.lookat() and camera rotation

Hi guys,
it’s me again and I really hope not to annoy you too much… I am trying to solve this for hours now and can’t find anyone with a similar problem.

I have written a control for an entity (a costum subclass of node) to follow a path. It should always look at the next waypoint it is walking to. This works great if I bring it down to a 2D room: My entity is always facing the next point on the 2D map - but it is rotating around it’s own z-axis when I rotate the camera. I could not find any relation between Spatial.lookAt() and the camera rotation and I do not have any idea why the rotation of the camera influences the up vector of my spatial.

Here is the code to set up the spatial’s rotation:

                this.entity.lookAt(
                        new Vector3f(
                                path.getCurrent().x, //The xPos (on the 2D map) of the next waypoint)
                                terrain.getHeight(path.getCurrent(), true), //The height of the terrain at the next waypoint
                                path.getCurrent().y), //The yPos (on the 2D map) of the next waypoint)
                        Vector3f.UNIT_Y); //Up Vector

Sorry if it is a dumb question but I did not find any relation between the camera rotation and Spatial.lookAt and so I can not explain this behaviour.

Thanks in advance…

Check if you didn’t change any of the built-in static vectors (Vector3f.ZERO, UNIT_X, Y, Z etc) Easiest way is to print out their values or check if they are what they should be (if Vector3f.UNIT_Y.equals(new Vector3f(0,1,0)); etc)

Thank you very much… I found it. In a line I didnt touch for weeks and I seem to have written in midnight, it’s really embarassing…

My camera control was building a quaternion like this:

new Quaternion().fromAngleAxis(cam.getRotation().toAngleAxis(Vector3f.UNIT_Y), Vector3f.UNIT_Y)

No wonder my UNIT_Y is messed up when I use it to store vectors…

Thank you, problem solved :slight_smile:

Happens to the best ^^ We could actually add some assertions like this in the application update loop so you’d immediately get an error if you run your app with -ea @Momoko_Fan? What do you think about that?

I added an issue report here:

Please please please please do this as an optional app state and not embedded directly into the engine. I know these are small checks but there is no reason to burden everyone with them for no reason.

We can always include the app state by default in the simple app default setup, ie: when super(AppState…) is not called.

Why an appstate when an assertion is absolutely zilch “burden” when -ea isn’t enabled?

“via assertion or debug option”

…so, yes, if it’s done as an assertion. No if it’s done as a debug option.

And for those of us who write games that allow user-level scripting, it might still be nice to have a sanity checking app state without having assertions enabled for the whole app.

Edit: also I suspect most users run without assertions enabled but would happily leave a sanity check app state enabled. And I thought most of the point would be to eliminate these sorts of posts.

Well or be able to just ask “what happen when you run with -ea?”

Heheh… better to never hear anything, I think. Keeps the list of questions we answer five times a day to half a dozen or so. :slight_smile:

1 Like