Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

313 Neutral

About Eleventy

  • Rank
    Advanced Member

Personal Information

  • Industry Role
  • Interests


  • Twitter
  • Github
  • Twitch
  • Steam

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks! Good to know that any projected plane will work with this method, and that it is fast - once I create the rest of the 3D counterparts to the 2D system I already have in place, I will implement this method.
  2. I am seeking advice regarding whether the following algorithm works (and if so, is the fastest) for a 3D line segment intersecting with a 3D cubic bezier curve: To test for intersections of a 3D line segment with a 3D bezier cubic path segment, project the 3D cubic path segment and the 3D line segment along a plane coincident with the 3D line segment. The chosen plane orientation should not cause the resultant 2D bezier cubic path segment to be linear unless its 3D counterpart is also linear. By default, the orientation will be along the Y axis (a vertical plane perpendicular to the X-Z axis). Then, perform a normal 2D bezier cubic curve/2D line intersection. For each found T value in the 2D intersection, only keep the T values in the 3D counterpart curve having all three coordinate values that are intersected by the actual 3D line segment.
  3. Eleventy

    Rotation matrix multiplication causes Gimbal lock

    Depending on if you want to have true 360-degree freedom, you could implement a system where each object has an up vector, a right vector and a forward vector. When rotation occurs, those three vectors rotate along with the object. Whenever an object rotates, you then use one of those three axis to rotate the object around, using the arbitrary rotation axis matrix: https://en.wikipedia.org/wiki/Rotation_matrix#Rotation_matrix_from_axis_and_angle Example code (axis is the axis of rotation and radians is the degrees to rotate): axis = vector_normalize(axis); float ct = cosf(radians); float st = sinf(radians); float ci = 1 - ct; float x = axis.x, y = axis.y, z = axis.z; return matrix_make(ct + x * x * ci, y * x * ci + z * st, z * x * ci - y * st, 0, x * y * ci - z * st, ct + y * y * ci, z * y * ci + x * st, 0, x * z * ci + y * st, y * z * ci - x * st, ct + z * z * ci, 0, 0, 0, 0, 1); As an example, when an object pitches up, rotate the object along the right axis and also rotate the "orientation" vectors along that same axis. When you perform another rotation (for example, turning right), rotate the object around the new up vector for the specified number of degrees (and, also rotate the orientation vectors). Another option is to use quaternions.
  4. Eleventy

    Torque and Angular Momentum

    Thanks! Your response is very helpful. I will look through my code and see where there might be one of those pitfalls you mentioned happening, as I do not feel that having to flip both the X and Y axis on the 'forward' vector and the Z-axis on the 'up' vector for the look-at matrix, in conjunction with having to flip all Z components of the position vectors for everything in my world is indication that I am doing everything right.
  5. Eleventy

    Torque and Angular Momentum

    Ah, I realize now why I have seen some other tutorials have the cross products reversed - given that the cross product is not commutative, that never made much sense to me until now. Good to know that matrices (and perhaps other components) also have this same issue. Now that I think about it, I did have to do some weird logic calculating the "look at" matrix and reverse all of the Z coordinates in order for my scene to even render and for movement to work correctly to begin with, as OpenGL and Metal is apparently configured to use a right-handed projection matrix by default (with no known way to change it).
  6. Eleventy

    Torque and Angular Momentum

    So, it appears that I am using a left-handed coordinate system, and the cross product in such a system always goes the opposite direction (you can see such an explanation here: https://betterexplained.com/articles/cross-product/). In my example above, in the right-handed coordinate system (positive X is to the left, positive Y is straight ahead, and positive Z is straight up), I would be calculating [1, 0, 0] cross [0, 1, 0], yielding [0, 0, 1], which looks correct. If I use the left-handed version of the cross product, I will get the correct result of [0, 1, 0] for the angular momentum vector. Weird that different coordinate systems even exist at all. I have always worked with the left-handed system in game development. Now I will have to replace all of my cross product calls with a special 'cross_lh' version, as my entire game engine has been unknowingly developed in this left-handed system.
  7. Hello, I am currently in the process of developing angular momentum for my game, and I am implementing torque for the purposes of changing objects' angular momentum. If I understand torque correctly, it is calculated by the position vector (R) (position the force is applied relative to the object) with the cross product of the force vector (F). The torque is then added to the angular momentum, resulting in the object starting to rotate. The angular momentum vector determines the direction the object rotates. An angular momentum vector of [0, 1, 0] should then cause an object to rotate to the left (it would spin counter-clockwise). So, to get an object to spin to the left, one would apply a force of [0, 0, 1] to the position of [1, 0, 0] (e.g. a force going forward applied to the right of the object). Positive X is to the right, and positive Z is going forwards. However, when I calculate R x F (e.g. [1, 0, 0] x [0, 0, 1]), I am getting torque result [0, -1, 0], which would cause the object to rotate clockwise instead of counter-clockwise. I figured my cross product calculation was wrong, but even Wolfram Mathematica gives me the same result. Am I missing something? Even the animations on Wikipedia's explanation of what torque is demonstrates that a force applied to the right of an object causes it to spin to the left (the animation clearly shows the vectors, and the torque vector is going upwards). Not to mention, this is what happens in real life. Is there something different about the coordinate system being used?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!