Camera look at oddity

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Camera look at oddity

Post by kendric »

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.
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

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
omar shaaban
Posts: 616
Joined: Wed Nov 01, 2006 6:26 pm
Location: Cairo,Egypt
Contact:

Post by omar shaaban »

so why is there getpostion() and getabsolutepostion() !!? why not make them only one? :roll:
death_au
Posts: 38
Joined: Tue Apr 17, 2007 9:48 am
Location: Australia

Post by death_au »

omar shaaban wrote:so why is there getpostion() and getabsolutepostion() !!? why not make them only one? :roll:
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.
Image
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

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.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

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
Post Reply