• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

MrRowl

Members
  • Content count

    801
  • Joined

  • Last visited

Community Reputation

2490 Excellent

About MrRowl

  • Rank
    Advanced Member

Personal Information

  1. A quick search came up with [url="http://digitalopus.ca/site/bullet-physics-in-unity-3d/"]this[/url] 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!).
  2. 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).
  3. 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?
  4. 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: http://www.aerospaceweb.org/question/airfoils/q0150b.shtml   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).
  5.   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.
  6.   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.
  7. 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/
  8. 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: https://youtu.be/HauN98naZ9U   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
  9.   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?!
  10. 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.
  11. 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: http://m-selig.ae.illinois.edu/pubs/   Selig-2010-AIAA-2010-7635-FullEnvelopeAeroSim.pdf Selig-2014-JofAC-FlightSim-FINAL.pdf Hope this helps - Danny
  12. 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. 
  13.   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.
  14. 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!).
  15.   You could do that. However, collision detection is/can be costly, so an alternative is to separate out collision detection and collision resolution stages. Do the collision detection first and make a list of potentially colliding objects (i.e. even if the objects are separated up to some threshold, or currently moving apart, still include them in the list). Then for collision resolution stage, iterate through that list multiple times (either a fixed number, or until everything is resolved), resolving each collision if it's active (i.e. the separating velocity is negative) using the pairwise Newton law of restitution. During this process you'll just be updating velocities, not positions, and that means the iteration can be very fast - since the relationship between impulse and velocity change depends only on positions it can be cached once during/immediately after the collision detection stage.   If you want to sort that list by time-to-collision you can, but I don't think it will be noticeable the vast majority of the time (though it might be in artificial test cases!). If you're worried about determinism, them it might be simpler to enforce that through some means other than time-to-impact (for example, sort contacts by (x,y,z) position etc.), since time-to-impact may be expensive to calculate (and not needed for anything else), and of course you'd have to keep recalculating the times to impact as you update the velocities (if you wanted to be accurate).   There are lots of ways to do this, though - it's not too difficult to just try a few and see what works best for your particular application.