• Advertisement

Randy Gaul

  • Content count

  • Joined

  • Last visited

Community Reputation

2775 Excellent


About Randy Gaul

  • Rank

Recent Profile Visitors

8190 profile views
  1. Everything you could want is in here, especially the pieces of GJK and continuous collision: http://box2d.org/downloads/
  2. Contact Area triangle sphere

    You should use GJK, except treat your sphere as a point. Then once you compute closest points, consider the radius after the fact. You can then take the distance between your witness points and compare it to your sphere radius to determine a hit. It is trivial to compute a contact point and normal once the witness points are available. You can use a special case to handle when the sphere center lays directly on the triangle. EPA should not be used for sphere to triangle.
  3. It's just a convention.
  4. Dealing with Non Center of Mass Translations

    Rotating something about an axis other than the center of mass can be computed by transforming the inertia at center of mass (COM) to the new location using the Parallel Axis Theorem (PAT). PAT can transform only to the COM, or away from the COM. It cannot be used to transform from an off-COM axis to another off-COM axis (but it is possible to transform to COM, then back out to the new position). https://en.wikipedia.org/wiki/Parallel_axis_theorem In the link look for the final equation under Tensor Generalization. There is a nice formula that can be coded using vector/matrix ops and the outer product.
  5. Creating 3D Collision Point

    Yep. 90% of groundwork to get a physics engine running is dealing with collision detection.
  6. Adding "Tilt" (depth) effect to overhead tactical game.

    There are quite a few ways to implement this, but the easiest would probably be to learn a bit more about mathematics and matrices. For example, a perspective matrix can be used to create the perspective effect you are referring to. Here are two resources to help get you started: https://www.essentialmath.com/book.htm https://en.wikipedia.org/wiki/3D_projection#Perspective_projection
  7. Make sure you also take a look at Erin's old Box2D *Lite* from 2006 (not the full Box2D library) download here, so you can see a straightforward implementation. Then you can verify your own equations and understanding by comparing with working code: http://box2d.org/files/GDC2006/Box2D_Lite.zip The solver is very easy to port to 3D. Getting collision detection in 3D is another story. For a full 3D example you can try reading my own code here (basically a Box2D *Lite* port to 3D): https://github.com/RandyGaul/qu3e
  8. From OBB-OBB intersection test to Sweep OBB test?

    You cannot form a simple equation and solve it if your OBBs carry angular velocity. Otherwise, conceptually, finding a time of impact (TOI) along a given axis can be done by simple linear interpolation. For example, say we have a point A traveling along a velocity V at a plane P. It is possible to do: d0 = Distance(A, P); d1 = Distance(A + V * dt, P); Then d0 and d1 can be used to lerp from A to A * V + dt by forming the interpolant: d0 / (d0 - d1). The same concept can apply to any axis and any given point, even axes and points on the surface of OBBs.
  9. Seperating Axis 2D Projection Issue

    Oh no do not bother printing to console. Debug render with lines and points on the screen, just like you are rendering your boxes!
  10. Seperating Axis 2D Projection Issue

    Nice work, I'm surprised someone found your mistake! A little tidbit of advice: make sure to start debug rendering some of your inner calculations next time you write this kind of code. You can render transforms, planes, normals, points, projected points, etc. to make sure you are understanding the linear algebra.
  11. I dunno. Test it out and see which one is better.
  12. If you try passing a bunch of SSE types as parameters to a function you will seen find you need __vectorcall on MSVC. Your tutorial author may have been just avoiding this and using a pointer instead. Whether a function call will be better off passing SSE types as parameters, or with pointers, depends on the context. It is not a straight-forward answer, unless you're just passing one or two XMVECTOR, then doing this as a parameter on 64bit builds will be good since floating point operations are going to be done in SIMD registers anyways (so loads/stores are super cheap or sometimes non-existent).
  13. 2d Physics: Solving for 2 Contact Points

    Your solver currently treats each contact point in isolation. Given the first contact point is perfectly solved, the second contact point, once solved, invalidates the solution to the first, thus causing jitter. A very good way to reduce jitter is to implement an iterative solver where the various contact points communicate with one another to somehow converge upon an acceptable solution altogether. My personal favorite resource for learning one good solution is under GDC 2006 here: http://box2d.org/downloads/. Specifically this link to the powerpoint and this link to the demo code.
  14. rigid body fixed constraint

    Just want to point out I wrote that before I knew much calculus. Although I did get it working, I didn't test it out much and the results weren't all that great. So probably not a good idea to use my link as a reference
  15. I don't have experience specifically with continuous cloth detection, but what is preventing you from using a mixture of CCD and DCD? Typically the solver does not care about what kind of collision detection is used, and can be black boxed from a collision detection point of view. Depending on your use case there can be many ways to simplify the collision detection. Maybe ray to triangle is not the best option, especially since rays can shoot through vertices or edges in your cloth mesh. Also your point, as represented by a ray, may not make sense either unless it strictly travels along a line over the given timestep.
  • Advertisement