Usually, I use the dot product of 2 vectors either to find out how perpendicular they are or the cosine of the angle between them. In this shader, a toon shader, the dot product is used on 2 colors and I cannot wrap my head around what exactly this is doing.
uniform vec2 resolution;
uniform sampler2D backBuffer;
void main(void)
{
vec4 to_gray = vec4(0.3,0.59,0.11,0);
float x1 = dot(to_gray, texture2D(backBuffer,vec2((gl_FragCoord.xy
+ vec2(1.0,1.0)) /resolution.xy)).rgba);
float x0 = dot(to_gray, texture2D(backBuffer,vec2((gl_FragCoord.xy
+ vec2(-1.0,-1.0)) /resolution.xy)).rgba);
float x3 = dot(to_gray, texture2D(backBuffer,vec2((gl_FragCoord.xy
+ vec2(1.0,-1.0)) /resolution.xy)).rgba);
float x2 = dot(to_gray, texture2D(backBuffer,vec2((gl_FragCoord.xy
+ vec2(-1.0,1.0)) /resolution.xy)).rgba);
float edge = (x1 - x0) * (x1 - x0);
float edge2 = (x3 - x2) * (x3 - x2);
edge += edge2;
vec4 color = texture2D(backBuffer,vec2(gl_FragCoord.xy / resolution.xy));
gl_FragColor = max(color - vec4(edge, edge, edge, edge) * 12.0,
vec4(0,0,0,color.a));
}
The "geometric" scalar (dot) product properties don't really matter in this case. What you have here is an ordinary conversion of some (R, G, B) color to the corresponding grayscale intensity I in accordance with the formula
I = R * 0.30 + G * 0.59 + B * 0.11
(You can learn more about these coefficients here: https://en.wikipedia.org/wiki/Grayscale#Luma_coding_in_video_systems).
As you can immediately see this formula looks like a scalar product of two vectors: one is our color (R, G, B) and the other is (0.30, 0.59, 0.11). So, the author of the code just used the "dot product" function to evaluate this formula for four different color values obtained at four different points: point gl_FragCoord.xy shifted in four different directions (like an x pattern).
In other words, the dot product in this case is not used on "two colors", as you seemed to assume initially. It is used on a color (pixel taken from backBuffer at some coordinates) and a conversion coefficient vector (0.30, 0.59, 0.11) (aptly named to_gray). The latter is not really a color. It just a vector of conversion coefficients. You can think of it as a "color" if you want, but there's not much sense in it.
That's it for the dot product.
Then they do some extra computations to combine the four grayscale values into a single grayscale value. Then they use that grayscale value to modify the original color at point gl_FragCoord.xy (gray values are subtracted from RGB values at gl_FragCoord.xy). The purpose of all this is not fully clear without context.
Related
I'd like to generate random points being located on the surface of an n-dimensional torus. I have found formulas for how to generate the points on the surface of a 3-dimensional torus:
x = (c + a * cos(v)) * cos(u)
y = (c + a * cos(v)) * sin(u)
z = a * sin(v)
u, v ∈ [0, 2 * pi); c, a > 0.
My question is now: how to extend this formulas to n dimensions. Any help on the matter would be much appreciated.
I guess that you can do this recursively. Start with a full orthonormal basis of your vector space, and let the current location be the origin. At each step, choose a point in the plane spanned by the first two coordinate vectors, i.e. take w1 = cos(t)*v1 + sin(t)*v2. Shift the other basis vectors, i.e. w2 = v3, w3 = v4, …. Also take a step from your current position in the direction w1, with the radius r1 chosen up front. When you only have a single basis vector remaining, then the current point is a point on the n-dimensional torus of the outermost recursive call.
Note that while the above may be used to choose points randomly, it won't choose them uniformly. That would likely be a much harder question, and you definitely should ask about the math of that on Math SE or perhaps on Cross Validated (Statistics SE) to get the math right before you worry about implementation.
An n-torus (n being the dimensionality of the surface of the torus; a bagel or doughnut is therefore a 2-torus, not a 3-torus) is a smooth mapping of an n-rectangle. One way to approach this is to generate points on the rectangle and then map them onto the torus. Aside from the problem of figuring out how to map a rectangle onto a torus (I don't know it off-hand), there is the problem that the resulting distribution of points on the torus is not uniform even if the distribution of points is uniform on the rectangle. But there must be a way to adjust the distribution on the rectangle to make it uniform on the torus.
Merely generating u and v uniformly will not necessarily sample uniformly from a torus surface. An additional step is needed.
J.F. Williamson, "Random selection of points distributed on curved surfaces", Physics in Medicine & Biology 32(10), 1987, describes a general method of choosing a uniformly random point on a parametric surface. It is an acceptance/rejection method that accepts or rejects each candidate point depending on its stretch factor (norm-of-gradient). To use this method for a parametric surface, several things have to be known about the surface, namely—
x(u, v), y(u, v) and z(u, v), which are functions that generate 3-dimensional coordinates from two dimensional coordinates u and v,
The ranges of u and v,
g(point), the norm of the gradient ("stretch factor") at each point on the surface, and
gmax, the maximum value of g for the entire surface.
For the 3-dimensional torus with the parameterization you give in your question, g and gmax are the following:
g(u, v) = a * (c + cos(v) * a).
gmax = a * (a + c).
The algorithm to generate a uniform random point on the surface of a 3-dimensional torus with torus radius c and tube radius a is then as follows (where RNDEXCRANGE(x,y) returns a number in [x,y) uniformly at random, and RNDRANGE(x,y) returns a number in [x,y] uniformly at random):
// Maximum stretch factor for torus
gmax = a * (a + c)
while true
u = RNDEXCRANGE(0, pi * 2)
v = RNDEXCRANGE(0, pi * 2)
x = cos(u)*(c+cos(v)*a)
y = sin(u)*(c+cos(v)*a)
z = sin(v)*a
// Norm of gradient (stretch factor)
g = a*abs(c+cos(v)*a)
if g >= RNDRANGE(0, gmax)
// Accept the point
return [x, y, z]
end
end
If you have n-dimensional torus generating formulas, a similar approach can be used to generate uniform random points on that torus (accept a candidate point if norm-of-gradient equals or exceeds a random number in [0, gmax), where gmax is the maximum norm-of-gradient).
Solved
I'm making a 3D portal system in my engine (like Portal game). Each of the portals has its own orientation saved in a quaternion. To render the virtual scene in one of the portals I need to calculate the difference between the two quaternions, and the result use to rotate the virtual scene.
When creating the first portal on the left wall, and second one on the right wall, the rotation from one to another will take place in only one axis, but for example when the first portal will be created on the floor, and the second one on the right wall, the rotation from one to another could be in two axis, and that's the problem, because the rotation goes wrong.
I think the problem exists because the orientation for example X axis and Z axis are stored together in one quaternion and I need it separately to manualy multiply X * Z (or Z * X), but how to do it with only one quaternion, (the difference quaternion)? Or is there other way to correct rotate the scene?
EDIT:
Here on this picture are two portals P1 and P2, the arrows show how are they rotated. As I am looking into P1 I will see what sees P2. To find the rotation which I need to rotate the main scene to be like the virtual scene in this picture I'm doing following:
Getting difference from quaternion P2 to quaternion P1
Rotating result by 180 degrees in Y axis (portal's UP)
Using the result to rotate the virtual scene
This method above works only when the difference takes place in only one axis. When one portal will be on the floor, or on te ceiling, this will not work because the difference quaternion is build in more than one axis. As suggested I tried to multiply P1's quaternion to P2's quaternion, and inversely but this isn't working.
EDIT 2:
To find the difference from P2 to P1 I'm doing following:
Quat q1 = P1->getOrientation();
Quat q2 = P2->getOrientation();
Quat diff = Quat::diff(q2, q1); // q2 * diff = q1 //
Here's the Quat::diff function:
GE::Quat GE::Quat::diff(const Quat &a, const Quat &b)
{
Quat inv = a;
inv.inverse();
return inv * b;
}
Inverse:
void GE::Quat::inverse()
{
Quat q = (*this);
q.conjugate();
(*this) = q / Quat::dot((*this), (*this));
}
Conjugate:
void GE::Quat::conjugate()
{
Quat q;
q.x = -this->x;
q.y = -this->y;
q.z = -this->z;
q.w = this->w;
(*this) = q;
}
Dot product:
float GE::Quat::dot(const Quat &q1, const Quat &q2)
{
return q1.x*q2.x + q1.y*q2.y + q1.z*q2.z + q1.w*q2.w;
}
Operator*:
const GE::Quat GE::Quat::operator* ( const Quat &q) const
{
Quat qu;
qu.x = this->w*q.x + this->x*q.w + this->y*q.z - this->z*q.y;
qu.y = this->w*q.y + this->y*q.w + this->z*q.x - this->x*q.z;
qu.z = this->w*q.z + this->z*q.w + this->x*q.y - this->y*q.x;
qu.w = this->w*q.w - this->x*q.x - this->y*q.y - this->z*q.z;
return qu;
}
Operator/:
const GE::Quat GE::Quat::operator/ (float s) const
{
Quat q = (*this);
return Quat(q.x / s, q.y / s, q.z / s, q.w / s);
}
All this stuff works, because I have tested it with GLM library
If you want to find a quaternion diff such that diff * q1 == q2, then you need to use the multiplicative inverse:
diff * q1 = q2 ---> diff = q2 * inverse(q1)
where: inverse(q1) = conjugate(q1) / abs(q1)
and: conjugate( quaternion(re, i, j, k) ) = quaternion(re, -i, -j, -k)
If your quaternions are rotation quaternions, they should all be unit quaternions. This makes finding the inverse easy: since abs(q1) = 1, your inverse(q1) = conjugate(q1) can be found by just negating the i, j, and k components.
However, for the kind of scene-based geometric configuration you describe, you probably don't actually want to do the above, because you also need to compute the translation correctly.
The most straightforward way to do everything correctly is to convert your quaternions into 4x4 rotation matrices, and multiply them in the appropriate order with 4x4 translation matrices, as described in most introductory computer graphics texts.
It is certainly possible to compose Euclidean transformations by hand, keeping your rotations in quaternion form while applying the quaternions incrementally to a separate translation vector. However, this method tends to be technically obscure and prone to coding error: there are good reasons why the 4x4 matrix form is conventional, and one of the big ones is that it appears to be easier to get it right that way.
I solved my problem. As it turned out I don't need any difference between two rotations. Just multiply one rotation by rotation in 180 degrees, and then multiply by inverse of second rotation that way (using matrices):
Matrix m1 = p1->getOrientation().toMatrix();
Matrix m2 = p2->getOrientation().toMatrix();
Matrix model = m1 * Matrix::rotation(180, Vector3(0,1,0)) * Matrix::inverse(m2);
and translation calculating this way:
Vector3 position = -p2->getPosition();
position = model * position + p1->getPosition();
model = Matrix::translation(position) * model;
No, you have to multiply two quaternions together to get the final quaternion you desire.
Let's say that your first rotation is q1 and the second is q2. You want to apply them in that order.
The resulting quaternion will be q2 * q1, which will represent your composite rotation (recall that quaternions use left-hand multiplication, so q2 is being applied to q1 by multiplying from the left)
Reference
For a brief tutorial on computing a single quaternion, refer to my previous stack overflow answer
Edit:
To clarify, you'd face a similar problem with rotation matrices and Euler angles. You define your transformations about X, Y, and Z, and then multiply them together to get the resulting transformation matrix (wiki). You have the same issue here. Rotation matrices and Quaternions are equivalent in most ways for representing rotations. Quaternions are preferred mostly because they're a bit easier to represent (and easier for addressing gimbal lock)
Quaternions work the following way: the local frame of reference is represented as the imaginary quaternion directions i,j,k. For instance, for an observer standing in the portal door 1 and looking in the direction of the arrow, direction i may represent the direction of the arrow, j is up and k=ij points to the right of the observer. In global coordinates represented by the quaternion q1, the axes in 3D coordinates are
q1*(i,j,k)*q1^-1=q1*(i,j,k)*q1',
where q' is the conjugate, and for unit quaternions, the conjugate is the inverse.
Now the task is to find a unit quaternion q so that directions q*(i,j,k)*q' in local frame 1 expressed in global coordinates coincide with the rotated directions of frame 2 in global coordinates. From the sketch that means forwards becomes backwards and left becomes right, that is
q1*q*(i,j,k)*q'*q1'=q2*(-i,j,-k)*q2'
=q2*j*(i,j,k)*j'*q2'
which is readily achieved by equating
q1*q=q2*j or q=q1'*q2*j.
But details may be different, mainly that another axis may represent the direction "up" instead of j.
If the global system of the sketch is from the bottom, so that global-i points forward in the vertical direction, global-j up and global-k to the right, then local1-(i,j,k) is global-(-i,j,-k), giving
q1=j.
local2-(i,j,k) is global-(-k,j,i) which can be realized by
q2=sqrt(0.5)*(1+j),
since
(1+j)*i*(1-j)=i*(1-j)^2=-2*i*j=-2*k and
(1+j)*k*(1-j)=(1+j)^2*k= 2*j*k= 2*i
Comparing this to the actual values in your implementation will indicate how the assignment of axes and quaternion directions has to be changed.
Check https://www.emis.de/proceedings/Varna/vol1/GEOM09.pdf
Imagine to get dQ from Q1 to Q2, I'll explain why dQ = Q1*·Q2, instead of Q2·Q1*
This rotates the frame, instead of an object. For any vector v in R3, the rotation action of operator
L(v) = Q*·v·Q
It's not Q·v·Q*, which is object rotation action.
If you rotates Q1 and then Q1* and then Q2, you can write
(Q1·Q1*·Q2)*·v·(Q1·Q1*·Q2) = (Q1*·Q2)*·Q1*·v·Q1·(Q1*·Q2) = dQ*·Q1*·v·Q1·dQ
So dQ = Q1*·Q2
Why this throws an compilation error: no matching function for call to ‘cross(glm::vec4&, glm::vec4&)’
glm::vec4 a;
glm::vec4 b;
glm::vec4 c = glm::cross(a, b);
but it works fine for vec3?
There is no such thing as a 4D vector cross-product; the operation is only defined for 3D vectors. Well, technically, there is a seven-dimensional vector cross-product, but somehow I don't think you're looking for that.
Since 4D vector cross-products aren't mathematically reasonable, GLM doesn't offer a function to compute it.
What do your vec4's represent? Like Nicol said, cross products are only for 3D vectors. The cross product operation is used to find a vector that is orthogonal to the two input vectors. So if your vec4's represent 3D homogeneous vectors in the form {x, y, z, w}, then the w-component doesn't matter to you; You could simply ignore it.
A workaround could go as follows:
vec4 crossVec4(vec4 _v1, vec4 _v2){
vec3 vec1 = vec3(_v1[0], _v1[1], _v1[2]);
vec3 vec2 = vec3(_v2[0], _v2[1], _v2[2]);
vec3 res = cross(vec1, vec2);
return vec4(res[0], res[1], res[2], 1);
}
Simply turn your vec4's into vec3's, perform the cross product, then add a w-component of 1 back into it.
The generalization of the cross product is the wedge product, and the wedge product of two vectors is a 2-form, also known as a bivector.
In 3-space, the 2-form kinda looks like a vector, but it behaves quite differently. Suppose we have two non-collinear vectors tangent to a surface (aka tangent vectors). By taking the cross product of these vectors, we have a 2-form that represents the tangent plane. We can also represent that tangent plane by the vector normal to that plane (aka the normal vector). But the tangent and normal vectors are transformed differently, i.e. the normal vector is transformed by the inverse transpose of the matrix used to transform the tangent vectors.
In 4-space, the 2-form resulting from the wedge product of two vectors also represents the plane that contains the two vectors (this is also true in N-space). Similarly to the case in 3-space, we can have an alternate interpretation of that plane, but in 4-space, the complement to a plane is not a 4-vector, but another plane, both of which are represented with 6 components, not 4.
c1 * e1^e2 + c2 * e1^e3 + c3 * e1^e4 + c4 * e2^e3 + c5 * e2^e4 + c6 * e3^e4
Since glm doesn't provide the API for wedge products, you will have to roll your own. You can easily work out the algebra for the wedge product with two simple rules:
(1) ei ^ ei = 0
(2) ei ^ ej = -ej ^ ei
where the ei and ej are the component vectors (bases) of the vector space, e.g.
[a b c d] --> a * e1 + b * e2 + c * e3 + d * e4
The 7-dimensional vector referred to in a previous post is the geometric product of two vectors, which uses ei^ei=1 instead of rule (1) above, and is like a meld of the dot and cross products (or complex multiplication), which is more than what you want.
For more information, https://en.wikipedia.org/wiki/Exterior_algebra or https://en.wikipedia.org/wiki/Geometric_algebra .
There is more shortcut way to calculate cross product using glm's GLM_SWIZZLE.
Just do #define GLM_SWIZZLE before inclusion of any glm file. It's also helpful for lots of other tricks.
glm::vec4 a;
glm::vec4 b;
glm::vec4 c = glm::vec4( glm::cross( glm::vec3( a.xyz ), glm::vec3( b.xyz ) ), 0 );
Time for a little bit of math for the end of the day..
I need to project 4 points of the window size:
<0,0> <1024,768>
Into a world space coordinates so it will form a quadrilateral shape that will later be used for terrain culling - without GluUnproject
For test only, I use mouse coordinates - and try to project them onto the world coords
RESOLVED
Here's how to do it exactly, step by step.
Obtain your mouse coordinates within the client area
Get your Projection matrix and View matrix if no Model matrix required.
Multiply Projection * View
Inverse the results of multiplication
Construct a vector4 consisting of
x = mouseposition.x within a range of window x
transform to values between -1 and 1
y = mouseposition.y within a range of window y
transform to values between -1 and 1
remember to invert mouseposition.y if needed
z = the depth value ( this can be obtained with glReadPixel)
you can manually go from -1 to 1 ( zNear, zFar )
w = 1.0
Multiply the vector by inversed matrix created before
Divide result vector by it's w component after matrix multiplication ( perspective division )
POINT mousePos;
GetCursorPos(&mousePos);
ScreenToClient( this->GetWindowHWND(), &mousePos );
CMatrix4x4 matProjection = m_pCamera->getViewMatrix() * m_pCamera->getProjectionMatrix() ;
CMatrix4x4 matInverse = matProjection.inverse();
float in[4];
float winZ = 1.0;
in[0]=(2.0f*((float)(mousePos.x-0)/(this->GetResolution().x-0)))-1.0f,
in[1]=1.0f-(2.0f*((float)(mousePos.y-0)/(this->GetResolution().y-0)));
in[2]=2.0* winZ -1.0;
in[3]=1.0;
CVector4 vIn = CVector4(in[0],in[1],in[2],in[3]);
pos = vIn * matInverse;
pos.w = 1.0 / pos.w;
pos.x *= pos.w;
pos.y *= pos.w;
pos.z *= pos.w;
sprintf(strTitle,"%f %f %f / %f,%f,%f ",m_pCamera->m_vPosition.x,m_pCamera->m_vPosition.y,m_pCamera->m_vPosition.z,pos.x,pos.y,pos.z);
SetWindowText(this->GetWindowHWND(),strTitle);
I had to make some adjustments to the answers provided here. But here's the code I ended up with (Note I'm using GLM, that could affect multiplication order). nearResult is the projected point on the near plane and farResult is the projected point on the far plane. I want to perform a ray cast to see what my mouse is hovering over so I convert them to a direction vector which will then originate from my camera's position.
vec3 getRayFromScreenSpace(const vec2 & pos)
{
mat4 invMat= inverse(m_glData.getPerspective()*m_glData.getView());
vec4 near = vec4((pos.x - Constants::m_halfScreenWidth) / Constants::m_halfScreenWidth, -1*(pos.y - Constants::m_halfScreenHeight) / Constants::m_halfScreenHeight, -1, 1.0);
vec4 far = vec4((pos.x - Constants::m_halfScreenWidth) / Constants::m_halfScreenWidth, -1*(pos.y - Constants::m_halfScreenHeight) / Constants::m_halfScreenHeight, 1, 1.0);
vec4 nearResult = invMat*near;
vec4 farResult = invMat*far;
nearResult /= nearResult.w;
farResult /= farResult.w;
vec3 dir = vec3(farResult - nearResult );
return normalize(dir);
}
Multiply all your matrices. Then invert the result. Point after projection are always in the -1,1. So the four corner screen points are -1,-1; -1,1; 1,-1;1,1. But you still need to choose th z value. If you are in OpenGL, z is between -1 and 1. For directx, the range is 0 to 1. Finally take your points and transform them with the matrix
If you have access to the glu libraries, use gluUnProject(winX, winY, winZ, model, projection, viewport, &objX, &objY, &objZ);
winX and winY will be the corners of your screen in pixels. winZ is a number in [0,1] which will specify where between zNear and zFar (clipping planes) the points should fall. objX-Z will hold the results. The middle variables are the relevant matrices. They can be queried if needed.
I am currently trying to convert colours between RGB (red, green, blue) colour space and RYB (red, yellow, blue) colour space and back again.
Based on the details in the following paper, I am able to convert from RYB to RGB using trilinear interpolation - where the parametric weightings (s, t, u) are the RYB colors, and the vertices of the cube are 3d points in RGB space.
Paint Inspired Color Mixing and Compositing for Visualisation - Gossett and Chen - Section 2.1 - Realization Details
My difficulties are in reversing the conversion process.
A second paper references the use of this technique and also indicates that the reverse conversion was achieved using Newton's Method. But provides no further details. This would probably indicate root finding in solving the trilinear interpolation equations.
On the Transfer of Painting Style to Photographic Images through Attention to Colour Contrast - Xiaoyan Zhang; Constable, M.; Ying He;
Before I expand on this question with the equations, has anybody seen, or solved this in a language such as Java/C/C++/C#?
My current approach is to take the forward equations of the trilinear interpolation (RYB to RGB), expand and rearrange to provide 3 simultaneous equations for 3 unknowns (the parametric weightings: s, t, and u) then work out how to find the roots using the Newton-Raphson method. Am I going about this in the right way?
I managed to solve it in the end.
Take the equations for a trilinear interpolation:
wikipedia
Edit: Wikipedia revision at the time
Substitute the first equations into the last, the expand and collect the coefficients for:
Xd, Yd, Zd, XdYd, XdZd, YdZd, ZdYdZd and the constant.
Then find the partial differentiation of the equation in each of the 3 dimensions each in respect to Xd, Yd and Zd. Use these new equations to populate the (3x3) Jacobian matrix and then use Newton's method to solve in software.
Newton-Raphson Method
I found this JavaScript implementation of RYB->RGB conversion based on cubic splines. Here is my Lua port (all values lie in the interval 0-1):
local ryb2rgb = function( R, Y, B )
local R, Y, B = R*R*(3-R-R), Y*Y*(3-Y-Y), B*B*(3-B-B)
return 1.0 + B * ( R * (0.337 + Y * -0.137) + (-0.837 + Y * -0.163) ),
1.0 + B * ( -0.627 + Y * 0.287) + R * (-1.0 + Y * (0.5 + B * -0.693) - B * (-0.627) ),
1.0 + B * (-0.4 + Y * 0.6) - Y + R * ( -1.0 + B * (0.9 + Y * -1.1) + Y )
end
Here is a category on UIColor that does the same thing, returning elements between RGB, RYB, and CMYK. Further, you can mix any number of colors in the respective color space (they mix differently, of course, depending).
https://github.com/ddelruss/UIColor-Mixing