Tag Info

Hot answers tagged

35

I think the direction of the coordinate axes are holdovers from different domains where the crucial plane was different, and X/Y were aligned with that crucial plane. In some applications the ground plane was the most important, thus X/Y were the ground and Z ended up perpendicular to that. For games however the crucial plane is usually the screen ...


17

Your assumptions aren't wrong: each engine treats these coordinates differently. Generally speaking X is almost always the East-West axis but whether Y or Z is the Altitude axis tends to vary. As I understand it, Quake 3, the Source Engine, and the Torque engine all have Z as up. So does the modelling tool 3DS Max. It's not uncommon. It makes sense to have ...


12

Think about the problem differently. You want to object always to "face" the player, which means you want its "forward" vector rotated around to be parallel to the vector from itself to the player. Assuming its "forward" vector is normally at obj.Rotation = 0, the proper rotation is basically the arctangent of Vector2.Subtract(playerPos, objectPos). Most ...


6

Imagine looking at a piece of paper held out in front of you with a chart on it, the axes are typically labeled X across the bottom and Y up the vertical; this leaves Z to be the outwards axis along the ground. It's merely a convention, but it's used a lot in graphics where we think of Z as the depth into the scene. In other fields like CAD your version ...


5

I'm not sure of a good way to preface this, other than I hope it ties together nicely by the end. That said, let's dive in: A rotation and an orientation are different because the former describes a transformation, and the latter describes a state. A rotation is how an object gets into an orientation, and an orientation is the local rotated space of the ...


5

Your problem is under-constrained, so there are a lot of possible solutions. My suggestion is to see your vec3 as the result of rotating vector [1 0 0] by φ around axis Y then by θ around axis Z. This is the latitude/longitude notation. The corresponding transformation matrix is: |cosθ cosφ -sinθ -cosθ sinφ| |sinθ cosφ cosθ -sinθ sinφ| | sinφ ...


4

The simplest way to do this is to compute a correcting rotation every time the camera moves: axis = cross(newPosition, oldPosition); angle = acos(dot(normalize(oldPosition), normalize(newPosition))); ...and then rotate the camera's orientation matrix/quaternion/basis vectors by this correction. But since the movements are likely to be small and frequent, ...


4

Click on the object in the scene, and look at the Rotation values in the Inspector. This will tell you which way the object is oriented in absolute terms. If the orientation does not match your expected axis (for example, 90 degrees off, or using an unintuitive axis for a given direction), you cannot change the axis of the object itself. Instead, you can ...


4

The sign of the dot-product of C with AB will be positive when the vector component of CD parallel to vector AB is in the direction AB, and negative when it is in the direction BA. The sign of the (z-component of the) cross-product of vector CD with vector AB will indicate which side of AB the agent is approaching from. Depending on your sign conventions, ...


4

A single vector only represents a direction. It sounds like gimbal lock will not be a problem in your case. First you need to select an up vector to really define an orientation instead of a direction. You can start with the world's up vector and than use the last frames up vector from there on. Now you can calculate a side vector using the cross product ...


3

The idea is that the x and y axes stay the same - y is 'up' on the screen, and x is across. z - the third dimension, projects back into the screen (ignoring the issues of handedness here). In 3 dimensions this gets a bit odd, but for positioning things in screen space it makes more sense. 3) You can if you want, but it would be painful and clunky. I would ...


3

This can be handled like the similar case for linear acceleration. First fact to note: Because the ship starts off with an angular velocity of zero, an you want it to end up with an angular velocity of zero, this means that the total change in velocity must equal zero. From this we can see that the integral of the acceleration over time must equal zero -- ...


3

Your best luck is to learn some matrix math. You should have some kind of scene graph that establishes the character as a child node of the boat. It then would store it's position relative to the boat. The boat would have a transformation matrix, you apply that to the child nodes, and the child nodes could stack some more transformations on the matrix ...


3

You can just check if the width of the screen is less than the height - if this is the case, then you definitely have a monitor in portrait mode.


2

From what I've understood from your post, this is essentially an Arrive behaviour. Arrival is a fairly simple behaviour to implement, and you don't have to use angles to get an angle back either. Vector toTargetVector = targetPosition - bodyPosition; double distanceToTarget = toTargetVector.Length(); // It's very simple to get the angle from here, just use ...


2

Matrix accumulations can in fact solve Gimbal lock. By accumulating rotations, you are adding gimbals, allowing any arbitrary rotation. The diagram that ktodisco provided shows a gimbal lock in the left diagram. The matrix for this orientation can be defined as: glutil::MatrixStack bookMatrix; bookMatrix.RotateX(90); bookMatrix.RotateY(90); ...


2

If I understand what you're asking, the vector CD is just a vector, not a ray, so only the direction matters, not location. However, AB is a line segment, not just a vector, so its location matters. Your tests have one 'if' test to make two cases, but I think you actually have four cases. Let's look at the diagram in AB's reference frame: If you can ...


2

you can set the velocity to "world space" and just provide a vertical velocity, the particle system will follow the hand orientation, but the particles emitted will always move upwards.


2

It's mostly legacy from the times when all that could've been made with 3D was some screen-space rotating cube or parallax scrolling or something similar. In such applications, Z was "depth" because X and Y were the axes for the screen plane. As demos were getting more advanced, the original conventions stayed because it's easier not to change anything that ...


2

Turn the quaternion into a 3x3 matrix, transpose it (shortcut for the inverse of a purely rotational matrix), apply this matrix to your world space vector and you now have your model space velocity vector (entity's virtual axes: X=right, Y=Up, Z=forward or backward).


1

How to design a simple unit AI for attack runs / combat moves? I would recommend using some sort of Finite-State Machines e.g. see: http://gamedevelopment.tutsplus.com/tutorials/finite-state-machines-theory-and-implementation--gamedev-11867 How to implement collision avoidance? I can think of two implementations to start with: 1:If the space is ...


1

I haven't digested all of your code. Consider the effect of using the center of the rear axle as the vehicle's origin and have that point ride the actual Bezier. As such, the car's forward direction is coincident with the tangent. Both of these relate to the path of a real car. The front wheels just need to always point directly toward their ...


1

I think that your constraints of "don't letterbox" and "support the same viewable area in both orientations" are irreconcilable. I think you need to relax one of those constraints somewhat, and then your question devolves into the already-asked-and-answered question of handling multiple resolutions (see the "Related Questions" sidebar for a collection of ...


1

I figured out how to do it. I used an interface as shown at this link Basically, I created an interface in the core project, then for each back-end project I implements my interface. To change the orientation in Android is simple as shown here That is, setRequestedOrientation(ActivityInfo.<THE_ORIENTATION>)


1

I figured out the best way to do this is to check the screen size on the device and base a boolean conditional to device on which axis to use. This is tested and working great. // Check the screen layout to determine if the device is a tablet. public boolean isTablet(Context context) { boolean xlarge = ...


1

I don't know about the rotation part but for the mapping input to rotation you can do the following: (this doesn't go in code) add 32768 to your input getting a value 0-65535 from here you can get your multiplier which is 90/65535 = 0.00137 then to get your rotation distance you can simply multiply your input by your multiplier (this goes in code) ...


1

I solved it. I was on the right track... The final solution is: void SceneElement::look_at(const mx::Vector3f& target, const mx::Vector3f& up) { mx::Vector3f forward_l = mx::normalize(target - position); mx::Vector3f forward_w(1, 0, 0); mx::Vector3f axis = forward_l % forward_w; float angle = mx::rad_to_deg(acos(forward_l * ...


1

1) Yes your observations are correct. 2) The standard global XYZ coordinate system makes sense when you think in terms of a first person shooter, when you are looking through the eyes of a character in the scene with a blank(identity) transformation matrix. Like it would when you draw a coordinate system on a piece of paper, X points to right and Y points ...


1

As far as I have ever gleaned the Y = up/down, and Z = depth is based off of physics where gravity is always in the (-Y) direction, and then adding 3D means you don't want to change a fundamental, so it was made depth. On the Z = up/down method though that is a throw back to mathematicians. because X/Y was drawn on the paper that was flat on the table when ...


1

Because the coordinate system that are used in games are based off of the dimension of the monitor. When computer renders anything, it starts at the upper left hand corner which gives the x, and y coordinate of [ 0, 0 ]. As the rendering progresses towards the right side of the screen, the x value increments, respectively when the render moves down, the y ...



Only top voted, non community-wiki answers of a minimum length are eligible