I am working on a yet another 3d game engine and have following Problem. In order to improve Performance I want to check if two Objects are coming closer or moving away from each other. Only if they are coming closer to each other collision detection should happen.
At the moment the code calculates the current distance using the positions of both Objects. Then moves both positions about the velocity vector and calculates the expected distance. etc.
public class Model{
public boolean isApproaching(Model model) {
float [] otherPosition = model.getPosition();
float [] otherVelocity = model.getVelocity();
double currentDistance = Math.pow(this.position[0] - otherPosition[0], 2)
+ Math.pow(this.position[1] - otherPosition[1], 2)
+ Math.pow(this.position[2] - otherPosition[2], 2);
double expectedDistance = Math.pow(this.position[0] + this.velocityVector[0]/1000 - otherPosition[0] - otherVelocity[0]/1000, 2)
+ Math.pow(this.position[1] + this.velocityVector[1]/1000 - otherPosition[1] - otherVelocity[1]/1000, 2)
+ Math.pow(this.position[2] + this.velocityVector[2]/1000 - otherPosition[2] - otherVelocity[2]/1000, 2);
if(currentDistance < expectedDistance)
return false;
return true;
}
}
As you can see in the Picture it does not work for fast moving objects. Is there any good way to show if two points are moving towards each other?
Given the two straight line trajectories, there's a unique time when they're going to be closest, which may have been in the past. If it's in the past then it means that the objects are moving away from each other, but if its in the future it means that they're moving closer together. But even it they're moving closer together, I would guess that knowing how soon is the information that you need, so that you can schedule when to worry about it. This methodology should cater for both slow moving and fast moving objects.
It appears that you are using the /1000 versus any other value for some unstated reason that may negate the following.
By changing this scale factor you get better detection with a fast object. Perform your same isApproaching() calculation except with a /(1000*N) instead of /1000. You will then has N times better sensitivity to know if they are approaching or not.
Related
I posted this question on the stack math site, but they are not too excited to see questions including programming. Anyway, now I am here :)
I have an object, which is located at MyTransform.position (Vector)
That object should follow the DesiredPosition (Vector), which is
moving in varius directions with a changing velocity
MaxDelayDistance (float) is the maximum distance my object is allowed
to have to the DesiredPosition.
DelayRecovery (float) are the seconds my object has in order to move
to the DesiredPosition if the MaxDelayDistance is reached.
Time.deltaTime (float) is a term we use to describe the time the last
frame update took. It's value is usually about 0.025f.
private Vector3 GetLerpedPosition(Vector3 DesiredPosition) {
//DesiredPosition now contains the goal
Vector3 dirToDesiredPosition = (DesiredPosition - MyTransform.position).normalized; //Direction to desired position
Vector3 lerpStart = DesiredPosition + (-dirToDesiredPosition * MaxDelayDistance); //Start the lerp at my farthest allowed position
float lerpCurrentT = Vector3.Distance(MyTransform.position, DesiredPosition) / Vector3.Distance(lerpStart, DesiredPosition); //My current fragtion (t) of the lerp
//Now I lerp from lerpStart to DesiredPosition using a calculated fraction
Vector3 result = Vector3.Lerp(
lerpStart,
DesiredPosition,
lerpCurrentT + (DelayRecovery / MaxDelayDistance * Vector3.Distance(MyTransform.position, DesiredPosition) * Time.deltaTime)
);
return result;
}
The main problem is that my object is not following the DesiredPosition smoothly.
It jumps from MaxDelayDistance to DesiredPosition and back.
Somehow the fraction (t) in my Lerp function always results in about 1.005 or about 0.001. Can you spot any problems in my approach?
I see several issue, and I'm not sure of the direction you have choose (at least never seen anything similar before).
Preamble:
Vector3.Distance(lerpStart, DesiredPosition)
this is a constant and is the radius around DesiredPosition.
Here's some problems I noticed:
Problem 1
lerpT is always >=1 for every point more distant more than MaxDelayDistance (outside the radius). So when an object is further distant than MaxDelayDistance it will be immediately moved to DesiredPosition.
Problem 2
DelayRecovery (float) are the seconds my object has in order to move
to the DesiredPosition if the MaxDelayDistance is reached.
Not sure of having completely understood your intricate lerp, btw the statement above seems to be false. DelayRecover is always taken in consideration while lerping despite its distance.
Problem 3
Possible division by zero when you are closed to DesiredPosition (* operator is evaluated before /)
Some considerations
I'll read with more attention your code, and I'll try to figure out the logic behind that. It's something I've never seen.
Some general approach for moving toward a given position:
If start and destination are known and fixed, than lerping (or an ease function) allow to control exactly the travel time incrementing t parameter from 0 to 1.
If destination is moving you can still smooth follow the target using lerp (maybe not the more correct use from a theoretical point of view, nor physical realistic but in any case effective). Lerp factor in this case is a kind of "speed toward the goal". Effectively linear proportional to the distance from the target.
Some physic based approach. Integrate. Define some kind of max speed and max acceleration and calculate the next position (eventually clamp to prevent overshooting and oscillation)
PID controllers. Lot of power, but I always found them hard to tweak.
Consider also to use Vector3.MoveToward, here's how it's implemented:
public static Vector3 MoveTowards(Vector3 current, Vector3 target, float maxDistanceDelta)
{
Vector3 a = target - current;
float magnitude = a.magnitude;
if (magnitude <= maxDistanceDelta || magnitude == 0f)
{
return target;
}
return current + a / magnitude * maxDistanceDelta;
}
Hope this helps.
Im trying to optimize my skeletal animation system by using tracks (curve) instead of keyframe. Each curve take care of a specific component then (for now) I linearly interpolate the values. Work fine for my bone positions, however Im having a hard time getting rid of the "jagyness" of the quaternion component interpolation...
Basically I have 1 curve for each component (XY and Z) for each bones quaternion and I use the following code to interpolate the XY and Z curves independently:
// Simple lerp... (f is always a value between 0.0f and 1.0f)
return ( curve->data_array[ currentframe ].value * ( 1.0f - f ) ) +
( curve->data_array[ nextframe ].value * f );
When I interpolate the quaternion XYZ then I use the following code to rebuild the W component of the quaternion before normalizing it and affecting it to my bone before drawing:
Quaternion QuaternionW( const Quaternion q )
{
Quaternion t = { q.x, q.y, q.z };
float l = 1.0f - ( q.x * q.x ) - ( q.y * q.y ) - ( q.z * q.z );
t.w = ( l < 0.0f ) ? 0.0f : -sqrtf( l );
return t;
}
The drawing look fine at the exception that the bones become all jerky from time to time, would it be due to the floating point precision? Or the recalculation of the W component? Or there is absolutely no way I can linearly interpolate each component of a quaternion this way?
ps: On a side note, in my curve interpolation function if I replace the code above with:
return curve->data_array[ currentframe ].value;
instead or linearly interpolating, everything is fine... So the data is obviously correct... Im puzzled...
[ EDIT ]
After more research I found that the problem comes from the frame data... I got i.e. the following:
Frame0:
quat.x = 0.950497
Frame1:
quat.x = -0.952190
Frame2:
quat.x = 0.953192
This is what causes the inversion and jaggyness... I tried to detect this case and inverse the sign of the data but it still doesn't fix the problem fully as some frame now simply look weird (visually when drawing).
Any ideas how to properly fix the curves?
Your data are probably not wrong. Quaternion representations of orientation have the funny property of being 2x redundant. If you negate all four elements of a quaternion, you're left with the same orientation. It's easy to see this if you think of the quaternion as an axis/angle representation: Rotating by Θ around axis a, is the same as rotating by -Θ around axis -a.
So what should you do about it? As mentioned before, slerp is the right thing to do. Quaternion orientations exist on the unit hypersphere. If you linearly interpolate between points on a sphere, you leave the sphere. However, if the points are close by each other, it's often not a big deal (although you should still renormalize afterward). What you absolutely do need to make sure you do is check the inner-product of your two quaternions before interpolating them: e.g.,
k=q0[0]*q1[0] + q0[1]*q1[1] + q0[2]*q1[2] + q0[3]*q1[3];
If k<0, negate one of the quaternions: for (ii=0;ii<4;++ii) q1[ii]=-q1[ii]; This makes sure that you're not trying to interpolate the long way around the circle. This does mean, however, that you have to treat the quaternions as a whole, not in parts. Completely throwing away one component is particularly problematic because you need its sign to keep the quaternion from being ambiguous.
Naive considerations
Linear interpolation is fine for things that operate additively, i.e. that add something to something else every time you execute the corresponding operation. Queternions, however, are multiplicative: you multiply them to chain them.
For this reason, I originally suggested computing the following:
pow(secondQuaternion, f)*pow(firstQuaternion, 1. - f)
Wikipedia has a section on computing powers of quaternions, among other things. As your comment below states that this does not work, the above is for reference only.
Proper interpolation
Since writing this post, I've read a bit more about slerp (spherical linear interpolation) and found that wikipedia has a section on quaternion slerp. Your comment above suggests that the term is already familiar to you. The formula is a bit more complicated than what I wrote above, but it is still rather related due to the way it uses powers. I guess you'd do best by adapting or porting an available implementatin of that formula. This page for example comes with a bit of code.
Fixing data
As to your updated question
Any ideas how to properly fix the curves?
Fixing errors while maintaining correct data requires some idea of what kinds of errors do occur. So I'd start by trying to locate the source of that error, if at all possible. If that can be fixed to generate correct data, then good. If not, it should still give you a better idea of what to expect, and when.
I would like to create a "Gravity Grid" such as in this image:
The closest I have been in creating this grid is shown in this image:
I'm only warping the lines parallel to the Y-Axis until I can solve this problem. But as you can see in the picture, the lines seem to be warping past my "planet".
Here is the code of interest I have for now:
for (each point on a line parallel to the y-axis) {
if (planetPosition.x > currrentPoint.x) {
warpedXPos = currrentPoint.x + (1 / (distance*1000));
}
else {
warpedXPos = currrentPoint.x - (1 / (distance*1000));
}
}
The idea is to pull every point towards the planet by an amount proportional to 1/R, where R is the distance from the planet to the point.
In your code you currentPoint.x, etc, is the absolute position, but you need to warp the position relative to the planet. Therefore your equation should look like:
warped.x = currrentPoint.x + (planetPosition.x-currrentPoint.x)/(1000*distance)
The part after the + is the scaling of the relative distance basically your warp, and then you add this deflection to the original absolute value. You probably also won't want to use the 1000 factor, but this is just keeping with your example. Also, note that there's no need to break this into cases using the >, the sign of the subtraction should make the adjustment in the appropriate direction.
(By the way, this type of operation is super common... first you subtract an absolute factor, then you scale, then you add the original factor back in. It's a trick worth memorizing for use in lots of applications.)
So I have a ship, that has thrusters at the bottom and that can only use these to move forward. It can also rotate itself around its center. Its thrusters gives it acceleration, so it doesn't move at a constant velocity. What I want to do is to tell it "move to point B".
I have come up with a solution but it doesn't work very well and it doesn't rotate smoothly, it moves jerkily and it doesn't end up exactly where it should be, so I have to have a big margin of error.
Is this a normal problem, and if so is there a "standard" way of doing it? Is this an easy problem? I want to make it look like the ship is steering itself to that point, using the constraints (thrusters, rotation) the player has. This excludes just lerping it from point A to B. Or does it?
I'd love some help in solving this problem. Positions are stored in vectors, and it's a 2D problem. Just for reference I'm including my solution, which basically is accelerating the ship until and rotating it to point to the point. I think my implementation of this idea is the problem:
Vector diff = vector_sub(to_point, pos);
float angle = vector_getangle(diff);
float current_angle = vector_getangle(dir);
float angle_diff = rightrange(angle) - rightrange(current_angle);
float len = vector_getlength(diff);
// "Margin of error"
float margin = 15.0;
// Adjust direction, only if we're not stopping the next thing we do (len <= margin)
if ( len > margin && fabs(angle_diff) > 2.0 )
{
dir = vector_setangle(dir, current_angle + (angle_diff)*delta*(MY_PI) - MY_PI/2);
}
else if ( len > margin )
{
dir = vector_normalize(diff);
}
// accelerate ship (if needed)
acc.x = acc.y = speed;
acc = vector_setangle(acc, vector_getangle(dir));
if ( len <= margin )
{
// Player is within margin of error
}
If you are not looking for a very general solution that works online, then there is a simple solution. What I mean by online is continuously re-calculating the actions along the complete trajectory.
Assuming the ship is at rest at start, simply rotate it towards your target point (while still at rest). Now, your ship can reach the target by accelerating for t seconds, rotating back while in motion (for 0.5 seconds as per your constraint), and decelerating for another t seconds. If the distance between current point and destination is d, then the equation you need to solve is:
d = 0.5*a*t^2 + 0.5*a*t + 0.5*a*t^2
The first term is distance traveled while accelerating. The second term is distance traveled while rotating (v*t_rot, v=a*t, t_rot=0.5). The final term is the distance traveled while decelerating. Solve the above for t, and you have your trajectory.
If the ship is moving at start, I would first stop it (just rotate in opposite direction of its speed vector, and decelerate until at rest). Now we know how to reach destination.
The problem with offline trajectory calculation is that it is not very accurate. There is a good chance that you will end up in the vicinity of the target, but not exactly on top of it.
Let's make the problem a little more interesting: the ship cannot rotate without acceleration. Let's call this acceleration vector a_r, a vector that is at a certain angle against the ship's direction (somewhat like having a thruster at an angle at the back). Your task now is to rotate the ship and accelerate in such a direction that the speed component perpendicular to the vector connecting the current position to the target is canceled out. Instead of trying to calculate the vectors offline, I would go with an online approach with this.
The easiest thing to do would be to add the following algorithm calculated at every time interval:
Calculate the vector pointing from ship to destination.
Split your current speed vector into two components: towards the destination, and perpendicular to it.
If perpendicular speed is zero, skip 4
Start rotating towards the negative of the perpendicular vector's direction. If already looking away from it (not exact opposite, but just looking away), also fire main thruster.
This will oscillate a bit, I suspect it will also stabilize after a while. I must admit, I don't know how I would make it stop at destination.
And the final approach is to model the ship's dynamics, and try to linearize it. It will be a non-linear system, so the second step will be necessary. Then convert the model to a discrete time system. And finally apply a control rule to make it reach target point. For this, you can change your state-space from position and speed to error in position and (maybe) error in speed, and finally add a regulation control (a control loop that takes the current state, and generates an input such that the state variables will approach zero).
This last one is fairly difficult in the maths compartment, and you'd probably need to study control engineering a bit to do it. However, you'll get much better results than the above simplistic algorithm - which admittedly might not even work. In addition, you can now apply various optimization rules to it: minimize time to reach target, minimize fuel consumption, minimize distance traveled, etc.
I have a 2D surface ( Grid ) with 50 elements at different locations.
I need to decide which are the 10 closest elements to a given point.
In addition, the given point is constantly moving and i need to do the calculation on each movement.
I know I can calculate the Euclidean distance to each point on each movement, but I want a faster way.
Thanks.
It sounds like you're trying to come up with a way where you can take the 10 closest points at time t and use those to help you figure out the 10 closest at time t+1. Here's an idea to consider.
When you calculate the 10 closest points, also store the angular direction of where they are relative to your current location. Then, when you move you can calculate the direction in which you moved. Focus your search on the space that's opened up to you (think of a circle around point A and another around point B. The space in B but not in A is where you want to focus your search).
Of course, to do this you need to have some way of searching in a particular area of the grid instead of doing a linear search through an array of points to find those close to you. I'd recommend looking into BSP trees for that. If you're not doing it already, using BSP trees instead of linear search might alone be the performance boost you're looking for.
So, I am going to put all the attempts that I went over to figure out my implementation and hopefully you will be able to figure out the best approach for you project.
I am working on somewhat similar project to what you have mentioned. But in my case I need to do extra cycles once I found the points within a given distance threshold. I have tried few iterations, first I started by creating a distance grid. Keep in mind, I am not working on 2D surface but I don't think changing this to 2D will take much work.
Here is how I developed my distance grid (its so simple even a cave man can do it, I making fun of myself) , Also keep in mind I didn't continue using the grid to finish up my implementation.
public double[][] distanceGrid() {
double[] gridSize = combineArrays(generateClusters(1, 3), generateClusters(12, 15));
double [][] pointsDistanceGrid = new double[gridSize.length][gridSize.length];
for (int i = 0; i < pointsDistanceGrid.length; i++) {
for (int j = 0; j < pointsDistanceGrid[i].length; j++) {
pointsDistanceGrid[i][j] = Math.abs(gridSize[i] - gridSize[j] );
System.out.print(" " + pointsDistanceGrid[i][j]);
}
System.out.println("");
}
return pointsDistanceGrid;
}
As I mentioned I didn't use it.
Since I had to deal with a distance threshold, and I decided before finding "The Nearest" i wanted to see all the points that are closer to the particular point that I am looking at, so I implemented this method.
/**
* Given a point method returns an array with point that are within the limit of threshold.
* #param point
* #return
*/
public double[] pointsWithinThreshold(double point) {
double[] neighbors = new double[bigCluster.length];
for (int i = 0; i < bigCluster.length; i++) {
if (bigCluster[i] != point) {
double distance = 0;
distance = Math.abs(point - bigCluster[i]);
if (distance <= getDistanceThreshold()) {
neighbors[i] = bigCluster[i];
}
}
}
return neighbors;
}
After this I realize I don't really care what are all the closest points so I end up not using this and refractor some of this functionalities to a method where I get the closest member and do recursive DFS.
Let me know if you would like to see that, I didn't put it here coz I thought you only need to know the closest 10 member.
Hope this helps and good luck.