Irrlicht Engine

I noticed something odd with camera->getTarget()

I use the following 2 lines of code to get the start point of a bullet fired from the player and the trajectory.

vector3df aimVector=(camera->getTarget() - camera->getPosition()).normalize();

vector3df aimStart=camera->getPosition();

This works fine most of the time. However if you are moving I noticed that the values get negative signs. Now movement is something I am controlling myself. I use a fpscamera but I have disabled the movement keys and only retain the mouselook(by using the constructor keymapping)

My question is, if I am programatically moving the camera in response to my physics engine events, why would moving in any way effect these lines of code? The graphical view looks fine when moving, I don't flicker to looking backwards(which is what would happen since my bullets are comming out my back).

Is there a multithreading issue with these events from irrlicht, or are they comming in on the main thread still?

Is using an FPS camera bad? I just want the mouselook capability so I could implement it myself if I have to.

However if you are moving I noticed that the values get negative signs.

That isn't really a bad thing. If the camera is at (0, 0, 0) and it is looking at (-10, -10, -10), the aimVector will end up as (-.577, -.577, -.577), which is totally correct.

The only problem that I could see happening is if the camera is a child of some other scene node. Just to be safe you should usually use getAbsolutePosition() instead of getPosition().

Travis

so why is there getpostion() and getabsolutepostion() !!? why not make them only one?

omar shaaban wrote:so why is there getpostion() and getabsolutepostion() !!? why not make them only one?

If the camera is a child of a scene node, and you want to get it's position relative to it's parent, you would use getPosition(). If you wanted to get the position of the camera relative to the rest of the world, you would use getAbsolutePosition().

I only wish there was a function for setAbsolutePosition()... It probably wouldn't get used much, but it would be helpful sometimes.

Hey thanks for the reply vietk.
The problem with the negative numbers is not that they are negative, but that they switch from being positive to negative simply by moving in a direction. This shouldn't happen since moving doesn't rotate the camera. It just moves the scene node. What I am seeing is 2 of the co-ordinates in the look at vector flipping from positive to negative or vice versa when i start moving the camera around. They keep the same value pretty much, so like going from 30,30,30 to -30,30,-30.

Something like that.

I will try the absolute position and see if it helps any.

*Update*
I tried using absolute position and it works fine now. I checked and I do not attach my camera to anything. I don't know why this fixed it but hey I will take what I can get. Thanks a lot.

Oh and in response to death_au

I think I can answer this one.
There is no reason to set absolute position. A scene node is attached to something or nothing. If it is attached to something it should always remain relative. If you want it to not be relative it should be attached to nothing, and in that case setPosition would be the same as setAbsolutePosition