I'm trying to make sense of all the ways I can use the Rotation matrix (sorry for unreadability):
R(x) = [ cos(x) -sin(x) ; sin(x) cos(x) ]
There are two types of coordinate systems (CS) that you can have:
CS1 --> positive x-axis going right and positive y-axis going up which is apparently the standard orientation people use.
CS2 --> positive x-axis going right and positive y-axis going down.
What I'm confused with is the sign of angle x when plugged into R(x). Depending on the sign of the numerical, the angle either makes a counter-clockwise or clockwise rotation (on an arbitrary vector) but for which CS orientation and how would the other orientation behave?
Also, if you could explain a bit more than what wikipedia has on alibi and alias transformations, that would be great. Which would be best to think of rotations in? If I think in the alias approach, would I have to use the opposite sign for angle x.
This is what I'm referring to:
http://en.wikipedia.org/wiki/Rotation_matrix#Ambiguities
Thanks!
Would this be right...
Making use of R(x).
The vector undergoes a counter clockwise rotation of 'x' in CS1 (alibi). This relates to a clockwise rotation of CS1 of an angle 'x' (with the vector now having new coordinates). If x is negative then counter-clockwise becomes clockwise (alibi) and clockwise becomes counter-clockwise (alias)
If we were to use CS2...the above can be taken but with again swapping counter-clockwise with clockwise and vice versa.
In standard cartesian coordinates (what you've called "CS1") that matrix will cause a counter clockwise rotation to the vector (i.e. "alibi")
In the inverted Y axis case it'll be clockwise.
Related
I'm trying to infer an object's direction of movement using dense optical flow in OpenCV. I'm using calcOpticalFlowFarneback() to get flow coordinates and cartToPolar() to acquire vector angles which would indicate direction.
To interpret the results I need to know the reference point for measuring the angle. I have found this blog post indicating that the range of angles is 360°. That tells me that the angle measurement would go along the lines of the unit circle. I couldn't make out much more than that.
The documentation for cartToPolar() doesn't cover this and my attempts at testing it have failed.
It seems that the angle produced by cartToPolar() is in reference to the unit circle rotated clockwise by 90° centered on the image coordinate starting point in the top left corner. It would look like this.
I came to this conclusion by using the dense optical flow example provided by OpenCV. I replaced the line hsv[...,0] = ang*180/np.pi/2 with hsv[...,0] = ang*180/np.pi to get correct angle conversion from radians. Then I tested a video with people moving from top right to bottom left and vice versa. I sampled the dominant color with GIMP and got RGB values which I converted to HSV values. Hue value corresponds to the angle in degrees.
People moving from top right to bottom left produced an angle of about 300° and people moving the other way round produced an angle of about 120°. This hinted at the way the unit circle is positioned.
Looking at the code, fastAtan32f is used to compute the angles. and that seems to be a atan2 implementation.
A quaternion rotation defines a point in 3d-space and rotation around the axis of that point.
I am trying to understand why quaternion rotation requires a vector and rotation, why not just a 3d point in space and rotation ?
eg : In the following picture a hand points to a point in 3d-space which can be rotated around its axis.
http://s29.postimg.org/ih79tirnr/quarternion.jpg
Thanks
Actually, the x, y and z components of a quaternion define a vector pointing in the direction of the axis of rotation. The w component defines the amount of the rotation along that axis. So, the x, y and z don't actually signify a point at all. As the amount of rotation changes, the length of the x, y, z vector will change but the vector always points in the same direction. It doesn't make sense, therefore, to consider this to be a point in space. It's merely a direction and a rotation around that axis.
I once defined a new class that included a quaternion to define the transformation of an object along with a vector to describe the translation of the object. The object could then represent a complete transformation in 3D space similar to a 3x4 transformation matrix.
Looking at Convert a quadratic bezier to a cubic?, I can finally understand why programming teachers always told me that math was so important. Sadly, I didn't listen.
Can anyone provide a more concrete - e.g., computer-language-y - formula for converting a quadratic curve to a cubic? Understanding that there's some rounding errors possible, which is fine.
Given a quad curve represented by variables:
StartX, StartY
ControlX, ControlY
EndX, EndY
And desiring StartX, StartY and EndX, EndY to remain the same, but to now have Control1X, Control1Y and Control2X, Control2Y of a cubic curve.
Is it...
Control1X = StartX + (.66 * (ControlX - StartX))
Control2X = EndX + (.66 * (ControlX - EndX))
With the same essential functions used to calculate Control1Y and Control2Y?
Your code is right except that you should use 2.0/3.0 instead of 0.66.
You avoid most rounding errors by using
Control1 = (Start + 2 * Control) / 3
Control2 = (End + 2 * Control) / 3
Note that line segments are also convertible to cubic Bezier curves using:
Control1 = Start
Control2 = End
This can be handy when converting a complex path mixing various types of curves (linear, quadratic, cubic).
There's also a basic transform for converting elliptic arcs to cubic (with some minor unnoticeable errors): you just have to split at least the arc on elliptic quadrans (cutting the ellipse first on the two orthogonal axis of symetries, or on arbitrary orthogonal axis passing through the center if the ellipse is a circle, then representing each arc; when the ellipse is a circle, the two focal points are confused on the same point, the center of the circle, so you can use any direction for one of the orthogonal axis).
Many SVG renderers do that by adding an additional split on octants (so that you get also precise position not only for points where the two main axis are passing through, but also for two diagonal axis which are bissecting (when the ellipse is a circle) each quadrant (when the ellipse is not a circle, assimilate it as a circle flattened with a linear transform along the small axis only, you do the same computation), because octants are also quite precisely positioned:
cos(pi/4) = sin(pi/4) = sqrt(2)/2 ≈ 0.71, and because this additional splitting will allow precise rendering of tangents on points crossing the diagonals at 45 degrees of the circle.
A full ellipse is then converted to 8 cubic arcs (i.e. 8 points on ellipse and 16 control points): you'll almost not notice the difference between elliptical arcs and these generated cubic arcs
You can create an algorithm that uses the same "flattening error" computed when splitting a Bezier to a list of linear segments, which are then drawn using the classic fast Bresenham algo for line segments; a "flattenning" algorithm just has to measure the relative deviation of the sum of lengths of the two straight segments joining the two focal points of the ellipse to any point of the generated cubic arcs, as this sum is constant on any true ellipse: if you make this measurement on the generated control points for the cubic arcs, the difference should be below a given percentage of the expected sum, or within an absolute distance precision, and can be used to create better approximation of control points with a simple linear formula so that these added points will be on the real ellipse.
Such transform of arbitrary paths is useful when you want to derive other curves from the path, notably the curves of "buffers" at a given distance, notably when these paths must be converted to "strokes" with a defined "stroke width": you need to compute two "inner" and "outer" curves and then concentrate on how to converting the miters/buts/squares/rounded corners, and then to cut long miters at a convenient distance (matching the "miter limit" factor times the "stroke width").
More advanced renderers will also use miters represented by tangent circles when there's a corner between two arcs instead of two segments (this is useful for drawing cute geographic maps)...
Converting an arbitrary path mixing segments, elliptic and bezier arcs to only cubic arcs is a necessary step to compute precise images without excessive defects visible when zooming in. This is then necessary when your "stroke" buffers have to take some effects (such as computing dashes), and then enhancing the result with semi-transparent pixels or subpixels to smooth the rendered strokes (smoothing is easy to computez only when everything has been flattened to line segments, and alsos may be simpler to develop if it only has to manage paths containing only cubic beziers: it can easily be parallelized if needed and accelerated by hardware). Bezier arcs are always interesting because drawing them is fast and requires only basic arithmetics, and the time needed to draw them is proportional to the length of the curve with every point drawn with the same accuracy level.
In summary, all curves are representable by cubic Bezier arcs with a maximum measurable deviation allowed (you can set this maximum deviation to one half pixel, or one subpixel if you first scale up the measurement grid for half-toning or subpixel shading, and then represent accurately every curve with a reasonnaly fast rendering, and get accurate rendering at any zoom level with curves smoothed everywhere, including with half-toning or transparency levels when finally drawing the linear strokes with the classic Bresenham algorithm using fast integer-only arithmetics). These rendered curve will all have the correct tangeants everywhere, without any unexpected angles visible on approximation points, and the remaining control points in the approximation will make also a good smooth rendering of the curvature everywhere (i.e. radius of the tangeant circle), so you can use this approximation as well to derive other measurements such as acceleration, inertial forces, or magnetic effects of paths of charged particles).
If you ever need higher precision, use Bezier arcs with degree 4 (i.e. with 3 control points between points on curve) to get smoothed derivation at a supplementary degree (e.g. gradients of forces), or just split the cubic arcs with additional steps further, until the derivation is smooth enough (but using degree-4 Bezier arcs requires much less points curves and less control points for the same accuracy tolerances, than when using cubic Bezier only).
I came across this link http://www.mathopenref.com/coordpolygonarea2.html
It explains how to calculate the area of a polygon and helps to identify whether the polygon vertices we entered is clockwise or counter clockwise.
If area value is +ve, it is clockwise, if it is -nv then it is in counterclockwise.
My requirement is to identify only whether it is clockwise or counterclockwise. Is this rule will work correctly (though there are limitations as mentioned in the link). I have only regular polygons (not complicated, no self intersections) but the vertices are more.
I am not interested in the area value accuracy, just to know the ring rotation.
Any other thought on this.
For convex polygons:
Select two edges with a common vertex.
Lets say, edge1 is between vertex A and B. Edge2 is between vertex B and C.
Define to vectors: vect1: A----->B
vect2: B----->C
Cross product vect1 and vect2.
If the result is positive, the sequence A-->B-->C is Counter-clockwise.
If the result is negative, the sequence A-->B-->C is clockwise.
If you have only convex polygons (and all regular polygons are convex), and if your points are all organized consistently--either all counterclockwise or all clockwise--then you can determine which by just computing the (signed) area of one triangle determined by any three consecutive points. This is essentially computing the cross product of the two vectors along the two edges.
Greetings,
I want to draw a rectangle over a polygon belonging
to a arbitrary plane. Given the width (SA) and height (SB) of the
rectangle and the left upper corner (V1) of the rectangle, how
to determine the other vertices (V2, V3 and V4).
In the case of generic normal vector (all components are nonzero),
the directions (V2-V1) and (V3-V1) must be choosed by dropping
the coordinate of the normal vector with largest magnitude.
Any help is appreciated and welcome,
Best regards,
ricfow
Problem solved.
- First determine the directions to construct the rectangle from the the given point V1.
The possibilities are (1,0,0), (0,1,0) or (0,0,1). One of the them is eliminated by
observing the component of largest magnitude of the normal vector. Ex: suppose
that the normal vector is (0.2 -0.9 0.3). So drop (0,1,0). The other two will be used.
- Project the first direction vector on the plane, using the plane's normal vector. Using
SA, determine the position of V2. The same idea for V3 and V4.