I have calculated an axis angle rotations for each axis. If I only apply one of the three rotations, the objects rotates as expected.
If I multiply the rotation matrixes, as you would normally do it if you combine rotations I don't get the desired result, cause the first rotation affects the others and therefore the end result is not what I'm looking for.
I want to apply each rotation to the object as if it wasn't rotated before.
I guess this is a simple task, but it seems that I'm not searching for the right keywords. (Also the title is not perfect ... (open for suggestions))
Thanks for every hint / help.
You're experiencing gimbal lock. It's not a maths problem, it's a logical fallacy. Try it with, for the sake of description, your phone:
put it on your desk face up, with the charging connector at the bottom.
rotate clockwise around z by 90 degrees. So the charging connector is now to the left.
rotate around x (which will be the longer axis of the phone assuming the charging port is on the top or bottom) by 180 degrees.
the phone is now upside down, with the charging port on the left.
But:
put it on your desk face up, with the charging connector at the bottom.
rotate around x by 180 degrees. So the charging connector is now at the top.
rotate clockwise around z by 90 degrees.
the phone is now upside down, with the charging port on the right.
Which of those is incorrect if the instruction was to rotate 180 degrees around x and 90 degrees clockwise around z? Neither is incorrect. The instructions were ambiguous.
The order of individual rotations always matters, because the second affects the work done in the first, the third affects the work done in the first and second, etc. Shuffling the order just changes which affects which.
Orientation is normally stored directly as a matrix or as a quaternion because it's unambiguous and because it keeps the order of actions properly ordered.
Just stumbled into this question searching for something slightly different. Long story short, you are likely multiplying your matrices in reversed order.
Chaining rotations is a little counter-intuitive. If you have a chain of rotations R1*R2*R3*R4 then you have two ways to conceptualize what is happening: intrinsic and extrinsic.
The intrinsic view works from right to left. You start with R4 and work your way to R1. R4 takes the initial frame and produces a new frame that is rotated around R4's rotation axis. R4's axis is specified in the initial frame. R3 takes this rotated frame and rotates it around R3's rotation axis. Here, R3's axis is specified in R4's rotated frame. This continues down the chain, each time changing the frame in which the rotation axis is expressed.
The extrinsic view works from left to right. You start with R1 and work your way to R4. The output frame of R1 is rotated around R1's axis. R1's axis is expressed in the initial frame. R2 then takes both, R1's output frame and R2's output frame and rotates both around R2's axis. R2's axis is again expressed in the initial frame. This continues up the chain, each time rotating all the
previous frames around some axis expressed in the initial frame.
Confused already? What's even better is that both ways are exactly equivalent. They are just two ways of looking at the same thing. As I said, chaining rotations are a little counter-intuitive.
The bottom line of it is though if you have a bunch of rotation matrices expressed in the initial reference frame, then the extrinsic view makes the most sense. If you want to first rotate around R1 then R2, etc. then your left-most matrix is the one that you want to rotate around last, i.e., you'd compute Rn*Rn-1*...*R3*R2*R1
Composition of rotation matrix isn't something trivial. I would recommend expressing your rotation matrix as quaternions. Quaternions have very useful properties. Multiplying two quaternions will give a 3rd quaternion which, put back into matrix form, is the exact composition of both input matrix. I think Boost libraries have code for that, but I haven't used it personally.
edit: you can get a rot matrix from (normalized) axis vector and rotation angle. look at this article on wikipedia
Related
I'm trying to calculate the axis of rotation of a ball which is moving and spinning at the same time, i.e. I want the vector along the axis that the ball is spinning on.
For every frame I know the x, y and z locations of 3 specific points on the surface of the sphere. I assume that by looking at how these 3 points have moved in successive frames, you can calculate the axis of rotation of the ball, however I have very little experience with this kind of maths, any help would be appreciated!
You could use the fact that the direction a position vector moves in will always be perpendicular to the axis of rotation. Therefore, if you have two position vectors v1 and v2 at successive times (for the same point), use
This gives you an equation with three unknowns (the components of w, the rotation axis). If you then plug in all three points you have knowledge of you should be able to solve these simultaneous equations and work out w.
I am writing 3D app for OpenGL ES 2.0 where the user sets a path and flies over some terrain. It's basically a flight simulator on rails.
The path is defined by a series of points created from a spline. Every timeslice I advance the current position using interpolation i.e. I interpolate between p0 to p1, then when I reach p1 I interpolate between p1 and p2, then finally back from pN to p0.
I create a view matrix with something analogous to gluLookAt. The eye coord is the current position, the look at is the next position along the path and an up (0, 0, 1). So the camera looks towards where it is flying to next and Z points towards the sky.
But now I want to "bank" as I turn. i.e. the up vector is not necessarily directly straight up but a changes based on the rate of turn. I know my current direction and my last direction so I could increment or decrement the bank by some amount. The dot product would tell me the angle of turn, and the a cross product would tell me if its to the left or right. I could maintain a bank angle and keep it within the range -/+70 degrees, incrementing or decrementing appropriately.
I assume this is the correct approach but I could spend a long time implementing it to find out it isn't.
Am I on the right track and are there samples which demonstrate what I'm attempting to do?
Since you seem to have a nice smooth plane flying in normal conditions you don't need much... You are almost right in your approach and it will look totally natural. All you need is a cross product between 3 sequential points A, B, C: cross = cross(A-B, C-B). Now cross is the vector you need to turn the plane around the "forward" vector: Naturally the plane's up vector is (-gravitation) usually (0,0,1) and forward vector in point B is C-B (if no interpolation is needed) now "side" vector is side = normalized(cross(forward, up)) here is where you use the banking: side = side + cross*planeCorrectionParameter and then up = cross(normalized(side), normalized(forward)). "planeCorrectionParameter" is a parameter you should play with, in reality it would represent some combination of parameters such as dimensions of wings and hull, air density, gravity, speed, mass...
Note that some cross operations above might need swap in parameter order (cross(a,b) should be cross(b,a)) so play around a bit with that.
Your approach sounds correct but it will look unnatural. Take for example a path that looks like a sin function: The plane might be "going" to the left when it's actually going to the right.
I can mention two solutions to your problem. First, you can take the derivative of the spline. I'm assuming your spline is a f(t) function that returns a point (x, y, z). The derivative of a parametric curve is a vector that points to the rotation center: it'll point to the center of a circular path.
A couple of things to note with the above method: the derivative of a straight line is 0, and the vector will also be 0, so you have to fix the up vector manually. Also, you might want to fix this vector so it won't turn upside down.
That works and will look better than your method. But it will still look unnatural for some curves. The best method I can mention is quaternion interpolation, such as Slerp.
At each point of the curve, you also have a "right" vector: the vector that points to the right of the plane. From the curve and this vector, you can calculate the up vector at this point. Then, you use quaternion interpolation to interpolate the up vectors along the curve.
If position and rotation depends only on spline curvature the easiest way will be Numerical differentiation of 3D spline (you will have 2 derivatives one for vertical and one for horizontal components). Your UP and side will be normals to the tangent.
I'm trying to write a simple voxel raycaster as a learning exercise. This is purely CPU based for now until I figure out how things work exactly -- fow now, OpenGL is just (ab)used to blit the generated bitmap to the screen as often as possible.
Now I have gotten to the point where a perspective-projection camera can move through the world and I can render (mostly, minus some artifacts that need investigation) perspective-correct 3-dimensional views of the "world", which is basically empty but contains a voxel cube of the Stanford Bunny.
So I have a camera that I can move up and down, strafe left and right and "walk forward/backward" -- all axis-aligned so far, no camera rotations. Herein lies my problem.
Screenshots: (1) raycasting voxels while... ...(2) the camera remains... ...(3) strictly axis-aligned.
Now I have for a few days been trying to get rotation to work. The basic logic and theory behind matrices and 3D rotations, in theory, is very clear to me. Yet I have only ever achieved a "2.5 rendering" when the camera rotates... fish-eyey, bit like in Google Streetview: even though I have a volumetric world representation, it seems --no matter what I try-- like I would first create a rendering from the "front view", then rotate that flat rendering according to camera rotation. Needless to say, I'm by now aware that rotating rays is not particularly necessary and error-prone.
Still, in my most recent setup, with the most simplified raycast ray-position-and-direction algorithm possible, my rotation still produces the same fish-eyey flat-render-rotated style looks:
camera "rotated to the right by 39 degrees" -- note how the blue-shaded left-hand side of the cube from screen #2 is not visible in this rotation, yet by now "it really should"!
Now of course I'm aware of this: in a simple axis-aligned-no-rotation-setup like I had in the beginning, the ray simply traverses in small steps the positive z-direction, diverging to the left or right and top or bottom only depending on pixel position and projection matrix. As I "rotate the camera to the right or left" -- ie I rotate it around the Y-axis -- those very steps should be simply transformed by the proper rotation matrix, right? So for forward-traversal the Z-step gets a bit smaller the more the cam rotates, offset by an "increase" in the X-step. Yet for the pixel-position-based horizontal+vertical-divergence, increasing fractions of the x-step need to be "added" to the z-step. Somehow, none of my many matrices that I experimented with, nor my experiments with matrix-less hardcoded verbose sin/cos calculations really get this part right.
Here's my basic per-ray pre-traversal algorithm -- syntax in Go, but take it as pseudocode:
fx and fy: pixel positions x and y
rayPos: vec3 for the ray starting position in world-space (calculated as below)
rayDir: vec3 for the xyz-steps to be added to rayPos in each step during ray traversal
rayStep: a temporary vec3
camPos: vec3 for the camera position in world space
camRad: vec3 for camera rotation in radians
pmat: typical perspective projection matrix
The algorithm / pseudocode:
// 1: rayPos is for now "this pixel, as a vector on the view plane in 3d, at The Origin"
rayPos.X, rayPos.Y, rayPos.Z = ((fx / width) - 0.5), ((fy / height) - 0.5), 0
// 2: rotate around Y axis depending on cam rotation. No prob since view plane still at Origin 0,0,0
rayPos.MultMat(num.NewDmat4RotationY(camRad.Y))
// 3: a temp vec3. planeDist is -0.15 or some such -- fov-based dist of view plane from eye and also the non-normalized, "in axis-aligned world" traversal step size "forward into the screen"
rayStep.X, rayStep.Y, rayStep.Z = 0, 0, planeDist
// 4: rotate this too -- 0,zstep should become some meaningful xzstep,xzstep
rayStep.MultMat(num.NewDmat4RotationY(CamRad.Y))
// set up direction vector from still-origin-based-ray-position-off-rotated-view-plane plus rotated-zstep-vector
rayDir.X, rayDir.Y, rayDir.Z = -rayPos.X - me.rayStep.X, -rayPos.Y, rayPos.Z + rayStep.Z
// perspective projection
rayDir.Normalize()
rayDir.MultMat(pmat)
// before traversal, the ray starting position has to be transformed from origin-relative to campos-relative
rayPos.Add(camPos)
I'm skipping the traversal and sampling parts -- as per screens #1 through #3, those are "basically mostly correct" (though not pretty) -- when axis-aligned / unrotated.
It's a lot easier if you picture the system as a pinhole camera rather than anything else. Instead of shooting rays from the surface of a rectangle representing your image, shoot the rays from a point, through the rectangle that will be your image plane, into the scene. All the primary rays should have the same point of origin, only with slightly different directions. The directions are determined using basic trig by which pixel in the image plane you want them to go through. To make the simplest example, let's imagine your point is at the camera, and your image plane is one unit along the z axis, and two units tall and wide. That way, the pixel at the upper-left corner wants to go from (0,0,0) through (-1, -1, 1). Normalize (-1, -1, 1) to get the direction. (You don't actually need to normalize the direction just to do ray intersection, but if you decide not to, remember that your directions are non-normalized before you try to compute the distance the ray has travelled or anything like that.) For every other pixel, compute the point on the plane it wants to go through the way you've already been doing, by dividing the size of the plane by the number of pixels, in each direction.
Then, and this is the most important thing, don't try to do a perspective projection. That's necessary for scan-conversion techniques, to map every vertex to a point on the screen, but in ray-tracing, your rays accomplish that just by spreading out from one point into space. The direction from your start point (camera position, the origin in this example), through your image plane, is exactly the direction you need to trace with. If you were to want an orthographic projection instead (and you almost never want this), you'd accomplish this by having the direction be the same for all the rays, and the starting positions vary across the image plane.
If you do that, you'll have a good starting point. Then you can try again to add camera rotation, either by rotating the image plane about the origin before you iterate over it to compute ray directions, or by rotating the ray directions directly. There's nothing wrong with rotating directions directly! When you bear in mind that a direction is just the position your ray goes through if it starts from the origin, it's easy to see that rotating the direction, and rotating the point it goes through, do exactly the same thing.
A brief background: I'm working on a web-based drawing application and need to draw 1px thick splines that pass through their control points.
The issue I'm struggling with is that I need to draw each of the pixels between p1 and p2 as if I were using a 1px pencil tool. So, no anti-aliasing and one pixel at a time. This needs to be done manually without the use of any line/curve library code as my brush system depends upon having a pixel coordinate to apply the brush tip to the canvas.
Essentially, I need to combine the one pixel stepping from something like the Bresenham algorithm with the coordinates returned by the Catmull-Rom equation. I'm having trouble because the Catmull-Rom points are not uniformly distributed (so I can't just say there should be 100 pixels in the curve and run the equation 100 times). I tried using an estimated starting value of the maximum of the X and Y deltas and filling in the gaps with Bresenham, but due to rounding I still end up with some "dirty" sections (ie. the line is clearly moving up and to the right but I still get two pixels with the same Y component, resulting in a "fat" section of the line).
I'm positive this has been solved because nearly every graphics program that draws splines has to support the clean pixel curves that I'm after. After quite a bit of math research, though, I'm a bit confused and still without a solution. Any advice?
EDIT: Here's an example of a curve that I might have to render:
Which might have an expected result looking like this (note that this is an estimate):
Using the Catmull-Rom spline equation, we need four points to create a segment. P0 and P3 are used as tangents for incoming and outgoing direction from the P1->P2 segment. With a Catmull-Rom spline, the blue section is all that gets interpolated as t moves from 0 to 1. P0 and P3 can be duplicated to ensure that the green portion gets rendered, so that is not an issue for me.
For simplicity's sake, I need to render the pixels on the curve between P1 and P2, given that I have tangents in the form of P0 and P3. I don't necessarily need to use Catmull-Rom splines, but they seem to be the right tool for this job being that control points must be passed through. The non-uniform distribution of interpolation points is what's throwing me for a loop.
EDIT2: Here's an example of what I mean when I say my resulting curve is dirty:
The red arrows point out a few locations where there should not be a pixel. This is occurring because the X and Y components of the coordinate that get calculated do not change at the same rate. So, when each of the components gets rounded (so I have an exact pixel location) it can be the case that either X or Y doesn't get bumped up because the calculated coordinate is, say, (42.4999, 50.98). Swapping the round for a floor or ceil doesn't solve the problem, as it just changes where it occurs.
Here you have a paper describing method for the re-parametrization of splines in order to get equally spaced points along the curve length. I think this can solve your problem if you can adapt it to Catmull-Rom curves (shouldn't be too difficult, I guess)
As a followup to my previous question about determining camera parameters I have formulated a new problem.
I have two pictures of the same rectangle:
The first is an image without any transformations and shows the rectangle as it is.
The second image shows the rectangle after some 3d transformation (XYZ-rotation, scaling, XY-translation) is applied. This has caused the rectangle to look a trapezoid.
I hope the following picture describes my problem:
alt text http://wilco.menge.nl/application.data/cms/upload/transformation%20matrix.png
How do determine what transformations (more specifically: what transformation matrix) have caused this tranformation?
I know the pixel locations of the corners in both images, hence i also know the distances between the corners.
I'm confused. Is this a 2d or a 3d problem?
The way I understand it, you have a flat rectangle embedded in 3d space, and you're looking at two 2d "pictures" of it - one of the original version and one based on the transformed version. Is this correct?
If this is correct, then there is not enough information to solve the problem. For example, suppose the two pictures look exactly the same. This could be because the translation is the identity, or it could be because the translation moves the rectangle twice as far away from the camera and doubles its size (thus making it look exactly the same).
This is a math problem, not programming ..
you need to define a set of equations (your transformation matrix, my guess is 3 equations) and then solve it for the 4 transformations of the corner-points.
I've only ever described this using German words ... so the above will sound strange ..
Based on the information you have, this is not that easy. I will give you some ideas to play with, however. If you had the 3D coordinates of the corners, you'd have an easier time. Here's the basic idea.
Move a corner to the origin. Thereafter, rotations will take place about the origin.
Determine vectors of the axes. Do this by subtracting the adjacent corners from the origin point. These will be a local x and y axis for your world.
Determine angles using the vectors. You can use the dot and cross products to determine the angle between the local x axis and the global x axis (1, 0, 0).
Rotate by the angle in step 3. This will give you a new x axis which should match the global x axis and a new local y axis. You can then determine another rotation about the x axis which will bring the y axis into alignment with the global y axis.
Without the z coordinates, you can see that this will be difficult, but this is the general process. I hope this helps.
The solution will not be unique, as Alex319 points out.
If the second image is really a trapezoid as you say, then this won't be too hard. It is a trapezoid (not a parallelogram) because of perspective, so it must be an isosceles trapezoid.
Draw the two diagonals. They intersect at the center of the rectangle, so that takes care of the translation.
Rotate the trapezoid until its parallel sides are parallel to two sides of the original rectangle. (Which two? It doesn't matter.)
Draw a third parallel through the center. Scale this to the sides of the rectangle you chose.
Now for the rotation out of the plane. Measure the distance from the center to one of the parallel sides and use the law of sines.
If it's not a trapezoid, just a quadralateral, then it'll be harder, you'll have to use the angles between the diagonals to find the axis of rotation.