I found a Web Site which explains Inverse Kinematics in 2D:
Starting from the joint nearest the
end point:
1. Calculate a force vector from the end of the bone to the target.
2. Calculate the dot product of the force vector and the Right angle
vector.
3. Multiply it by a small value, like 0.01.
4. Add it to the angle of the joint.
http://freespace.virgin.net/hugo.elias/models/m_ik.htm
So the way the bones are designed in my application is in terms of a joint and an angle. Each 'bone' is a joint and an angle and a length. The bone's end point is then the unit vector of its starting point and angle, multiplied by its length.
So I think for step 1, I simply generate a unit vector whos direction points toward the target and multiply it by the distance between the end point and the target point.
Step 2 is where I'm unsure. I know how to produce a dot product, but I'm not sure how to get this right angle vector they speak of.
Thanks
The "right angle vector" is a vector that is at a right angle to the length of the bone.
If you are pushing the bone along its length, it shouldn't move. In this case, the angle between this "right angle vector" and your force vector is then 90 degrees, and so the dot product is zero. Hence, no change in angle of the bone.
The Right-Vector is the R-Vector in the pictures of the 2D-inv-kinematics-sections. It is a normalized vector orthogonal to the bone.
A small hint: the dot-product of vector A and a normalized vector B is just the projected length of vector A to the straight of vector B which is just the cos(angle). More details here: http://en.wikipedia.org/wiki/Dot_product#Geometric_interpretation
As a result if the target-vector is nearly the same as the right-vector then the cos will be near 1 and the algorithm will correct your bone-angle more than if the target-vector is nearly the same as your bone-vector (cos is near 0)
Related
here is a problem that will turn your brain inside out, I'm trying to deal with it for a quite some time already.
Suppose you have sphere located in the origin of a 3d space. The sphere is segmented into a grid of equidistant points. The procedure that forms grid isn't that important but what seems simple to me is to use regular 3d computer graphics sphere generation procedure (The algorithm that forms the sphere described in the picture below)
Now, after I have such sphere (i.e. icosahedron of some degree) I need a computationally trivial procedure that will be capable to snap (an angle) of a random unit vector to it's closest icosahedron edge points. Also it is acceptable if the vector will be snapped to a center point of triangle that the vector is intersecting.
I would like to emphasise that it is important that the procedure should be computationally trivial. This means that procedures that actually create a sphere in memory and then involve a search among every triangle in sphere is not a good idea because such search will require access to global heap and ram which is slow because I need to perform this procedure millions of times on a low end mobile hardware.
The procedure should yield it's result through a set of mathematical equations based only on two values, the vector and degree of icosahedron (i.e. sphere)
Any thoughts? Thank you in advance!
============
Edit
One afterthought that just came to my mind, it seems that within diagram below step 3 (i.e. Project each new vertex to the unit sphere) is not important at all, because after bisection, projection of every vertex to a sphere would preserve all angular characteristics of a bisected shape that we are trying to snap to. So the task simplifies to identifying a bisected sub triangle coordinates that are penetrated by vector.
Make a table with 20 entries of top-level icosahedron faces coordinates - for example, build them from wiki coordinate set)
The vertices of an icosahedron centered at the origin with an
edge-length of 2 and a circumscribed sphere radius of 2 sin (2π/5) are
described by circular permutations of:
V[] = (0, ±1, ±ϕ)
where ϕ = (1 + √5)/2
is the golden ratio (also written τ).
and calculate corresponding central vectors C[] (sum of three vectors for vertices of every face).
Find the closest central vector using maximum of dot product (DP) of your vector P and all C[]. Perhaps, it is possible to reduce number of checks accounting for P components (for example if dot product of P and some V[i] is negative, there is no sense to consider faces being neighbors of V[i]). Don't sure that this elimination takes less time than direct full comparison of DP's with centers.
When big triangle face is determined, project P onto the plane of that face and get coordinates of P' in u-v (decompose AP' by AB and AC, where A,B,C are face vertices).
Multiply u,v by 2^N (degree of subdivision).
u' = u * 2^N
v' = v * 2^N
iu = Floor(u')
iv = Floor(v')
fu = Frac(u')
fv = Frac(v')
Integer part of u' is "row" of small triangle, integer part of v' is "column". Fractional parts are trilinear coordinates inside small triangle face, so we can choose the smallest value of fu, fv, 1-fu-fv to get the closest vertice. Calculate this closest vertex and normalize vector if needed.
It's not equidistant, you can see if you study this version:
It's a problem of geodesic dome frequency and some people have spent time researching all known methods to do that geometry: http://geo-dome.co.uk/article.asp?uname=domefreq, see that guy is a self labelled geodesizer :)
One page told me that the progression goes like this: 2 + 10·4N (12,42,162...)
You can simplify it down to a simple flat fractal triangle, where every triangle devides into 4 smaller triangles, and every time the subdivision is rotated 12 times around a sphere.
Logically, it is only one triangle rotated 12 times, and if you solve the code on that side, then you have the lowest computation version of the geodesic spheres.
If you don't want to keep the 12 sides as a series of arrays, and you want a lower memory version, then you can read about midpoint subdivision code, there's a lot of versions of midpoint subdivision.
I may have completely missed something. just that there isn't a true equidistant geodesic dome, because a triangle doesn't map to a sphere, only for icos.
In three.js, the constructor for the Math Plane takes 2 inputs:
normal -- (Vector3) normal vector defining the plane pointing towards the origin
constant -- (Float) the negative distance from the origin to the plane along the normal vector
Can someone provide an illustration or explain how this works? I can understand given a point and normal how to construct a plane, or 3 co-planar points, but can't figure out how a normal vector and constant can be used.
TL:DR?
Mathy-ness and linear algebra
So planes in 3 dimensional space can be defined as a 2-dimensional infinite rectangle that falls on 3 points (what you know)
It can also be defined by a perpendicular (normal) vector and a constant of how far from the origin the plane is.
Three.js take the normal vector (a vector that is perpendicular to the plane you want) and basically applies linear algebra to find the plane, then moves it the constant distance away from the origin.
Math Calculation Explanation:
If we have a vector A and B that are orthogonal (perpendicular) then their dot product is 0. SO if we use this principle we can actually take a known Vector X and find 2 orthogonal Vectors Y and Z that will be co-planar (due to orthogonality properties) by backwards solving X (dot) Y = 0 and X (dot) Z = 0
Now we have 2 co-planar vectors to make our plane that we set the distance of the constant away from the origin
(think how vectors have an origin and an endpoint. If the co-planar vectors share an origin, then we have 3 points: 2 ends, and 1 origin, aka 3 points to make a plane.)
Math Theory Explanation on why this works ahead:
I can't draw very well (without pen and paper to show), but basically, think about a vector in 3D space. Now think about all the vectors that can be perpendicular to it. Basically, that creates an infinite amount of perpendicular vectors rotated in a circle perpendicularly to the original, and if we span them infinitely, we have created a plane.
If you ever have an opportunity to take a linear algebra class, I would highly recommend it. It is extremely interesting, very related to computer graphics, and explains a lot of 3D space math that THREEjs uses
I have 2 sets of points that are restricted to live on the 3D unit sphere, call them {pi} and {qi} (I'll assume correspondence is known). The goal is to register one set to the other, through rotations and translations. Typically I would have used a transformation of the form:
P = RQ + T
where R is a rotation matrix and T a translation vector.
But in this case there is an extra constraint that all points must live on the sphere, how can I include this condition.
Assuming the sets are 'rigid', so you can slide and rotate the whole set on the sphere, but can not change distances between points within a set, all possible transformations are rotations.
Whenever you rotate the set relative to some axis, points move in planes perpendicular to the axis. So all displacements are vectors normal to the axis vector. So each two displacement vectors should make a vector product parallel to the axis vector.
Now, if you already know the correspondence between P and Q points, calculate displacement vectors di from each qi to a corresponding pi and calculate some vector products:
di × dj = (pi - qi) × (pj - qj)
If they have directions close enough to each other, you can assume you have the rotation axis.
Now for each pair or pi,qi find a point ti on an axis such that the PQT triangle is normal to the axis. The angle at the T vertex defines the rotation to slide qi to pi. If all respective angles are equal, you're done. Otherwise you'll have to seek some approximate solution...
all the plane definitions i've found use either four numbers (for the plane normal and distance from origin definition) or six numbers (for the plane normal and point that is on the plane definition).
maybe i'm missing something, but shouldn't it be possible to define a plane with only three numbers, (nx, ny, nz) using the direction of the vector as the plane normal and the magnitude of the vector as the distance from the origin?
i am trying to write a game that generates billions of planes, and shaving 25% off of my plane struct would really help.
It is possible, at the cost of recalculating the distance to the origin every time you need it.
If you need a solution using 3 parameters that has no degenerate case, use two direction angles (U, V) and the distance to the origin D.
Equation of the plane: cos(U).X + sin(U).cos(V).Y + sin(U).sin(V).Z = D.
If high accuracy is not mandated, you can store the angles as shorts, with suitable scaling, achieving 0°00'20" resolution. With float D, this packs to 8 bytes per plane.
I am given a pivot point (by the integer coordinates) and a line that goes through that point and makes an x degree with the horizontal. The line makes a 360 degrees clockwise rotation around the pivot point with speed s= 0.001 degree per second. I am now given N points (with integer coordinates) and I have to sort these points in the order in which the line touches these points. How can i compute this? Thank you in advance.
You need to do something equivalent to the following:
Translate everything so that the pivot point is at the origin
Convert each point to polar coordinates.
Subtract x from each point's angle component, modulo 360 degrees (2pi radians).
Sort the angle components in ascending order.
Write the comparison function that takes two points and compare the angles they make with horizontal line.