Phsyics and the mouse
Author
Let's say the mouse movement controls a certain mesh's position (where the mouse moves the mesh moves as well). How can I calculate the velocity of the mesh object ?. How velocity is expressed at this situation ?
Another thing , The mesh object can hit another object , how I calculate the new velocity of the other object ?
I know the physics eqations for those, but I don't know how to capture time between mouse movements ?
any ideas or good tutorials about this specific stuff ?
thx.
It seems to be 2D, isn't it? If it be 3D things are much more complex. I'll try explaining the 2D case.
If the object is going to move with the same speed as the cursor is moving then its just you get the time at one game step(when you check mouse cursor position) and then get the time again at the next step and you'll have the delta time. Now its just divide the mouse cursor displacement vector by the delta time. I think that is it. And for collision, you can use the conservation of momentum principles. Take a look at this.
If the object is going to move with the same speed as the cursor is moving then its just you get the time at one game step(when you check mouse cursor position) and then get the time again at the next step and you'll have the delta time. Now its just divide the mouse cursor displacement vector by the delta time. I think that is it. And for collision, you can use the conservation of momentum principles. Take a look at this.
A lot of APIs have some sort of "Mouse Relative" variable, which just gives you the last position of the mouse.
If you take the relative coordinates and divide them by time, you'll get the speed.
You can also use the coords to generate a vector of some sort, that will get you the actual VELOCITY (containing speed and direction).
If you take the relative coordinates and divide them by time, you'll get the speed.
You can also use the coords to generate a vector of some sort, that will get you the actual VELOCITY (containing speed and direction).
The best way to do this is to attach a spring with a resting length of zero and high spring constant to the mouse and a point on the object you want to control. This allows the object to move by physical dynamics while it is controlled by the mouse. This avoids problems that arise when you control the position of the object directly, such as problems with collision response (the object appears to have infinite mass), as well as other limitations of kinematicly driven objects, as opposed to a smooth dynamics based simulation.
Author
Thx for the replies.
I'm still having troubles understanding it. I use DirectInpu for capturing mouse movement. Now on each frame update I the mouse moved, I get the offset values for his movement. Can I treat these offsets as the cursor speed ? If not, how to time these events correctly ?
thx.
I'm still having troubles understanding it. I use DirectInpu for capturing mouse movement. Now on each frame update I the mouse moved, I get the offset values for his movement. Can I treat these offsets as the cursor speed ? If not, how to time these events correctly ?
thx.
I don't know how that input API works, but if you can get the current position of the mouse on the screen, then all you need to do in the physics engine is attach a spring to that position (assuming you're working in 2D, otherwise you have to do some sort of projection/ray casting) and the position of the object you're manipulating.
This is the most stable, accurate way of doing this. If you just use the mouse's dx and dy, you'll run into round off errors and integration problems if you use that to calculate the object's velocity. I highly recommend letting the physics engine take care of everything and then all you have to do is attach a spring when you down-click and deattach it when you up-click.
This is the most stable, accurate way of doing this. If you just use the mouse's dx and dy, you'll run into round off errors and integration problems if you use that to calculate the object's velocity. I highly recommend letting the physics engine take care of everything and then all you have to do is attach a spring when you down-click and deattach it when you up-click.
I'm going to agree with Aressera.
Attaching the object to the mouse curosr directly can cause problems.
Consider this possibility, the user might have a Touchpad (like on a laptop computer). He can tap the cursor at one location, then lift his finger and tap somplace on the other side of the screen without moving between those locations. If your object just inherits the cursor position directly, it will 'warp' across the game map.
Rather than moving the object with the cursor while trying to measure its velocity. It is better to have the object maintain its velocity Inside the physics code entirely, and have the cursor only apply an acceleration to it.
Aressera's Spring suggestion is a good example of this, a spring applies a force(or acceleration) to the object, the physics engine then alters the velocity.
One slight concern though, depending on your object's dynamics, a simple spring force might lead to 'wobbling' -the object might go into orbit around your cursor rather than end up stopped. A small amount of friction or 'wind resistance' in your physics should prevent this kind of issue.
Attaching the object to the mouse curosr directly can cause problems.
Consider this possibility, the user might have a Touchpad (like on a laptop computer). He can tap the cursor at one location, then lift his finger and tap somplace on the other side of the screen without moving between those locations. If your object just inherits the cursor position directly, it will 'warp' across the game map.
Rather than moving the object with the cursor while trying to measure its velocity. It is better to have the object maintain its velocity Inside the physics code entirely, and have the cursor only apply an acceleration to it.
Aressera's Spring suggestion is a good example of this, a spring applies a force(or acceleration) to the object, the physics engine then alters the velocity.
One slight concern though, depending on your object's dynamics, a simple spring force might lead to 'wobbling' -the object might go into orbit around your cursor rather than end up stopped. A small amount of friction or 'wind resistance' in your physics should prevent this kind of issue.
Author
thx all for the replies.
What do you mean by attaching my object to a spring ?
All I wanna do is move the object with the mouse. For now I did as AfroFire suggested. On each move I calc the distance between current pos and last pos and divide it with the time differnce (using a very accurate timer) for getting the velocity. Is that not enough ? or is that not accurate ?
thx.
What do you mean by attaching my object to a spring ?
All I wanna do is move the object with the mouse. For now I did as AfroFire suggested. On each move I calc the distance between current pos and last pos and divide it with the time differnce (using a very accurate timer) for getting the velocity. Is that not enough ? or is that not accurate ?
thx.
Directly coupling your object to a non-physics object introduces the possibility of a distinct group of errors and has some unintended side effects that are described in the post above yours.
By utilizing a spring-mass system, you are abstracting from direct interaction with the physics environment, and letting the physics engine do the work. The physics engine stores the state information and will apply forces based on Hooke's law with the coeff. that you specify when you create the spring. In short, using a spring will save you a ton of work and headache later on.
By utilizing a spring-mass system, you are abstracting from direct interaction with the physics environment, and letting the physics engine do the work. The physics engine stores the state information and will apply forces based on Hooke's law with the coeff. that you specify when you create the spring. In short, using a spring will save you a ton of work and headache later on.
Another example of why connecting your object directly to the mouse is bad:
The old game Descent(2) (multiplayer version)
The ship's orientation was Directly connected to your mouse cursor, meaning if you whippped the mouse around, you could instantly reverse direction (in a physically unreal way).
As a consequence, the multiplayer game hosts split into two groups, mouse allowed, and joystick only. Because people would 'cheat' by increasing their mouse sensitivity to gain manuverability.
The old game Descent(2) (multiplayer version)
The ship's orientation was Directly connected to your mouse cursor, meaning if you whippped the mouse around, you could instantly reverse direction (in a physically unreal way).
As a consequence, the multiplayer game hosts split into two groups, mouse allowed, and joystick only. Because people would 'cheat' by increasing their mouse sensitivity to gain manuverability.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
