Jump to content
  • Advertisement

Dirk Gregorius

  • Content count

  • Joined

  • Last visited

  • Days Won


Dirk Gregorius last won the day on August 16

Dirk Gregorius had the most liked content!

Community Reputation

2810 Excellent


About Dirk Gregorius

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

13491 profile views
  1. Dirk Gregorius

    How to solve this trig function?

    For completeness: // Solve sin(at) * d = sin(a(1-t)) * e // Divide by e sin(a*t) * d / e = sin(a*(1-t)) // Substitute b = d/e b * sin(at) = sin(a - at) // Trig identity b * sin(at) = sin(a) * cos(at) - cos(a) * sin(at) // Add cos(a) * sin(at) on both sides b * sin(at) + cos(a) * sin(at) = sin(a) * cos(at) // Factor sin(at) sin(at) * [b + cos(a)] = sin(a) * cos(at) // Divide by cos(at) and use tan(at) = sin(at) / cos(at) tan(at) * [b + cos(a)] = sin(a) *and* cos(at) != 0 // Divide by [b + cos(a)] tan(at) = sin(a) / [b + cos(a)] // Solve for at at = atan( sin(a) / [b + cos(a)] ) // Divide by a t = atan( sin(a) / [b + cos(a)] ) / a
  2. Dirk Gregorius

    How to solve this trig function?

    I gave this a quick look. To avoid typing I just solved the simpler problem sin(t) = sin(1-t). The basic solving strategy should be the same hopefully. Here is what I came up with: // Solve sin(t) = sin(1-t) // Angle sum identies sin(a-b) = sin(a) * sin(b) - cos(a) * sin(b) sin(t) = sin(1) * cos(t) - cos(1) * sin(t) // Add cos(1) * sin(t) on both side sin(t) + cos(1) * sin(t) = sin(1) * cos(t) // Factor sin(t) sin(t) * [1 + cos(1)] = sin(1) * cos(t) // Divide by cos(t) tan(t) * [1 + cos(1)] = sin(1) *and* cos(t) != 0 // Divide by [1 + cos(1)] tan(t) = sin(1) / [1 + cos(1)] // Solve for t t = atan( sin(1) / [1 + cos(1)] ) // Calculator t = 0.5 Obviously this is indeed the correct solution as sin( 0.5 ) = sin( 1 - 0.5 ) HTH, -Dirk
  3. Dirk Gregorius

    QR Algorithm & Eigen value order

    Interesting question. I would argue it doesn't matter. Since ( (a)^n )^m = a^(n*m) = a^(m*n) = ( (a)^m )^n
  4. Dirk Gregorius

    QR Algorithm & Eigen value order

    I think you can cut out those permutations that would change the handness of the rotation frame. You cannot rotate from a RH system into LH system I guess.
  5. Dirk Gregorius

    Sweep and prune obstacle containing boxes

    I am not sure I understand the question. Are you asking how to construct the proxy AABB (Axis Aligned Bounding Box) from a mesh?
  6. Dirk Gregorius

    QR Algorithm & Eigen value order

    Did you consider writing an email to Shoemake? Over the years I often contacted researchers directly and most of the time they replied back. These people usually put quite some effort into their research and are usually happy to discuss their work.
  7. Dirk Gregorius

    QR Algorithm & Eigen value order

    Sorry, I would need to look this up myself. I noticed one thing in your implementation though. I would use a cross product for the z-axis instead of the Gram-Schmidt projection. I think this is actually common for 3D matrices as it is numerically more robust. Another thing I would think about is whether a full decomposition is actually needed. If your matrix has simply the form M = R * S (assuming column vectors and S being a diagonal scale matrix) then you can trivially extract the scale simply by computing the length of of each column. No decomposition needed. If you have an arbitrary transformation with shear and eventually reflection, then QR decomposition will be not sufficient IIRC.
  8. Dirk Gregorius

    QR Algorithm & Eigen value order

    I assume QRDecompose() sorts the results. You need to change the source code to not sort. If you don't have access to source you need to do it yourself. As a side note, QR decomposition is not the best method for decomposing affine transformations as used in games or animation. You might want to check this out: http://research.cs.wisc.edu/graphics/Courses/838-s2002/Papers/polar-decomp.pdf Source code is available as well.
  9. Dirk Gregorius

    Moving circle to Aabb collision

    The sweep tests for character movement or AI are usually at least reasonably optimized. The reason is that you usually don't move a character with a single sweep, but instead need a couple of consecutive sweeps.You don't just move to the first point of intersection. This would be a bad player experience since you will get stuck easily (e.g. you want to slide along walls, climb steps, etc). Since there are usually a couple of characters and these sweep are not cheap you don't go with a brute force solution. E.g. in Source 1 and 2 we use box sweeps and they are really *heavily* optimized. Both for performance and numerical robustness. BTW: I didn't mean to criticize you. Your solution is correct and shows a good geometric understanding of the problem in my opinion. From there the question is how many of the exhaustive tests are redundant due to the symmetry of the problem and can be collapsed into simpler tests. This is all I wanted to point out and is really the interesting point of this problem in my opinion.
  10. Dirk Gregorius

    Moving circle to Aabb collision

    How do you know it is used in hordes of games? Do you know the collision detection specifics of this many games? I would actually assume that in most games these tests run through the physic engine in practice where it goes through the general sweep API. Physics engines have usually pretty optimized collision detection routines.
  11. Dirk Gregorius

    Moving circle to Aabb collision

    Th Well, that is indeed correct and of course you can sweep the sphere against each individual feature (face, edge, or vertex) of the AABB. But this is also the most expensive solution and unpractical in my opinion.
  12. Dirk Gregorius

    Moving circle to Aabb collision

    I was so surprised I couldn't find a reasonable simple solution to this problem and I discussed it with some colleagues this morning. The simplest solution we came up is described below. I haven't implemented and tested it yet though. The key observation is that you can approach this problem per axis. Essentially a dynamic separating axis test. In 2D the first two separating axes are the face normals of the AABB which are simply the global x and y axis. You need to compute the enter and exit times (t_min and t_max) where the distance of the moving sphere center along these axes becomes equal to the sphere radius. If you now inspect the case where the moving spheres hits just a vertex you will notice that these two dynamic separating axes tests are not sufficient. You need to test a third separating axis which in 2D is simply the direction vector of the ray the sphere is moving along. So in total you will get three intervals (one pair of t_min and t_max per separating axis) and the solution is simply the intersection of the three intervals. If I find time I might add some sketches and code examples later. HTH, -Dirk
  13. Dirk Gregorius

    Moving circle to Aabb collision

    This is a non-trivial test or at least I am not aware of a simple solution I could explain in reasonable time here. You might be able to use a Minkowski space approach. But to be honest I would just use conservative advancement. I recommend googling for some solution and then come back when you run into more specific problems. Sorry, I cannot be of more help. PS: I would start looking into C. Ericson "Real-time Collision Detection" or Gino v.d. Bergen book. Alternatively the collision detection part of "Real-time Rendering" is available for free here: http://www.realtimerendering.com/Real-Time_Rendering_4th-Collision_Detection.pdf. "Essential Math for Game Developrs" has also a lot of resources here: https://www.essentialmath.com/
  14. Dirk Gregorius

    Incorrect angular collision response

    This happens to me as well sometime. I think the reason is that you tend to look for mistakes in the math rather than for simple programming/typo mistakes. :)
  15. I recommend looking at the Maya documentation to get an idea how sophisticated the joint transformation can be in practice in a modeling package: https://download.autodesk.com/us/maya/2011help/API/class_m_fn_transform.html http://download.autodesk.com/us/maya/2011help/Api/class_m_fn_ik_joint.html You see that the joint transformations can be composed out of up to 15 affine transformations (if I counted correctly). Also depending on the transformation type the parent scale might not be propagated down into the child transformation. This is the reason why you most likely never want to query anything local (e.g the local translation or rotation) on a node since there is a large chance that it is not the value you are looking for. From my experience people usually compute the world space transformations of the parent and child. Then you transform the child transformation into the local space of the parent yourself. Finally you decompose the local matrix. Here is a simple example how to extract the transformation data from an FBX node // Transform FbxAMatrix GlobalTransform = Node->EvaluateGlobalTransform(); FbxAMatrix LocalTransform = GlobalTransform; // Hierarchy if ( FbxNode* Parent = Node->GetParent() ) { FbxAMatrix ParentTransform = Parent->EvaluateGlobalTransform(); LocalTransform = ParentTransform.Inverse() * GlobalTransform; } // Decomposition FbxVector4 LocalTranslation = LocalTransform.GetT(); FbxQuaternion LocalRotation = LocalTransform.GetQ(); FbxVector4 LocalScale = LocalTransform.GetS(); Note that when you later export animations the same idea holds. You move the scene forward in time, sample the global transformations, compute the local child transformation and then decompose. It is actually pretty easy if you do it this way. HTH, -Dirk PS: The local scale extraction can potentially go wrong due to limitations of the FBXAMatrix class. This is more of a theoretical problem though. If this is a problem you would still evaluate the global transformation, but store the results in your own matrix class and then decompose using whatever strategy works in your context. Again, this shouldn't be a problem in practice and I wouldn't worry too much about this. I just mentioned it for completeness!
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!