Jump to content

  • Log In with Google      Sign In   
  • Create Account

Journal of Aardvajk



Character Controller development

Posted by , 30 December 2012 - - - - - - · 676 views

Character Controller development I wrote a miniature level editor and have got the basics of a capsule-based character controller working now. It correctly collides with the various objects as you move it around, including sliding and resolving the awkward cases where resolving a collision with one shape causes a collision with another.

To address this, I do the collision detection and resolution in a loop that is capped at a maximum number of iterations but otherwise continues while the length of the collision resolution vector last returned is greater than a certain threshold. So it keeps resolving until the object is not colliding with anything. A cap of 10 is sufficient to resolve the case here, where the capsule attempts to move into the slope from underneath.

This is the majority of it solved now. Just need to deal with gravity and standing on/walking up slopes now. At the moment, the object moves very slowly up slopes and slides back down if a naive gravity is applied. Need to figure a way to do this better, then the basics of character controller stuff is done.


Christmas Adventures with Gilbert, Johnson and Keerthi

Posted by , 25 December 2012 - - - - - - · 842 views

Christmas Adventures with Gilbert, Johnson and Keerthi Seem to be getting there slowly. It is tough making this numerically stable but making progress. Just got some issues left with an infinite loop on the flat faces but I'm hoping the simplex at the time is close enough to the optimum.

Funny, would have expected the infinite loop to occur around the curves, not the flat features. Seems to be the other way around.

Oh, happy Christmas every one. Spending it on my own with geometry this year.

[EDIT] Finally, seem to have cracked it Posted Image.

For some reason in my implementation, there are certain faces on the Minkowski difference that I can't seem to get the simplex to resolve correctly when the shapes are disjoint to find the simplex closest to the origin, which is used when checking for the minimum separation vector between two shapes overlapping by only their margin.

This provides a far more accurate MSV than using sampling vectors around a unit cube, which is the fall back when the shapes overlap by greater than the margin - this is because GJK fails to find the closest simplex to the origin when the shapes intersect.

However, it seems that if I fail to compute a MSV with the GJK, I can then just fall back on the unit-sphere sampling method and this seems to return a consistent result along the face, so you still get a smooth sliding between the shapes.

The idea is to just step around a unit sphere creating normals and then project the furthest point on the Minkowski sum in that direction onto the vector. This provides the closest point on the Minkowski sum from the origin to the surface of the sum. Obviously you can only use vectors around a sphere to a fixed level of granularity although the operation is pretty cheap per vertex - assuming the vectors are precalculated, it is basically a dot product and a vector multiplication.

This will be even further improved by implementing an idea from Bullet - in addition to the unit-sphere vector checks, provide some "preferred" vectors based on the shape - these would be the negated face normals of polyhedrons for example. If the unit-sphere vectors do not directly coincide with these vectors, these vectors should "win" the test.

Huge amount of scope for improvement but all in all, I'm very happy to be sitting here on Christmas day 2012 having finally achieved something I've wanted to accomplish for about ten years - correctly detecting and resolving a collision between two convex 3D polyhedrons.

[EDIT]

Attached Image

All gets a bit easier now. Trivially implemented a support function for a cylinder and a slightly rotated cube (implemented as a polyhedron). The red pyramid is controlled by the keyboard and correctly collides with and slides around the three green volumes.

The next step is to provide each volume with its own transformation but this is trivial to implement without considering optimisations, which I'm not for now. Just take the normal into the support function, inverse transform it by the shape transform, get the result then transform the result by the transform.

I'm already doing something similar with the position, adding it to the result in the support so the point is calculated in local space but transformed to world space before returning. Obviously in the case of position, this has no effect on a normal so there is no need to inverse transform it first. Once we add in rotations for the volumes, it becomes necessary but easy enough to do.

I'm going to wait till this is fully working before I start to worry about making it more efficient. At the moment it has a lot of scope for improvements in this regard but that will be fun for later.

It will be interesting to see if I can build a reasonable character controller based on a capsule using this system - something I never managed using Bullet. I'm thinking somehow that we want a capsule sitting on a line segment perhaps but that is a problem for another day.


Visualising 3D Minkowski Sums

Posted by , 23 December 2012 - - - - - - · 680 views

Visualising 3D Minkowski Sums I've finished the development of the 2D GJK implementation, including both margin-based resolution for shallow penetrations and unit-circle sampling for approximate resolution for deeper checks and the time has come to start to try to implement this in 3D.

Something that was very handy during working out the 2D version of the algorithm was that I could sweep around a circle to generate an approximate set of points on the Minkowski sum and draw it as a polygon, so I could then draw the simplex I was refining.

So the first step for implementing a 3D version has been to create a method that can generate a mesh from a shape given only a support function. It works by sweeping directions around a unit sphere to generate the vertices, then stitching these into triangles, taking advantage of the fact that we know the order the vertices were added and rejecting any degenerate triangles that are formed.

Above is an image of a capsule built by combining two spheres, using the maximum dot of the point with the direction of each in the support function, but the mesh generator can work with any shape that you provide a support function for, so will be ideal for also visualising the Minkowski sum.

It creates a few more triangles than are actually needed so would require some refinement if it was to be used as anything other than a visualisation tool but is fine for these purposes.





December 2012 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Recent Comments

Recent Comments



PARTNERS