The "union" there says that these are three different ways of viewing the same memory.
So the x component of the first struct occupies the same bytes of memory as the r component of the second struct, and so on. The three different versions just create different aliases by which you can refer to the vector's components - depending on whether you're viewing ...
qx = ax * sin(angle/2)
qy = ay * sin(angle/2)
qz = az * sin(angle/2)
qw = cos(angle/2)
But since your vector represents the rotation, and is not the axis of rotation, we need to compute the angle. Your axis of rotation is just 0,1,0
angle = atan2( vector.x, vector.z ...
Because the lookAt function is to position the camera to look at an object (not for an object to look at another object) and the way 3D cameras work is that mathematically they move the entire world the opposite way and the screen stays at the origin.
So because the matrix is intended for a camera and 3d cameras work "backward" you need to inverse the ...
One way is to disable GL_DEPTH_TEST for rendering 2D stuff. So draw everything of the 3D world like normal, then disable depth testing and then draw your UI at last.
Another approach would make use of the depth test by setting the z-component of the vertices for the 2D stuff to 0 (and the near plane in the prohection matrix to something greater than 0) to ...
the glm::quat(float, float, float, float); constructor doesn't do what you think it does. It sets the values directly.
The values of the quaternion (w, x, y, z) are in order: the cosine of half the angle, the sine of half the angle times the x coordinate of the normalized rotation axis, and the same for the y and z components.
So instead you want to use ...
user1118321's answer will provide you the correct answer, though it is more general than necessary. Since we're dealing with a right triangle, the easiest solution is to use the definition of the tangent function:
tan(α) = A / B
Substituting half the height of the screen, the z coordinate of the camera, and half the vertical field of view gets us:
Local versus world is just a matter of the order in which you compose transforms. For instance, when using row-vector math, multiplying the current local-to-world transform by a new transform on the left will perform the new transform in local space, since it will be equivalent to doing the new transform followed by the old local-to-world transform. ...
The results are not what you expect, but they are not wrong. It’s just that for a given orientation there are at least two “paths” through Euler angles that lead there.
For instance, the identity quaternion is trivially converted to Euler angles [0,0,0]. But doing three 180-degree rotations around each axis leaves you in the same orientation, too. That ...
Making a model always face a point is trickier in 3d than it is in 2d: the added dimension makes one wonder "what about the UP?".
This here assumes that you want your model to stay vertical as much as possible, and it uses the following coordinate system.
// z+ y+
// | /
// | /
// | /
// | /
// ¯¯¯¯¯¯¯¯¯¯¯¯ x+
This also assumes that the '...
Short answer: To store position, use a single vec3. To store rotation, use a quaternion and normalize it after every multiplication or after every n (1-1000) multiplications.
You shall only use mat4s when it comes to drawing or transforming lots of vertices: Convert vec3+quaternion pair to mat4 and pass it to your shader or use it to transform vertices ...
It also depends on your OS and compiler. I'm testing GLM-0.99, and this is the behavior I observe. Note that I have the following macros defined before including glm headers:
On MacOS 10.14 with clang++ compiler, I get executable with SIMD right away.
On Ubuntu 16.04 with g++ compiler, ...
If you have the normal of the collision triangle, then you can do a dot product with a normal pointing up (0, 1, 0), the result will be related to the angle of the surface (0 when is completety vertical, 1 when it's completely flat, and in between)
That should be really all, you check that against a threshold to determine if you want the ellipsoid to slide ...
Your current code assumes it's always going to get Euler angles where x is between ±90° and z is close to 0.
Meanwhile, glm wants to return Euler angles that are standardized so that y is between ±90°, even if that means putting a large number in x & z to compensate.
So when you're in the vicinity of (0, 0-89, 0), your code behaves relatively intuitively....
First thing I see is that you shouldn't read the quaternion in reverse order.
Also you shouldn't use glm::mix, use glm::slerp instead.
And here is how I construct the bone transform:
mat = glm::mat4_cast( currentrotation );
mat *= currentscale.x; mat *= currentscale.x; mat *= currentscale.x;
mat *= currentscale.y; mat *= ...
The problem is solved.
glUniformMatrix4fv(m_WVPLocation, 1, GL_TRUE, &PVMMat);
glUniformMatrix4fv(m_WVPLocation, 1, GL_FALSE, &PVMMat);
Your camera (and every object with a transform) has its own local space axes, which will usually not be the same as the world axes. Transforming around the world-space axis will give a different result than transforming around a local-space axis. Cameras typically need to work with both.
You usually want to rotate a camera horizontally around "world up" ...
Well if I understand well as @user8363 explained in the comments, your problem is that you are making one direction for all the particles, which makes the particles move in that direction. If you want the particles to accelerate toward the point you need to make a direction vector for each particle. For instance:
acc = particle - ...
I've done it by using a mix of Lighthouse3D tutorial, which I got by following the tip of @concept3d. My previous Frustum Culling routine was execute in about 12~16ms using Clip Space approach, but extracting planes from camera, I can execute it in 1~2ms....So, the peformance boost is awesome.
Here is my final code. Whenever my rotation/position changes, I ...
historically billboards matrix just copy the camera view matrix, and replace the last row with their own world position. the scale can be world-fixed if you want trees or hard stuff.
But it can also be screen-fixed for halo effects, in which case you need to scale using the euclidian distance. this can be done in the vertex shader rather than on CPU as an ...
Okay. Seems like you just want a single light-camera.
But there are many different approaches. Like using multiple frustum splits (which means multiple light-cameras), which is called "Cascaded Shadow Mapping". Even the way you construct the frustum of your light-camera to encompass the main camera's frustum can be done in various ways.
First some useful ...
Check out the Law of Cosines. It allows you to calculate any side or angle in a triangle if you have the opposite 2 angles or sides. Or alternately, use the law of sines (described at the bottom of the above link).
In your case, you know that vertical field of view is 45 degrees and that the base side you want is the height of the screen. You can think of ...
It's unclear where your issue lies.
To rotate a vector about the origin, you create a rotation matrix, and then you multiply the vertex by the matrix. In order to create the rotation matrix, you need a rotation axis and an angle.
With glm, you can do it this way:
glm::vec3 v3RotAxis( 0.0f, 0.0f, 1.0f ); // Rotate about z+
float angleRad = glm::half_pi&...
You get the error because there is no operator*= for vec4 that takes a matrix as a parameter. It then tries to convert the matrix to a float, but just can't.
To work around this, you should try to not use the operator*= and write it all in the long form:
Off = Off * Util::createTransform(offset);
Also, as pointed out in the comments to the OP, what you ...
Looks like that by luck I found the solution to the problem. I really don't like the glm documentation, was my understanding that glm doc was intentionally skinny since it matches corresponding glsl and glut. Anyway documentation is a mess.
doc v 0.92 doesnt specify what unit to use, the gluPerspective uses degree, so that's why I used degrees.
doc v0.94 ...
You just need the standard lookat function.
glm::vec3 const up(0.f, 0.f, 1.f);
object->setRotationMatrix(glm::lookAt(pos, target, up));
That’s all! Replace (0.f, 0.f, 1.f) with whatever you want your “up” vector to be.
Turns out the manual matrix creation method was on the right track, I just wasn't building it in the correct order. This appears to do what I want (though oriented on the -Z axis rather than the +X axis, but that'll be easy to change on my rectangle vertices).
glm::vec3 direction = glm::normalize( glm::vec3( p2 - p1 ) );
glm::vec3 rotationZ = direction;
Firstly, I would recommend working in radians, not degrees. Whilst the GLM library can work with degrees, it was designed with radians in minds(this is a very minor issue though, so work with what you feel comfortable in).
Secondly, If you wish to use quaternions to store data as orientation, then you must understand conceptually, what a quaternion is. ...
Yes, you can choose any coordinate system for your world. Choose one you like the most.
No, you don't need to rotate each object, you can just modify your projection matrix accordingly.
How to do that is explained below, but first I need to make some things clean.
in OpenGL, the coordinate system is so that the X-Z-plane is the "ground" plane