I was using blender 2.82 and actually i am pretty new to it and learning it and messing around with tools in it, and when i was using measure tool, i tried to measure angles on monkey face and tried to sum up all the interior angles of one face with 4 sides, but i was not getting that why the sum was coming out to be 355 degrees not 360 degrees as i know that sum of interior angles for polygons with n sides is (n-2)*180 degrees which means it should be 360 degrees as it has four sides but it was rather 355 degrees. I don't if this is some bug and i should report this bug or like i am doing something wrong in this and i need to know something that i don't know. Here are some pictures of the above described situation. Thanks in advance for your reply.
That's because you're in 3D space and you're looking at a non-planar face. If you select that face and go to Mesh > Clean up > Make Planar Faces and then re-snap your rulers on the angles, you will get 359, which is still 1° less but that's only due to the fact that the angles don't have decimals.
Related
I'm working on an application that uses a accelerometer to measure the sides of a room, I know it will not be exact measurements but it's fine.
In reality I would like the program to be able to calculate the sides of any room shape not only rectangles and squares (and more than 4 corners), but I'm starting with something more simple (rectangle shaped rooms).
My problem is not with the accelerometer but more with the math aspect of the code. Because I measured the room by placing the phone on a wall and then going to the connected wall, I will get the measurements of a quadrilateral inside the rectangle. From there, if it's possible, I will get the measurements of the sides of the rectangle, but I don't really know how.
What I've tried so far:
Divided the quadrilateral inside the rectangle in half, to make 2 triangles. Then I calculated the diagonal using the Pythagoras theorem. Then I used the law of Cosines to calculate one of the angles, and did the same again to find another. Then found the 3rd angle using the 2 other angles (c=a+b-180). I did this for both triangles.
I don't know if this is the right approach and if I have missed something simple, or if I simply don't have enough information to solve for the sides of the rectangle. I have looked into some geometry and trigonometry math online and haven't find anything that gives me a solution. But like I said, maybe I missed something simple.
Any push in the right direction would be helpful.
The rectangle and the quadrilateral
The problem lacks a unique solution. Imagine placing a pair of calipers around the quadrilateral. You'll be able to rotate the calipers around it, and at each angle the calipers will be able to close to a different width. Each of those widths is a different possible room dimension.
You'll also never get an accurate position measurement using the inertial sensors in a phone to begin with. The accels and gyros aren't even close to accurate enough. GPS is, but only outdoors away from structures that cause multipathing artifacts. Quick and sloppy with a tape measure will win every time.
I'm working with a MPU9250 to control a 3D position. I have an object that can rotate in 3 axis ( Roll, Pitch and Yaw) but I found some problems.
Initially I tried to calculate Euler Angles from Quaternions, but I discover that Euler Angles have 2 discontinuity in +/- 90 degrees, and so if I rotate the MPU for 365 deg it gives me wrong values like it's shifting while rotating.
I read that there is the possibility to convert Quaternions to DCM (Direction Cosine Matrix) but I find this algorithm fills too much the Arduino processor for calculations.
The last possibility that comes to my mind is to control the position directly with Quaternions, so I have to "forecast" the arriving Quaternion to stop the rotation when the MPU will give me the same Quaternion.
If anyone knows how to implement this or any other way please let me know your suggestions.
Many thanks,
Luca
I am currently teaching myself linear algebra in games and I almost feel ready to use my new-found knowledge in a simple 2D space. I plan on using a math library, with vectors/matrices etc. to represent positions and direction unlike my last game, which was simple enough not to need it.
I just want some clarification on this issue. First, is it valid to express a position in 2D space in 4x4 homogeneous coordinates, like this:
[400, 300, 0, 1]
Here, I am assuming, for simplicity that we are working in a fixed resolution (and in screen space) of 800 x 600, so this should be a point in the middle of the screen.
Is this valid?
Suppose that this position represents the position of the player, if I used a vector, I could represent the direction the player is facing:
[400, 400, 0, 0]
So this vector would represent that the player is facing the bottom of the screen (if we are working in screen space.
Is this valid?
Lastly, if I wanted to rotate the player by 90 degrees, I know I would multiply the vector by a matrix/quarternion, but this is where I get confused. I know that quarternions are more efficient, but I'm not exactly sure how I would go about rotating the direction my player is facing.
Could someone explain the math behind constructing a quarternion and multiplying it by my face vector?
I also heard that OpenGL and D3D represent vectors in a different manner, how does that work? I don't exactly understand it.
I am trying to start getting a handle on basic linear algebra in games before I step into a 3D space in several months.
You can represent your position as a 4D coordinate, however, I would recommend using only the dimensions that are needed (i.e. a 2D vector).
The direction is mostly expressed as a vector that starts at the player's position and points in the according direction. So a direction vector of (0,1) would be much easier to handle.
Given that vector you can use a rotation matrix. Quaternions are not really necessary in that case because you don't want to rotate about arbitrary axes. You just want to rotate about the z-axis. You helper library should provide methods to create such matrix and transform the vector with it (transform as a normal).
I am not sure about the difference between the OpenGL's and D3D's representation of the vectors. But I think, it is all about memory usage which should be a thing you don't want to worry about.
I can not answer all of your questions, but in terms of what is 'valid' or not it all completely depends on if it contains all of the information that you need and it makes sense to you.
Furthermore it is a little strange to have the direction that an object is facing be a non-unit vector. Basically you do not need the information of how long the vector is to figure out the direction they are facing, You simply need to be able to figure out the radians or degrees that they have rotated from 0 degrees or radians. Therefore people usually simply encode the radians or degrees directly as many linear algebra libraries will allow you to do vector math using them.
Hey so after reading this article I've been left with a few questions I hope to resolve here.
My understanding is that the goal of any multi-dimensional collision response is to convert it to a 1D collision be putting the bodies on some kind of shared axis. I've deduced from the article that the steps to responding to a 2d collision between 2 polygons is to
First find the velocity vector of each bodies collision point
Find relative velocity based on each collision point's velocity (see question 1)
Factor in how much of that velocity is along the the "force transfer line (see question 2)"
(which is the only velocity that matters for the collision)
Factor in elasticity
Factor in mass
Find impulse/ new linear velocity based on 2-4
Finally figure out new angular velocity by figuring out how much of the impulse is "rotating around" each object's CM (which is what determines angular acceleration)
All these steps basically figure out how much velocity each point is coming at the other with after each velocity is translated to a new 1D coordinate system, right?
Question 1: The article says relative velocity is meant to find and expression for the velocity with which the colliding points are approaching each other, but to me it seems as though is simply the vector of
CM 1 -> CM 2, with magnitude based on each point's velocity. I don't understand the reasoning behind even including the CMs in the calculations since it is the points colliding, not the CMs. Also, I like visualizing things, so how does relative velocity translate geometrically, and how does it work toward the goal of getting a 1D collision problem.
Question 2: The article states that the only force during the collision is in the direction perpendicular to the impacted edge, but how was this decided? Also how can they're only be force in one direction when each body is supposed to end up bouncing off in 2 different directions.
"All these steps basically figure out how much velocity each point is coming at the other with after each velocity is translated to a new 1D coordinate system, right?"
That seems like a pretty good description of steps 1 and 2.
"Question 1: The article says relative velocity is meant to find and expression for the velocity with which the colliding points are approaching each other, but to me it seems as though is simply the vector of CM 1 -> CM 2, with magnitude based on each point's velocity."
No, imagine both CMs almost stationary, but one rectangle rotating and striking the other. The relative velocity of the colliding points will be almost perpendicular to the displacement vector between CM1 and CM2.
"...How does relative velocity translate geometrically?"
Zoom in on the site of collision, just before impact. If you are standing on the collision point of one body, you see the collision point on the other point approaching you with a certain velocity (in your frame, the one in which you are standing still).
"...And how does it work toward the goal of getting a 1D collision problem?"
At the site of collision, it is a 1D collision problem.
"Question 2: The article states that the only force during the collision is in the direction perpendicular to the impacted edge, but how was this decided?"
It looks like an arbitrary decision to make the surfaces slippery, in order to make the problem easier to solve.
"Also how can [there] only be force in one direction when each body is supposed to end up bouncing off in 2 different directions."
Each body experiences a force in one direction. It departs in a certain direction, rotating with a certain angular velocity. I can't parse the rest of the question.
I am no mathematician, but I somehow got into game development as a hobby.
Having never studied anything beyond basic math, I have a lot of trouble figuring out how to reverse the angle of something, facing to the opposite direction, along the X axis & across the Y axis.
One image says more than 1000 words though (specially uneducated words):
http://img156.imageshack.us/i/wihwin.png/
I basically want to reverse the direction of cannon objects adhered to a robot. When the robot changes from facing right to facing left, I do (180 - angle) as everyone suggested me, but it literally reverses the angle, making the cannons aim up when they are aiming down. So, I need to do something else, but it escapes my knowledge.
To put it in other words, I work in 2D, so I want an angle that is facing right to face left. My angles are defined:
0 being "totally to the right"
180 "left"
90 "up" and
270 "down"
I want something that is aiming with an angle of 91 to turn into 89 when reversed. There's no Z axis present. Anyone would be so kind to help me with this?
In answer to your edit what you want then is
-( x - 90 ) + 90
i.e.
180 - x
Of course you will likely be working in radians and not degrees if you are using the standard C trigonometric functions so that would actually be
M_PI - x
Basically this breaks down into three steps
( x - 90 ) adjusts your angle so that the zero point is at 90 degrees.
Negating this then flips the transformed angle.
Add 90 back on to transform back to the original angle range.
Edit: Just noticed this is the same as #Paul R but you didn't seem to think that was correct?
This is quite tricky to answer without knowing a bit more about how the cannons are defined in your game, but I'll try to give some pointers.
It sounds like your cannon is viewed from the side, and you are wanting it to turn around from right to left but keeping the cannon facing up. The calculation depends on which direction 0 is, and whether the angles run clockwise or anticlockwise.
If the angle of 0 has the cannon pointing straight up, then the angle is measured from straight up, clockwise. Therefore, the reverse angle will be -angle. If negative angles don't work then use (360-angle).
If the angle of 0 has the cannon pointing to the right and an angle of 45 points to the bottom right, then the upward facing cannon angles are from 180 to 360 with 270 being straight up. Therefore, to reverse an angle, you'd use (540-angle).
If the angle of 0 has the cannon pointing to the right but an angle of 45 points to the top right, then the cannon angles are from 0 to 180. To reverse the angle, use (180-angle).
I hope that helps! Lee.
It depends on how you are defining your angle. If you define it relative to the X axis then the angle is indeed just (180 - alpha).
Looking at your diagram, the angles you've marked are the same - you've simply changed the starting point for them. If you actually intended to measure the angle so that 0 deg is straight up, then it's 360 - x
Thus if you have aimed at 45 degrees, when you reverse it is 360-45 = 315 degrees
Where does your zero degree angle point, and where does 90 degrees point?
If zero is straight up then you could just do -1 * angle.