Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 01 Jan 2004
Offline Last Active Today, 12:51 PM

#5305801 Matrix Handedness Confusion

Posted by on 14 August 2016 - 03:31 PM

Does handedness only matter once there is a viewer?


Yes - this is right. Your maths (and physics etc) code is (should be!) exactly the same irrespective of whether the viewing system is right or left handed.

#5288573 Simulating Human with Rigid Body Joints

Posted by on 25 April 2016 - 04:23 AM

You can do a lot of balancing by just considering the ankles or, more generally, rotating the floor contact plane relative to the character. For side-side balance, the equivalent of "ankle balance" in the fwd/back direction is pushing down with one foot - and you can generalise this into having a target plane for the feet that. This works when the feet are at awkward angles too, and can be extended to handle the feet being on uneven terrain.


However, you can do a lot more than just balancing with the ankles/feet. If you imagine standing facing out over a cliff top, feet so near the edge you can't step, and somebody gives you a shove from behind, you use your whole body to balance/try to recover - leaning forwards at the hip and "windmilling" your arms. It's worth thinking about what these actions are actually doing, how they induce forces on your feet which are the only ones that can affect your COM - its position and velocity. Ankles/feet are good for COM position control. Upper body motion is good for COM velocity control.


There are two types of forces on the feet that are relevant - normal and tangential (the latter coming from friction). It's easy to imagine (or even do!) an experiment where there's no tangential/frictional force - e.g. standing on ice. The other extreme, where you have a single contact point (i.e. you can make use of the friction forces, but the centre of pressure is always fixed) is harder to experience - would it be possible to stand on the tip of a spike, where you have no option to balance with just "ankle control"? See the "Balance Controller (new)" video here for the answer! http://royfeatherstone.org/skippy/

#5288346 Simulating Human with Rigid Body Joints

Posted by on 23 April 2016 - 03:14 PM

1. Physics simulation:
Imagine a human standing on only one leg. That's a system of 20 bodies and the foot body and ankle joint has to carry all the weight.
Mass ratio here is 1:50, worst case for game physics libs. Bullet can't even simulate a stack of a few equal mass bodies without jitter (the last time i've checked),
and also it may miss the necessary features for powered joints. So it's not the best choice for a demanding simulation like this and you'll have to add a lot of work,
probably ending up doing your own constraint solver.
I have experience with Bullet, Havok and ODE, but when i tried Newton i was blown away by the difference in stability, accuracy and robustness it offers.
It's by far the best library for this kind of simulation - sadly only few people know about this.

If you want accurate, stable control of a mechanism with lots of joints and large mass ratios, the important thing is to be using an appropriate solver. Bullet does have a Featherstone solver, though I don't know how good it is for actively driving articulations. PhysX has an articulation solver, and I know from first hand experience that it can be used to drive articulations accurately, without excessive numbers of iterations/small timesteps.

* Cheat and use external forces to stabilize the system :)
(I assume Natural Motion does this, but that's just an assumption)

Your assumption is wrong :) Of course, we can use external "cheat" forces to add stability, but that's not the fundamental method (and it all works without this). I can't discuss the methods by which we calculate the joint torques, but the character is controlled by joint torques.

For example, there's some nice demo here:


You want to know masses and moments of inertia for the different body parts, and don't want to go to the messy trouble of chopping up a cadaver yourself? OK - take a look here: http://www.smf.org/docs/articles/hic/USAARL_88-5.pdf

#5282462 Airfoil simulation

Posted by on 21 March 2016 - 04:34 PM

IFor a proper airplane I'm planning on cutting wings into multiple pieces, which means that Cd approximation won't work anymore as using aspect ratio for segment of the wing (rather than full wing) will drastically lower drag coefficient.

Just use the aspect ratio for the wing on each segment.  

The question is, can I simply sum up Cl and Cd coefficients of wing section and aileron section...

No. However, you don't really need to get curves for the flap up/down and interpolate either - you can get a very good approximation by:

1. Adding a constant (depending on the flap deflection) to the CL curve.

2. Shifting the CL vs alpha curve left/right (depending on the flap deflection).

The way you do this depends significantly on the fraction of the wing chord that the flap occupies. Obviously if it's 100% (i.e. it's a fully moving surface) then the CL shift is zero, and the angle shift is just the flap angle deflection.

For more "normal" flaps you can estimate the CL offset, and you can practically calculate the alpha shift geometrically (calculate the change in angle between the original wing, and the new wing leading and trailing edges).

You might find two papers here useful:


Hope this helps - Danny

#5259409 Flight dynamic model issues

Posted by on 28 October 2015 - 07:11 AM

The lift force produced by a wing is given by:


liftMagnitude = CL * dynamicPressure * wingArea


dynamicPressure = 0.5 * airDensity * square(airSpeed)


CL = lift coefficient, which depends on the aerofoil and the angle of attack.


The lift acts in a direction perpendicular to the local airflow (this is not the same as the wing "up" direction).


If the wing isn't stalled, then a fair approximation for CL is CL = CL0 + alpha * 0.1 where alpha = angle of attack in degrees. However, for general flight you need to have lift/drag etc calculations over the whole range of angles.


CL0 is the coefficient of lift when the angle of attack is zero. For symmetric aerofoils this is zero. For asymmetric aerofoils this may go up to to 0.3 or so.


You'll also need to calculate the drag (which acts in the direction of the local airflow), and the pitching moment - the torque around the direction perpendicular to the drag and lift directions. When you look info about this it typically indicates the pitching moment assuming the lift force is applied at the "quarter chord" point - i.e. 25% of the way back from the leading edge of the wing.


Also - if you're representing the plane with a single lift/drag/pitching force/torque you'll also need additional terms to represent things like the rolling moment due to sideways movement etc.


Alternatively you can represent the plane with multiple lifting surfaces. If you do this make sure that the airflow is calculated taking into account the rotational velocity of the plane itself (otherwise if you roll the plane, then centralise the stick, the plane will carry on rolling etc).


I'm afraid if you're writing a simulator you can't neglect any of these things, and it's worth getting a handle on them before getting too far with the coding. There's an old simulator I wrote with source code: http://rowlhouse.co.uk/sss/ A new version, using the same system of representing planes using multiple (partly interacting) lifting surfaces is available at http://rowlhouse.co.uk/PicaSim/ - no source code for this, but you can use it to display graphically the CL/CD/CM curves and lift/drag for each component in the plane, and see how they're affected by changing the controls (you're welcome to reverse engineer this!).

#5257786 Using Physics to Generate Sound

Posted by on 18 October 2015 - 09:40 AM

This reminded me of some posts on the Bullet forums a while back:




Project info here:





#5177686 Fixed-Time step only for physics ?

Posted by on 02 September 2014 - 11:21 AM

If you have to ask, and want a rule that just works without having to think too hard, then use a fixed timestep.


if you understand the underlying system, can figure out what problems and benefits you might get, then a variable timestep might be better. it will depend on the game and platform. 


I use a variable step so that I always have an integer number of physics steps per render update - but that integer is adjusted to keep the physics step itself reasonable. I have no need for determinism, am confident that my simulation is well behaved for the range of timesteps that can occur, and as a result don't need to interpolate between physics frames (which can simplify debug output too). This is for my PicaSim flight simulator.

#5136273 PhysX - PxRigidDynamic clip through other actors (CCD enabled)

Posted by on 04 March 2014 - 03:52 AM

OK great - having looked for just a few minutes:


1. The way the box falls, it doesn't look like CCD is enabled - are you sure it's enabled in the filter shader as well as the scene and dynamic actor (I can see the flag is these two)? However, this is not the cause of the problem. 


2. Your box looks like it's about 50 units across. The contactOffset value is 0.02 which is tiny, in proportion. I'd suggest setting contactOffset to 1. But I don't think this will solve the problem. 


3. The scene is reporting gravity as (0,0,0) (and the object has eDISABLE_GRAVITY) - is that right? So you're applying gravity manually? I don't see why you shouldn't - a constant force shouldn't cause penetration problems... but maybe it is.


4. PVD doesn't report the tolerancesScale length/mass values - but it does say the "normal" speed is 10 units/s. When your box falls it his the ground at about 909 units/s


I would:


1. Disable CCD for the moment - it hasn't been reliable in the past (though is probably fine now)


2. Make sure the PxTolerancesScale is set correctly


3. If that doesn't work, see whether it's due to disabling gravity and applying the gravitational force manually (if this is it, it sounds like a PhysX bug).

#5136200 PhysX - PxRigidDynamic clip through other actors (CCD enabled)

Posted by on 03 March 2014 - 04:30 PM

Make sure the PxTolerancesScale values are sensible when you create your scene - as fanwars suggests.


Make sure your iteration counts are OK - e.g. 4 for position iterations is sensible, and 2 for velocity (penetration correction). Though what you're seeing is so bad that I don't think it's this.


Also make sure that the shape contactOffset and restOffset are sensible for your units, on all shapes, static and dynamic (but again, I don't think it's this).


If you can upload a short PVD capture I'll take a look...

#5094681 Advanced Character Controller based on PhysX 3.2.4

Posted by on 17 September 2013 - 09:53 AM

I haven't had a chance to download your code or study the video in detail (though with a brief look it seems good!), so please excuse me if I missed something you've already done/described, but here are a couple of features that aren't mentioned in your list, and are quite important:


1. Ability to push dynamic objects (optional)

2. Ability to be pushed by dynamic objects (optional)

3. Ability to step over small objects...

4. Without being able to climb really steep slopes (I'm not sure how it is at the moment, but I've certainly seen problems with vanilla PhysX CC where if you enable stepping the the slope limiting is badly broken)

5. Ability to enable a "stick to floor" mode for transition between slopes. So - if you're running along a flat surface approaching a slope down, then you shouldn't go airborne as you transition onto the slope - unless the transition is greater than some authored angle.


Anyway - I hope some of these might be interesting things to think about if you haven't done them already.


Cheers - Danny

#5092931 PhysX - Scene scaling, object size, timestep and gravity inconsistency.

Posted by on 10 September 2013 - 02:35 AM

physicsManager::update() {
float currentTime = clock();
   float deltaTime = (currentTime - mLastTime)/CLOCKS_PER_SEC;
   mAccumulator  += deltaTime;
   mLastTime = currentTime;

   while(mAccumulator > mStepSize) {
         mAccumulator -= mStepSize;



OK - I see you changed this after first posting it to replace two calls to clock with one as I suggested. Can you confirm whether it does/doesn't work now?


There's still a potential problem that, according to the above code, you're probably storing your absolute time (mLastTime) as a float, as well as converting it to a float immediately after getting it. When the time gets large - which may not take very long since I expect CLOCKS_PER_SEC is pretty huge, then your deltaTime calculation subtracts two huge floats - and the result will get less and less precise. 

#5092821 PhysX - Scene scaling, object size, timestep and gravity inconsistency.

Posted by on 09 September 2013 - 03:56 PM

about simulation numbers. ok, i spawned a unit sphere with a density of 1 at some height, and using PVD i measured that without any deltaTime scaling(so everything is slow-mo), gravity of -9.8f and stepSize of 1/30 it touched the ground in 2.5 seconds, falling 132 units from starting point. well, it's velocity wasn't constant, but i'm not sure how else can you measure it.


Do you mean that in 2.5 seconds (that is: 2.5 seconds of simulation time), your sphere, starting at rest, has fallen 132m? If so, that's much further than expected - you'd expect 0.5 * 9.81 * 2.5 * 2.5 which is about 30.7m. That would suggest your simulation is running faster than normal... so I'm not sure I've interpreted your numbers right.


In post 13 your loop multiplies by mStepSize, which is definitely wrong - but then you correct it in post 15. But it's still not quite clear what your latest version looks like.


In any case I'd expect this to work:

void update() {
        clock_t c = clock();
        float deltaTime = (c - mLastTime) / CLOCKS_PER_SEC;
        mAccumulator  += deltaTime;
        mLastTime = c;

        while(mAccumulator > mStepSize) {
            mAccumulator -= mStepSize;
        // Ideally call something like sleepInSeconds(mAccumulator) here

I've replaced two calls to clock with one. I wonder - with your current code, assuming your scene is really simple, that update loop may spend a lot of time just spinning round, whilst it waits for the accumulator to accumulate, in which case each time it will lose a little bit of time - maybe that's where your slowdown is coming from?

#5092756 PhysX - Scene scaling, object size, timestep and gravity inconsistency.

Posted by on 09 September 2013 - 11:06 AM

Physx...you might find yourself in trouble....there are not many(almost none) tutorials,or documentations for it


I don't quite understand what you mean - in my opinion/experience the documentation is extremely accurate, clear and complete. And the SDK comes with a bunch of samples, as well as tutorial/guides in the documentation. I'm not sure how anyone could ask for more, to be honest.


As for solving this problem - I'd recommend using the PhysX Visual Debugger - it's extremely useful generally, and only takes a couple of lines to set up the communication in your code. Then when you simulate, you can inspect pretty much everything, including the scene timestep, gravity, objects etc. If you're unsure whether things are moving as they should, set up a little test scenario in your game where you drop a sphere, and in the debugger check that it falls the correct distance in a given time period - distance = vel * time + 0.5 * gravity * time^2 


If you can't figure things out from that, you could even attach the pvd capture to a post here...

#5064083 Sloped Bullet Heightmap Inaccurate

Posted by on 23 May 2013 - 02:41 AM

@MrRowl - nice trick! The btHeightfieldTerrainShape is a concave shape though.


I'm not sure what you're getting at...


It is a concave shape, but still btConvexTriangleCallback ends up getting called. Making this change can improve the frame rate of my app from around 15 to 25 FPS on lower-end mobile devices.

#5063064 Sloped Bullet Heightmap Inaccurate

Posted by on 19 May 2013 - 02:16 PM

Using 2.81 version. It seems to be fast enough for my purposes (about a hundred objects falling on it at once as a demonstration/proof-of-concept). I'll keep that in mind though. Maybe commit your extra test upstream?


I just moved to 2.81, and noticed that there's still the same problem. Here's the modification that does the early out (it makes a really significant difference in my app - which is running on mobile devices so I need to get all the performance I can):


EDIT: Obviously this tweak is customised for my application which has z-up!


void btConvexTriangleCallback::processTriangle(btVector3* triangle,int partId, int triangleIndex)


  const btCollisionObject* ob = const_cast<btCollisionObject*>(m_triBodyWrap->getCollisionObject());
  //aabb filter NOT is already applied!
  // Quick check on AABB

  const btTransform& tr = ob->getWorldTransform();

  if (

    triangle[0].getZ() < m_aabbMin.getZ() &&

    triangle[1].getZ() < m_aabbMin.getZ() &&

    triangle[2].getZ() < m_aabbMin.getZ()






In addition there are some redundant calls to getVertex in btHeightfieldTerrainShape::processAllTriangles, which I've removed, but which will be insignificant!