Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2490 Excellent

About MrRowl

  • Rank
    Advanced Member

Personal Information

  1. MrRowl

    Capsule Inertia Tensor

    Thanks for this. However, eq 14 has an error! Where it says H^2/2 that should be (H/2)^2. The code is correct, but of course nobody would just pinch that
  2. A quick search came up with this so it looks like it's been done. I don't use Unity so can't offer any opinion on it, though. Why do you think Bullet would be better than PhysX (that's not a loaded question - just interested!).
  3. MrRowl

    Better PhysX Character Controller

    Havok supply and recommend a CC using a simulated rigid body, and it's really good, from what I remember. They also used to supply a kinematic one, which was also really good (not sure if they still do - haven't looked recently). The point is - either can be made to work... but neither is easy to implement if you want it to work fast and robustly in non-trivial situations (e.g. interact nicely with physical objects, ride on moving objects etc).
  4. MrRowl

    Better PhysX Character Controller

    In the video the shape is not a cylinder - it's a convex hull (approximating a cylinder).  That doesn't help completely, because the supplied PhysX CC doesn't support convex hulls either! However, the collision system in PhysX does support convex hulls, but not true cylinders. I would guess that they either added support for convex hulls to the existing character controller (probably not that hard, since you get the source code), or possibly they just wrote their own CC from scratch. There are two ways to implement a character controller: 1. As a rigid body that is constrained to stay upright. Move it around with forces, and it will impart forces on other objects, and also receive forces. The big thing here is that it gets updated with everything else, in the single simulation step. 2. As a kinematic shape that is updated separately from the simulation (though typically you'd update all the CCs at once). You've got a slightly less physicsy interaction with other objects, but the argument goes that character movement doesn't tend to look right/be well controlled if it's done through forces, since you never really know what's going to happen (so it's hard to match the animation to it). This simultaneous/separate update is important if you're using animation on your characters, since the animation you play is tightly coupled to the character movement. Which determines which (it depends on your game)?! Also, if you are using physical simulation on part of your character, that affects things too. If you've got a large share that hasn't got rotational symmetry then you'll have more work to do, since I don't think PhysX really supports that. For example, if you've got a long character that rotates near a wall, should the CC push out from the wall?
  5. MrRowl

    Rudder force

    The rudder will work like a wing - which means:   1. Sometimes there will be laminar flow over it, and sometimes it will be stalled.    2. The forces on the rudder can be calculated as the sum of the lift force (which always acts in a direction perpendicular to the fluid flow relative to the rudder - so it's not the red arrow, but will act directly to the right in your diagram, given the blue arrow is pointing "up"), and the drag force (which always acts in a direction opposite to the fluid flow). These forces will be proportional to the square of the (local) fluid speed, the rudder area, and the coefficients of lift and drag.   You need to remember that you need to calculate the local fluid flow velocity at the rudder. When the boat is turning, this will not just be -v.   You can actually estimate these coefficient of lift (CL) and drag (CD) values pretty accurately - but you might need to do so over the whole 360 degrees - i.e. you need to know CL and CD  as a function of angle of attack. I'd expect them to look rather similar to curves in air - so if you have something that looks like this it should work OK:   Alternatively, if your boat has got a keel, when the fluid flow is significantly from the side, the effect of the rudder is probably minimal - in which case you only need to calculate the rudder force when the flow is laminar. For this CL is going to be directly proportional to alpha (the angle of attack) up to around +/- 15 degrees or so - then the rudder will stall and you can set it to zero. CD will be something like constant + alpha^2 up to the same angle (and beyond that you could clamp it).    This might all be overkill if you're not trying to do anything like a proper boat simulation :) If you want something simpler, just making the torque proportional to the rudder deflection and forward speed will probably work (assuming you have another rotational damping term that represents the reluctance of the boat (due to the keel) to turn when moving fwd/back).
  6. MrRowl

    Matrix Handedness Confusion

      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.
  7. MrRowl

    Rotational spring stiffness?

      Yes... except that for small bending angles, the displacement of the end particles (up/down in the OP's diagram) will be mostly orthogonal to the direction along which the spring acts (left-right). So I'd expect the proposed new spring would be effective at preventing substantial bends, but not very effective for keeping a plane flat when it is supposed to not bend very much at all.   If you want to represent very stiff planes, then it might be better to consider adding a spring between the centre particle and the mid-point between the end particles. You will then need to consider how to map the force applied to the mid point to the particles themselves (trivial if all the links have the same rest length, and the particles have the same mass) - you need to make it so that momentum is preserved. If you do this then for small angles, the spring force will be approximately proportional to the bending angle, which is probably what is desired.    Alternatively, it might be even better and just as quick to do the job properly: labelling the particles 1-2-3, take the cross-product between the directions 1-2 and 2-3. This is proportional to the torque vector you want to apply, and the pairs of linear forces will be given by the cross-product between this and each of the deltas 1-2, and 2-3 (divided by the squared delta magnitudes) - since torque = delta x force. You apply a force f1 to particle 1, and apply -f1 to particle 2. Similarly apply f3 to particle 3 and -f3 to particle 2. This preserves momentum. You don't need any trig functions for this, and if you can precalculate the delta lengths, then you might not need any square roots either.
  8. MrRowl

    Simulating Human with Rigid Body Joints

    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!
  9. MrRowl

    Simulating Human with Rigid Body Joints

    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.   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:
  10. MrRowl

    Airfoil simulation

      You need to be careful that you handle the varying air flow speed and angle of attack over the wing. For example, if the plane is rolling, then this doesn't change the angle of attack much at the root, but it does (increasingly) towards the tip. This is what makes the plane stop rolling almost as soon as you centralise the ailerons. It sounds like you're in danger of losing this (which would affect every other characteristic too) - or did I misunderstand?!
  11. MrRowl

    Airfoil simulation

    Not quite sure what you're getting at... I'd say the graph of CL vs alpha show two things: 1. +ve flap deflection shifts the graph left by pretty much the same amount at all angles of attack 2. +ve flap deflection shifts the graph up, but only in the non-stalled regions. Also, it has a greater effect in the normal flow region than for reverse flow. If you mentally do the "horizontal" shift first, then you'll see there isn't much/any "vertical" shift left in the stalled regions. It's true there's some slope introduced, but mostly it just shifts up/down in the non-stalled region. Cm curve is a bit weird as it's around the 1/4 chord point - which is obviously the wrong place for reverse flow! It will be zero at alpha=0 and flap=0, and will be close to zero for the non-stalled region. Yes - exactly that. I use that geometry to estimate the change in effective angle of attack (the horizontal shift), plus some heuristic for the vertical shift.
  12. MrRowl

    Airfoil simulation

    Just use the aspect ratio for the wing on each segment.     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:   Selig-2010-AIAA-2010-7635-FullEnvelopeAeroSim.pdf Selig-2014-JofAC-FlightSim-FINAL.pdf Hope this helps - Danny
  13. MrRowl

    "Real-Time" Smoothing

    Kalman filtering: You have a model of a system, and maintain an estimate of its state. Each update you make a prediction of the new state, which is then updated with measurements. 
  14.   Whatever you do, remember this: Newton's Law of Restitution is only correct (and even then it's only a law) for collisions between two particles (no rotation).   In practice, you can apply it to a single contact between two objects that can rotate. I'm not sure if this gives you physically correct behaviour, but it will look fine.   In practice you can apply it to multiple contacts between a pair of colliding objects. Again, I suspect this doesn't give you physically correct behaviour, but it will look fine.   In practice you can apply it to multiple contacts between more than two objects (i.e. simultaneous collisions) so long as the coefficient of restitution is zero. You can use this to solve for resting contact.   However, if you apply it to multiple contacts between more than two objects with non-zero coefficients of restitution, then if you enforce that law for all contacts simultaneously, you'll get implausible results. Just work through the example of a Newton's Cradle, which is similar to your example. If you apply the restitution law to pairs of contacts sequentially then you'll get plausible results, though (a) the exact result will depend on the order in which you process the pairs and (b) you may not get complete convergence in a sensible/finite number of iterations.
  15. MrRowl

    Flight dynamic model issues

    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: A new version, using the same system of representing planes using multiple (partly interacting) lifting surfaces is available at - 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!).
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!