Jump to content

  • Log In with Google      Sign In   
  • Create Account

Dirk Gregorius

Member Since 24 Apr 2002
Offline Last Active Yesterday, 03:05 PM

#5291951 Plane equation, + or - D

Posted by Dirk Gregorius on 16 May 2016 - 03:38 PM

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.




#5290700 Custom editor undo/redo system

Posted by Dirk Gregorius on 08 May 2016 - 02:26 PM

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:





#5289265 Lagrange multiplier in constrained dynamics

Posted by Dirk Gregorius on 29 April 2016 - 10:54 AM

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.


Thanks! I am glad you found it useful!

#5289162 Lagrange multiplier in constrained dynamics

Posted by Dirk Gregorius on 28 April 2016 - 05:21 PM

I think this is all related to Lagrange's equations (1. kind). You are not minimizing the constraint function but the Lagrange function which (IIRC!) the sum of potential and kinetic energy: 




I always found it difficult to find good material in English on this. In German there are tons of good resources...

#5285455 box-triangle test: how to ignore redundant edges?

Posted by Dirk Gregorius on 06 April 2016 - 11:31 AM

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.

#5279714 How do you go about a Property System for an Editor?

Posted by Dirk Gregorius on 05 March 2016 - 01:25 PM

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.



#5279703 How do you go about a Property System for an Editor?

Posted by Dirk Gregorius on 05 March 2016 - 12:12 PM

I am 100% with Alberth here. Besides the property you usually want all kind of meta data (e.g. min/max values, default values, tooltips, etc). This becomes quite inconvenient to add into the source using annotations. Quite frankly I am not sure if it really belongs there. You also need a programmer whenever you want to add a new property (e.g. you have a designer who wants to add a simple property he likes to access just from script for some quick test). A reflection based approach doesn't really create fast iteration times.


Stefan wrote some good articles on this problem here:




Reflection is useful for many things and I hope that it will be added to C++ soon, but I am not convinced it is the right tool for property editors. Imagine how hard it will be to maintain some fancy reflection library using macros or TMP compared to a simple schema file. 

#5277984 Integrating Bullet into an entity-component system

Posted by Dirk Gregorius on 24 February 2016 - 06:33 PM

I would not really use an ECS as it is often described currently all over the internet. For your use case I would have a entity with a transform and model member where both don't derive from a common component base class. You author the model in Blender and export from there into your game. The model can have the skeleton, render meshes, materials and physics information. Trust me, you really want to have the first class concept of a model in your engine.


For the integration you could e.g. have a PhysicsManager class which wraps around the Bullet world. The physics update then works in several phases:




   // For every kinematic body compute the velocity from the associated bone and set it on the body





    // For every dynamic body copy the position to the associated bone

    // For every kinematic body snap its position to the exact location of the associated bone

    // You can also iterate contacts here and callback into the game





    for ( n substep )






This is very high level and there is a lot more detail here. E.g The physics manager would not really iterate over all bodies in your world, but maintain a list of active (awake) bodies. So in those iterations I showed above you would ideally do nothing if everything is inactive/asleep. This will require you to setup the sleep callbacks appropriately. A naive integration would have high simulation time even if the whole physics world is doing nothing just by iterating blindly over every body.


In the physics manager you also wrap the raycast and volume query API. E.g. when you cast a ray in Bullet you will get a rigid body if you hit something. You need to convert the body into a game entity and the physics manager is where this happens. You can e.g. associate the entity with a body using its user data. 


If the game is reasonable small you can route all you code through the physics manager. E.g. when you load the model and create the model instance from it you iterate the body description and create the btRigidBody through the manager. You can now return that pointer or a handle to the body which is maintained in the manager. In the later case all updates would go through the manager where the handle gets dispatched.


A common problem is what to do if you don't have a skeleton for your model. One simple solution is to have at least one root bone (e.g created automatically when instating the model) which is then associated with the entity transform. Of course you can have special handlers to handle both cases, but this can make the code ugly though.




#5277917 Integrating Bullet into an entity-component system

Posted by Dirk Gregorius on 24 February 2016 - 11:45 AM

Where will these components be authored? E.g. if you build your models in Blender the bodies and shapes could even be simply a part of a model component. I would only add that kind of granularity if you want to author everything within some kind of custom editor. 

#5276747 Verlet integration and dampening

Posted by Dirk Gregorius on 18 February 2016 - 09:14 PM

In step 3 you have a 'v' too much on the right hand side. And obviously you derivation is wrong as you are missing the v0. In order to get this you need to add an integration constant  (in step 4) and then solve for v(0) = v0. I can provide a full derivation, but maybe you try yourself first. 

#5275360 How do i solve this specific scene graph problem

Posted by Dirk Gregorius on 11 February 2016 - 06:38 PM

You can also undo the scale of the parent in the child node. Simplified something along those lines (note that you undo the scale after the translation):


M1 * M2 * v = M1 * ( T2 * S1^-1 * R2 * S2 ) * v 


IIRC this is what Maya does for the IKJoint:


#5273763 Resting Contact With Friction

Posted by Dirk Gregorius on 01 February 2016 - 07:07 PM

I recall I have seen this problem being discussed endlessly in text books on technical mechanics.


Here is a discussion of the problem. It starts at page 229. Luckily it seems mostly all there:



I own this book and can recommend it. It is a good read on non-smooth mechanics.

#5273735 Window Creation in Win 7

Posted by Dirk Gregorius on 01 February 2016 - 03:22 PM

I found it useful to look at DXUT: 



Maybe another example to look at would be Freeglut:



I used both as examples for my physics testbed years ago and never ran into any issues. Both should have examples for what you are trying to achieve.




#5273720 Resting Contact With Friction

Posted by Dirk Gregorius on 01 February 2016 - 01:50 PM

The LCP formulation using acceleration can create infinite friction forces. You are actually showing the classic text book example here. In computer games we use a velocity level LCP and forces are now impulses and you don't have the problem of infinite forces there anymore. Pretty much what you say here happens then kind of automagically (a force applied over a very short period of time is an instant change in velocity aka as impulse):


I thought about this situation and what would happen in the real world. I think there would be a very large reactive and frictional force applied over a short period of time that would stop the vertical box moving to the right


Note that you can improve friction a bit compared to Irlan's box clipping. Instead block solve the 2x2 LCP along the two friction axes and then use Pt1^2 + Pt2^2 < ( mu * Pn )^2 for clipping. This way you can use more coherent tangents and don't need to align them with the relative velocity in the contact plane. This is an implementation detail though.

#5272385 Convex Hull computation

Posted by Dirk Gregorius on 23 January 2016 - 12:50 PM

Did you see my presentation on implementing Quickhull?




I learned it from this Java implementation here: