Think of a ball resting on the ground. The contact point is only active if the ball is accelerating downwards. In the moment you pick it up there is no contact force.
I think the confusion here is about the term linear system. Richard means a system of linear equality equations. You cannot model contact with equality constraints. You model contacts using the Signorini conditions (should also be in the citied paper) which makes the problem an LCP. The LCP is still linear, but with inequalities and the complimetary condition. If you would use a linear condition you would get sticky contacts.
The complimentary condition is what is essential for modeling contacts. If the relative acceleration is larger zero the contact force is zero. Or the contact force is active and removes all relative acceleration.
A good excersise is to solve a 1d LCP and then translate the meaning to the contact problem.
So yes, global LCP solvers can indeed solve this as well. There is a whole lot of problems with overconstrained systems. The four leg table is a good example. The solver can give you mg/2 in two diagonal legs and you would get the correct dynamic response. All variations that create equilibrium are feasible, but we know that we have in each leg a force of mg/4. I think Mirtichs PhD talks a bit about these problems.
Thanks, I am glad you like it. If you are interested in these kind of presentations (what your name suggests) you kind find a lot similar presentations on the GDC Physics Tutorial website hosted on Box2D: http://box2d.org/downloads/
Similarly, the GDC Math tutorial has lots of presentations collected over the years as well:
Your observation is totally correct! None of the triangle/triangle tests (SAT, Moeller, ...) handle the co-planar case by default iirc, but all rely on handling it as a special case. Sorry, I should have pointed that out. I only read over the SAT part and the possible separating axes.
His question demonstrates why there are additional planes/axes to test for beyond the 3*3 edge cross products (and 2 plane normals). For each triangle, besides the main plane, there are also 3 additional planes/axes, totaling 17 (3 * 3 + 3 + 3 + 2). The 3 extra per triangle are the axes constructed with the cross between each edge and the plane normal (for right handed/clockwise triangles). The same reason is there are 15 for OBBs and not merely 9.
Sorry, what you are writing is simply wrong! You only need to test axes that build a face on the Minkowski sum of the two triangles and there are *exactly* 11 possible separating axes you need test for two triangles. I recommend reading Christer's and Gino's books which are great resources on this topic.
I think about planes as being defined by a normal n and a point on the plane p. Then we can define the plane as (read * as dot-product):
P: n * x - n * p = n * ( x - p ) = 0
We can now define d = n * p and get:
P: n * x - d = 0
I thinks this is the more formal definition that you would find it in a textbook. If you use 4D vectors for planes and want to define the distance of a point to a plane using the dot product you would define d = -n * p which yields:
P : n * x + d = 0
I think the 4D vector definition also works well with transformations where you simply multiply the 4D 'plane' vector with a 4x4 transformation matrix (not sure though). Personally I prefer with the more formal definition and use explicit plane functions to evaluate the distance to planes or transform them. If you want to wrap everything into a generic 4D vector the later might be the better choice.
Assume you have decoupled your editor into a scene description (model) and a UI presentation (view), There are now two ways you can implement Undo/Redo:
In the first scenario your scene description (model) doesn't know anything about undo/redo and all changes to the scene inside the UI layer go through commands that are stored on a command stack which can be re-winded. E.g. The scene class has a addNode() function and in the UI you create a command that adds a new node to the scene and removes it again in redo.The Qt Undo framework is indeed a nice example for this approach. This is also a nice blog post on this approach:
In the second scenario the undo/redo is implemented in the model directly. E.g. whenever you change a node the old state is somehow serialized and can be reset if needed. Note that you don't need to store the whole scene, but only the sub-tree that is about to change. The advantage of this approach is that is easier to implement and you cannot mess up undo/redo in the UI by forgetting changing the scene through commands instead of the scene model API. On the downside it is intrusive in the scene description. Mikko has a short blog post about this approach here:
I think you might be a bit to concentrated on the term 'Lagrange Multiplier'. The important part here is that you know the direction of the constraint force is the gradient of the constraint function and you only need to find a scalar multiplier to determine the constraint force. The reason for this is that constraint forces doesn't do work. IIRC you can show this using virtual displacements. Maybe concentrate a bit more on the physical meaning rather than trying to be overly mathematical abstract.
Well, you can mark up your triangle mesh. Check the adjacent faces of a shared edge and mark edges as concave, convex or flat. You can also mark concave vertex. A vertex is concave if at least one adjacent edge is concave. When you check the edges, you simply skip over those that are concave.
I don't think that concave edges should be skipped though. In your example image just move the the lover right vertex of the box such that it is exactly coincident with the concave edge and pressing into it. If you ignore the concave edge you can be pushed out of the world. I assume that have wrong contact geometry and I would debug this first.
Here is another good presentation on reflection by my colleague Sergiy.He used Clang and a bunch of other tools to automatically generate the reflection data. It is a pretty amazing system.But again I am not sure if I would use this for properties.