Jump to content

  • Log In with Google      Sign In   
  • Create Account

Dirk Gregorius

Member Since 24 Apr 2002
Offline Last Active Today, 07:30 PM

#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:



#5271118 3D Editor Transform Gizmos(Handles)

Posted by Dirk Gregorius on 14 January 2016 - 02:29 PM

You are looking for what is called 'Direct Manipulation':





The first link has a bunch of references. You might need to scan them to find out what is useful for you. I also recommend looking at Maya, Max or UnrealEd and see how their manipulators work. Artists are used to these tools and expect custom tools to behave very similar. 

#5269461 Collision detected due to IK subsystem

Posted by Dirk Gregorius on 05 January 2016 - 12:39 PM

You need a filter system system to disable collision. If you are using some physics engine it will have this already and you would e.g define a camera and character group and disable collision between the two. 

#5263048 Axis aligned boxes and rotations

Posted by Dirk Gregorius on 21 November 2015 - 04:18 PM

If you transform a mesh you need to recompute the AABB from its transformed vertices. This can be unnecessarily expensive for broaphase culling (e.g. in physics or visibility). A simple way to conservatively transform a given AABB is this:

rnVector3 TransformedCenter = Transform * Bounds.Center;
rnVector3 TransformedExtent = rnAbs( Transform.Rotation ) * Bounds.Extent;

Here the rotation part of the transform is a 3x3 matrix and rnAbs() builds the absolute value of each element of the matrix. This formula doesn't give you the best fit AABB like transforming each vertex, but it is conservative and will contain your transformed mesh (e.g. it can be larger than necessary and yield false positives). Note that I used the center/(half)extent form of the AABB here, but it is trivial to transform from/to the min/max form. I would also not worry about the performance if you need to transform between the two!


Conceptually this formula transforms the original AABB (which now becomes an OBB) and then builds its AABB.




#5256599 Contact points confuses me

Posted by Dirk Gregorius on 10 October 2015 - 06:35 PM

The reference face is not always on A! It is defined by the face that realizes the axis of minimum penetration. The contact solver solves:


dC/dt = ( v2 + w2 x r2 - v1 - w1 x r1 ) * n


It assumes that the contact normal is pointing away from body 1. So dC/dt computes the relative velocity as seen from body 1. If it is larger zero (that means in the direction of the normal) the bodies are separating. They are approaching/penetrating otherwise. So you need to make sure that your contact normal is properly oriented to work correctly with the solver.