Imagine two coordinate systems layed on top of each other, with a rotation and scale difference between the two:
The problem is to convert a point from the non-rotated system to the other. What we do have, are four corner points forming a rectangle, with coordinates known for both systems at each point. We also know the rotation difference, and I think I at least should know the scale difference too. How do I convert a point from the non-rotated system to the rotated system? I have Unity3D at use.
Extra points for clarity in math :)
PS: I'm writing this really late, going to edit later for more clarity.
Some linear algebra does the trick:
Express each operation as a matrix and matrix multiply those to combine them into a single resulting matrix (for efficiency).
If translation is involved you need to add a dimension to your matrices, see homogenous coordinates.
The reason is that the mappings are affine ones then, not linear ones. You can ignore the extra dimension in the end result. It is just a nice way to embed affine mappings into linear ones, so the algebra is easier.
Example
M = M_trans * M_rot * M_scale
x' = M x
The order here is right to left: vector x is first scaled, then rotated, then translated into vector x'. (Using column vectors).
Hints on the matrices: Rotation Matrix, Scaling Matrix
For deriving 2D formulas when given 3D ones: either keep z = 0 or delete the 3rd row and 3rd column from each matrix.
Related
I am trying to rotate a model in 3D so that it faces the right direction. The rotation I want is fairly trivial and can be broken down into two steps:
Rotate the model 90 degrees on its x-axis.
Rotate the model 180 degrees on its z-axis (relative to the first rotation).
The way to set a model's rotation in the framework I'm using (openFrameworks) is by calling its setRotation method. This method takes an angle, as well as floats x, y and z that specify the axis of rotation. How do I calculate the axis of rotation and angle for this particular rotation? I can't rotate the model two times sequentially because any call to setRotation overwrites previous rotations.
Please let me know if I can provide more information or clarity.
EDIT: In case anyone has the same question, this post helped me a lot.
weird that you can not apply more then one transform ... maybe you just use wrong function but anyway:
If you have direct access to transform matrix (or by get,set)
google for transform matrices if you do not have the knowledge
I suspect you are using 4x4 homogenous cartesian transform matrices
transform matrix anatomy
generate first rotation matrix and store it to M1
can use the setRotation for that
generate second rotation matrix and store it to M2
multiply them M=M1*M2
use this M instead of setRotation
If yo do not have the direct access to transform matrix and have to use just the setRotation
in that case you have to use quaternion which is the 4D vector you call the setRotation with
google for quaternion math and find the application of 2 rotations
I do not use them so I can not help with that but there are also equations out there
which converts 3x3 rotation matrix into quaternion and back
so you can still use the algorithm above
obtain M
extract the rotation matrix from it (it is just sub matrix you omit last row and column)
compute quaternion from it
and call setRotation with the result
I'm working in OpenCV but I don't think there is a function for this. I can find a function for finding affine transformations, but affine transformations include scaling, and I only want to consider rotation + translation.
Imagine I have two sets of points in 2d - let's say each set has exactly 50 points.
E.g. set A = {x1, y1, x2, y2, ... , x50, y50}
set B = {x1', y1', x2', y2', ... , x50', y50'}
I want to find the rotation and translation combination that gets closest to mapping set A onto set B. I guess I would define "closest" as minimises the average distance between points in A and corresponding points in B. I.e., minimises the average distance between (x1, y1) and (x1', y1'), etc.
I guess I could use brute force testing all possible translations and rotations but this would be extremely inefficient. Does anyone know a simpler way?
Thanks!
This problem has a very elegant solution in terms of singular value decomposition of the proximity matrix (distances between pairs of points). The name of this is the orthogonal Procrustes problem, after the Greek legend about a fellow who offered travellers a bed that would fit anyone.
The solution comes from finding the nearest orthogonal matrix to a given (not necessarily orthogonal) matrix.
The way I would do it in Excel is to make a couple columns representing the points.
Cells representing rotation/translation of a set (no need to rotate and translate both of them).
Then columns representing those same points rotated/translated.
Then another column for the distance between the points of the rotated/translated points.
Then a cell of the sum of the distances between points.
Finally, use Solver to optimize the rotation and translation cells.
If you fix some rotation you can get an answer using ternary search. Run search in x and for every tested x run it in y to get the best value. This will give you the correct answer since the function (sum of corresponding distances) is convex (this can be proved through observing that restriction of the function to any line is a one-dimensional convex function; and the last is a standard fact: the sum of several convex functions is convex).
Instead of brute force over the angle I can propose such a method based on the ternary search. Choose some not very large step S. Compute the target function for every angle in (0, S, 2S,...). Then, if S is small enough, we can exclude some of segments (iS, (i + 1)S) from consideration. Namely ones with relatively large values of function with angles iS and (i + 1)S. Being implemented carefully this can give an answer and can do it faster than brute force.
I'm programming a physics game. It seems I can use 2 systems for storing a character's movement data:
A) x & y components (Cartesian coordinates)
B) speed and direction components (polar coordinates)
It seems I need to ultimately decide on one of these 2 systems because:
A) They both represent the same information about a vector
B) It seems redundant and inefficient to maintain both
Most game programming resources I've found use Cartesian. To my understanding, all transformations like friction, rotation, acceleration, etc are combined into each vector via multiplication, division, etc. But to me, polar feels more modular and, therefore, more malleable because each vector is comprised of and can be broken down into its two elements (direction and magnitude). If I want to modify one of these independently, I can set its value without needing to deconstruct it into separate parts.
I'm guessing that different models are suitable for different types of games. But...
What trade-offs affect the decision to use Cartesian versus polar?
When does one model become cumbersome or verbose?
Or am I way off?
The premise of your question is a bit odd. Magnitude plus angle and sum of 2 basis components are both ways to specify a vector in 2-space. In either case, you record 2 scalars (i.e. you do not have a separate variable to represent the x unit vector). The choice of rectangular vs polar coordinates doesn't change the nature of something from a vector to a scalar or vice versa.
However, different representations certainly have their uses. As you mention, breaking down into orthogonal components has a ready advantage for addition of two vectors and other operations. In addition, most displays use a x-y coordinate system, so rendering is easier because you don't have to do a coordinate transform.
If your game was based on a polar coordinate system (say a ship that always faces the center of a circle), you might actually want to represent it using polar coordinates. Other than that, rectangular coordinates are generally easier to use.
Either way, sin and cos will probably become your friend. Just remember that most graphical coordinate systems have y-down as positive.
You are confused about the difference between vectors and scalars.
The speed along the x-axis is a scalar.
The speed along the y-axis is also a scalar.
When you combine those two numbers into a single mathematical object, that object is the velocity vector. Think of it like a 2-element array: [x, y]
Similarly,
Thrust is a scalar.
Angle is a scalar.
The combination of these two numbers is a different kind of velocity vector [thrust, angle].
Any velocity that is expressable in your [x, y] system can be also expressed in your [thrust, angle] system.
You might be getting confused with "basis vectors." In your first coordinate system, a basis vector is a vector that is one unit long and which points along the x or y axis. So [1, 0] would be a basis vector that is one-unit along the x axis, and [0, 1] would be a basis vector that is one unit along the y axis. The thing that is interesting about basis vectors is that any vector at all can be expressed as a linear combination of basis vectors.
So if i = [1, 0], and j = [0, 1] then
(34.5 i + -4.45 j) is a vector,
(4.65 i + 23.3 j) is a vector,
etc. (if you're not familiar with vector addition, just google it, it's easy)
Now you might think that when take your 2-dimensional space and you use a different coordinate system (like polar coordinates, which is really what your thrust/angle coordinates are) you are getting away from basis vectors, but in fact you are not. So, for your thrust and angle coordinate system, your basis vectors are:
i = 1 unit of positive thrust, or radius
and
j = 1 degree (or radian) of positive angle
Any possible velocity is still a combination of i and j, your basis vectors.
The two representations are mathematically equivalent. Additionally, converting one to the other is a simple O(1) operation. So be aware that it's probably not a make-or-break decision. That said, in terms of ease-of-use:
You're probably right that it depends on the circumstance as to which is more appropriate, so whichever you can foresee yourself using more often, then go with that, and convert to the other form when necessary.
Use language features to help you abstract the specific type of implementation. E.g. If you're using Java, have a IPoint interface with the relevant methods. That way you can choose an implementation, or even more, to suit the needs. You can even choose certain parts of the program to work with one implementation, and other parts with other types. Proper architecture will make these things seemless.
Depending on certain calculations you might prefer to use ones that will provide you with more accuracy. If you're doing floating point arithmetic with vastly different magnitudes you might suffer precision loss. In that case it may, for example, be easier to use the angle and length representation, because angles will have persistent accuracy, and lengths might be of similar magnitude, whereas there is no guarantee of such in the x and y representation. Although granted that this is a slightly less pressing issue if you're values will be reasonable and calculations nominal.
What you're calling "scalar quantities" is really just a polar vector, right? So your question isn't so much about vectors vc scalars as it is about cartesian vs polar coordinate systems. [x,y] and [theta,r] are both vectors.
I haven't done a whole lot of physics programming, but the last time I did and it started to get complicated (modeling fish swimming in a three-dimensional space), I was much more comfortable dealing with polar coordinates. I was working from scratch implementing a boids-like algorithm, and I found it much more straightforward to think in terms of polar vectors, especially when working in 3 dimensions. I also found using trigonometric functions (acos(), asin(), etc.) cleaner than using the pythagorean formulae you'd use in a cartesian system.
But are you actually coding things from such a low level?
The dynamics of a system are usually easier to describe in the (point, velocity) framework. Indeed, the "fundamental" ODE is usually described in this system:
d (mv) / dt = force(x)
and hence are also easier to plug into a black box Runge Kutta solver.
However, any system will do, thanks to canonical transformations.
Does a 3D vector differ from a 3D point tuple (x,y,z) in the context of 3D game mathematics?
If they are different, then how do I calculate a vector given a 3d point?
The difference is that a vector is an algebraic object that may or may not be given as the set of coordinates in some space. (thanks to bungalobill for correcting my sloppiness).
A point is just a point given by coordinates. Generally, one can conflate the two. If you are given a set of coordinates, and told that they constitute a 'point' with no further information (choice of basis, etc), then you can just hand that set of numbers back and legitimately claim to have produced a vector.
The largest difference between the two is that it makes no sense to do things to one that you can do to the other. For example,
You can add vectors: <1 2 3> + <3 2 1> = <4 4 4>
You can multiply (or scale) a vector by a number (generally called a scalar)
2 * <1 1 1> = <2 2 2>
You can ask how far apart two points are: d((1, 2, 3), (3, 2, 1) = sqrt((1 - 3)2 + (2 - 2)2 + (3 - 1)2) = sqrt(8) ~= 2.82
A good intuitive way to think about the association between a vector and a point is that a vector tells you how to get from the origin (that one point in space to which we assign the coordinates (0, 0, 0)) to its associated point.
If you translate your coordinate system, then you get a new vector for the same point. Although the coordinates that make up the point will undergo the same translation so it's a pretty easy conflation to make between the two.
Likewise if rotate the coordinate system or apply some other transformation (e.g. a shear), then the coordinates and vector associated to the point will also change.
It's also possible for a vector to be something else entirely, for example a bounded function on the interval [0, 1] is a vector because you can multiply it by a real number and add it to another function on the interval and it will satisfy certain requirements (namely the axioms of a vectorspace). In this case one thinks of having one coordinate for each real number, x, in [0, 1] where the value of that coordinate is just f(x). So that's the easiest example of an infinite dimensional vector space.
There are all sorts of vector spaces and the notion that a vector is a 'point and a direction' (or whatever it's supposed to be) is actually pretty vacuous.
A vector represents a change from one state to another. To create one, you need two states (in this case, points), and then you subtract the initial state from the final state in order to get the resultant vector.
Vectors are a more general idea that a point in 3D space.
Vectors can have 2, 3, or n dimensions. They represent many quantities in the physical world (e.g., velocity, force, acceleration) besides position.
A mathematician would say that a vector is a first order tensor that transforms according to this rule:
u(i) = A(i, j)v(j)
You need both point and vector because they are different. A point in 3D space denoting position is a vector, but every vector is not a point in 3D space.
Then there's the computer science notion of a vector as a container - it's an abstraction for an array of values or references. This is a different concept from a mathematician's idea of a vector, because every vector container need not obey the first order tensor transformation law (e.g. a Vector of OrderItems). That's yet another separate idea.
It's important to keep all these in mind when talking about vectors and points.
Does a 3D vector differ from a 3D point tuple (x,y,z) in the context of 3D game mathematics?
Traditionaly vector means a direction and speed. A point could be considered a vector from the world orgin of one time step. (even though it may not be considered mathematically pure)
If they are different, then how do I calculate a vector given a 3d point?
target-tower is the common mnemonic.
Careful on your usage of this. The resulting vector is really normal*velocity. If you want to change it into something useful in a game application: you will need to normalize the vector first.
Example: Joe is at (10,0,0) and he wants to go to (10,10,0)
Target-Tower: (10,10,0)-(10,0,0)=(0,10,0)
Normalize the resulting vector: (0,1,0)
Apply "physics": (0,1,0) * speed*elapsed_time < speed = 3 and we'll say that the computer froze for a whole 2 seconds between the last step and this one for ease of computation >
=(0,6,0)
Add the resulting vector to Joes current point in space to get his next point in space: ... =(10,6,0)
Normal = vector/(sqrt(x*x+y*y+z*z))
...I think I have everything here
Vector is the change in the states. A point is the static point. Two vectors can be parallel or perpendicular. You can have product of two vectors which is a third vector. You can multiply a vector by a constant. You can add two vectors.
All these operations are not allowed on point. So program wise if you think both as a C++ class, there will be many such methods in the vector class but probably only Get and Set for point.
In the context of game mathematics there is no difference.
Points are elements of an affine space.† Vectors are elements of a vector (aka linear) space. When you choose an origin in an affine space it automatically induces a linear structure on that affine space. The contrary is also true: if you have a vector space it already satisfies all the axioms of an affine space.
The fact is that when it comes to computation, the only way to represent an affine space numerically is to use tuples of numbers, which also form a vector space.
Each object in a game always has an origin, and it is crucial to know where it is. That origin is set relative to the origin of the world, which is set relative to the origin of the camera/viewport. The vertices of the object are represented as vectors -- offsets from the object origin. You use matrix multiplication to transform the objects -- that is too a purely vector space operation (you cannot multiply an affine point by a matrix without specifying the origin first). Etc, etc... As we see all those triplets of numbers that we might think of as 'points' are actually vectors in the local coordinate system.
So is there any reason to distinguish between the two outside the study of algebra? It is an unnecessary abstraction, and unnecessary abstractions are harmful (KISS). So my answer is no, just go with a single vector type.
† Or any topological space outside the context of game development.
A vector is a line, that is a sequence of points but that it can be represented by two points, the starting and the ending point.
If you take the origin as the starting point, then you can describe your vector giving only the ending point.
I'm looking for a way to determine the optimal X/Y/Z rotation of a set of vertices for rendering (using the X/Y coordinates, ignoring Z) on a 2D canvas.
I've had a couple of ideas, one being pure brute-force involving performing a 3-dimensional loop ranging from 0..359 (either in steps of 1 or more, depending on results/speed requirements) on the set of vertices, measuring the difference between the min/max on both X/Y axis, storing the highest results/rotation pairs and using the most effective pair.
The second idea would be to determine the two points with the greatest distance between them in Euclidean distance, calculate the angle required to rotate the 'path' between these two points to lay along the X axis (again, we're ignoring the Z axis, so the depth within the result would not matter) and then repeating several times. The problem I can see with this is first by repeating it we may be overriding our previous rotation with a new rotation, and that the original/subsequent rotation may not neccesarily result in the greatest 2D area used. The second issue being if we use a single iteration, then the same problem occurs - the two points furthest apart may not have other poitns aligned along the same 'path', and as such we will probably not get an optimal rotation for a 2D project.
Using the second idea, perhaps using the first say 3 iterations, storing the required rotation angle, and averaging across the 3 would return a more accurate result, as it is taking into account not just a single rotation but the top 3 'pairs'.
Please, rip these ideas apart, give insight of your own. I'm intreaged to see what solutions you all may have, or algorithms unknown to me you may quote.
I would compute the principal axes of inertia, and take the axis vector v with highest corresponding moment. I would then rotate the vertices to align v with the z-axis. Let me know if you want more details about how to go about this.
Intuitively, this finds the axis about which it's hardest to rotate the points, ie, around which the vertices are the most "spread out".
Without a concrete definition of what you consider optimal, it's impossible to say how well this method performs. However, it has a few desirable properties:
If the vertices are coplanar, this method is optimal in that it will always align that plane with the x-y plane.
If the vertices are arranged into a rectangular box, the box's shortest dimension gets aligned to the z-axis.
EDIT: Here's more detailed information about how to implement this approach.
First, assign a mass to each vertex. I'll discuss options for how to do this below.
Next, compute the center of mass of your set of vertices. Then translate all of your vertices by -1 times the center of mass, so that the new center of mass is now (0,0,0).
Compute the moment of inertia tensor. This is a 3x3 matrix whose entries are given by formulas you can find on Wikipedia. The formulas depend only on the vertex positions and the masses you assigned them.
Now you need to diagonalize the inertia tensor. Since it is symmetric positive-definite, it is possible to do this by finding its eigenvectors and eigenvalues. Unfortunately, numerical algorithms for finding these tend to be complicated; the most direct approach requires finding the roots of a cubic polynomial. However finding the eigenvalues and eigenvectors of a matrix is an extremely common problem and any linear algebra package worth its salt will come with code that can do this for you (for example, the open-source linear algebra package Eigen has SelfAdjointEigenSolver.) You might also be able to find lighter-weight code specialized to the 3x3 case on the Internet.
You now have three eigenvectors and their corresponding eigenvalues. These eigenvalues will be positive. Take the eigenvector corresponding to the largest eigenvalue; this vector points in the direction of your new z-axis.
Now, about the choice of mass. The simplest thing to do is to give all vertices a mass of 1. If all you have is a cloud of points, this is probably a good solution.
You could also set each star's mass to be its real-world mass, if you have access to that data. If you do this, the z-axis you compute will also be the axis about which the star system is (most likely) rotating.
This answer is intended to be valid only for convex polyhedra.
In http://203.208.166.84/masudhasan/cgta_silhouette.pdf you can find
"In this paper, we study how to select view points of convex polyhedra such that the silhouette satisfies certain properties. Specifically, we give algorithms to find all projections of a convex polyhedron such that a given set of edges, faces and/or vertices appear on the silhouette."
The paper is an in-depth analysis of the properties and algorithms of polyhedra projections. But it is not easy to follow, I should admit.
With that algorithm at hand, your problem is combinatorics: select all sets of possible vertexes, check whether or not exist a projection for each set, and if it does exists, calculate the area of the convex hull of the silhouette.
You did not provide the approx number of vertex. But as always, a combinatorial solution is not recommended for unbounded (aka big) quantities.