Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by CombatWombat

  1. CombatWombat

    Gyro + Accel values into useful values.

    I think you need to break this down a bit before trying to jump into detecting certain motion paths. Use the gyro and accel data together to form a reliable estimator of orientation and orientation rate of change. Unfortunately this is non-trivial, because it involves things like Kalman or complementary filtering to combine the data, so I'd have to second Nagle's suggestion of investigating a ready made solution from the drone community. You might want to look into using an IMU board designed for drones that also give you magnetometer data for 9 DOF. This can make your orientation estimate better. Some of the drone algorithms will likely have position estimation as well, since they typical do things like "return to take-off point" and enforce "no fly zones" (via GPS, though). Possibly you could plot position estimates over time (essentially the "path") and then check if those points are within some geometry to determine if you are doing "the sweep" motion. Maybe keep a rolling log of the last 100 positions (or however many) and compare that path to a known path that represents the sweep you want to trigger on. Sorry if this is kind of "hand wavy" and general.
  2. CombatWombat

    Action points or not?

    FWIW the "two action" system used in the newer X-COM games had some clunky issues relating to skills/perks that would refund actions or grant bonus actions, because not all actions were "equal". IE: "Implacable" which granted a free "move" action after getting a kill. Could you shoot with that action? Use skill "X"? What about when combined with "Run and Gun" which allowed using both turns to move and then still shoot, but implemented by granted a 3rd action? The interaction of these abilities is *really confusing* and causes even players with hundreds/thousands of hours into the game to sometimes second guess how things will actually work. There's also the weird fact that shooting cost 1 action. But only if its your second action. If you don't move, then it cost both. Weird. Summary: The "simpler" 2 action system can be....not. Depending on implementation.
  3. CombatWombat

    Customizable front page?

    I don't like the left bar. Also get off my lawn. Now excuse me I have to go yell at some clouds.
  4. The radius of you turn will be velocity/turn-rate (for constant velocity and turn rate). Watch your unit conversions. For your example, at maximum 15m/s and 45 deg/s turn rate, you can turn with a radius "R" of 19.09m. Consider this crazy picture. With "R" solved, you can check your target point. Project a distance "R" normal to your velocity vector. From this center point, if your target destination "A" is inside a circle of radius "R", then you cannot reach the target point without slowing down. You will need a circle for "left" and "right" directions obviously, so you can project both normals for this.
  5. CombatWombat

    Limited-Slip Differential and friends

    So like.... https://en.wikipedia.org/wiki/Six-wheel_drive ? I'm now picturing armored personnel carriers racing around Monaco. That's a game I would play. Yes, but again the effects are pretty small except in very specific circumstances (one wheel on low grip surface for example). I'm not saying don't tinker with fancier setups, but it's good to make something simple that works well first and then build on that. This is a big area depending on how deep you want to go. There are commercial software packages out there that simulate engine parameters for purposes of designing real engines such as Dynomation, Pipemax, and many others. There was an old game, Burnout Drag Racing that had a pretty detailed engine simulation built into the game! The short answer to this direct question is "sort of". An engine will make X power at atmospheric pressure (1bar). If you add another 1bar of boost and were somehow able to hold every other variable constant, it would make close to 2X power. If I get some time this evening I will try to write you up something more in depth.
  6. CombatWombat

    Limited-Slip Differential and friends

    Maybe. It's a matter of semantics and will change your other scaling values but shouldn't change how things fundamentally work. In reality it needs some resistance working against the input torque to generate the locking forces. That resistance will be a combination of inertia of the wheels/axles and grip generated by the tire. So, for all intents you can just look at the input torque and trust in the 3rd law that there will be a reaction. For the most part, diff effects will be very subtle. Even if commercial racing games it can be tough to tell the difference between locked and open. Unless you're doing some kind of off-road rock climbing racer. Then it matters. So for AWD, a simple viscous type (tries to equalize speeds with a linear torque based on speed delta) is probably Good Enough™.
  7. CombatWombat

    Limited-Slip Differential and friends

    Hello Vu, Would be nice if someone else would happen a long and try to help, but this place seems quieter than it used to be. I have not tried to do a differential model, but I will try to offer what advice I can... For starters the wiki page on limited slip diffs is actually pretty good, start there if you have not. As a very general overview, I would say there are two types that you may want to model: 1) Torque sensitive types, which encompasses ramp loaded, clutch type, and probably Torsens. The most "general" is the ramp type, since it is very tune-able. 2) Speed sensitive types, which is pretty just much viscous types. So the differential has no idea what the throttle is doing. Most of them use the loads transmitted by the spider gears in various ways to engage the clutches, so they are sensitive to the torque coming in at their input. So you can use your torque after it is multiplied by the transmission gear in your function instead of throttle. I would suggest forgoing geared type LSDs at this moment. They are kind of an oddball in the automotive world (other than Audis?). They are torque sensitive, yes. I don't know in terms of "bias ratio". What happens is the torque causes some leverage on the clutch plates which push them together making the two axles want to turn the same speed. Some very rough psuedo-code. You have to experiment with the values to make sense! driveTorque = getDriveTorqueFromTransmissionOutputShaft(); LSDClutch.friction = 0.5f; LSDClutch.preload = 100.0f; LSDClutch.accelRamp = 1.0f; LSDClutch.decelRamp = 0.5f; if(driveTorque > 0.0f) LSDClutchTorque = preload*friction + accelRamp*driveTorque*friction; else LSDClutchTorque = perload*friction + decelRamp*-driveTorque*friction; speedDelta = axleL.speed - axleR.speed; if(speedDelta > 0) // left axle is faster axleL.torque = 0.5f*driveTorque - LSDClutchTorque; axleR.torque = 0.5f*driveTorque + LSDClutchTorque; else axleL.torque = 0.5f*driveTorque + LSDClutchTorque; axleR.torque = 0.5f*driveTorque - LSDClutchTorque; Yes. As long as the spiders have the same number of teeth. (This will be the case for all automotive differentials).
  8. CombatWombat

    Clutch Modelling Help

    Yes pretty much. Maybe. It's also highly effected by the masses/inertia, tire "stiffness", etc. Yes, but only for one frame. The next frame it might be -500. It might do +500, +500, -500, as it oscillates around the target set point. It should average out very close to 400Nm over enough frames. The linear model I sent in the xls definitely averages out where the transmitted torque is nearly equal to the engine's torque produced (it will not be exact as some of the torque is required to accelerate the engine's own inertia.) It should work similar with the more "digital" model, but you'd need to experiment. Does your model now work properly, but exhibit some other strange quirks? Or does it still completely run-away? So, this is a bit above my pay grade, but in general I'd say this problem could be described as trying to solve a 1D velocity constraint. So I'd wonder if some of the techniques used in collision response (sequential impulse, etc) might be applicable here. Anyone?
  9. CombatWombat

    Clutch Modelling Help

    It does not. Look again at the implementation. Integral is integral of a PID controller. Essentially proportional gets you close, and then integral compensates for the long term error. Real clutch only applies that 500Nm (or whatever) until the nanosecond it's speed has equalized. In discrete time you are stuck applying it for the full 10 ms. This makes it jittery. The proportional model is smoother in this respect. As bmarci said in a previous post, and good plan is to lockup when the sign changes (zero crossing). lastSpeedError = speedError; speedError = engineSpeed - drivelineSpeed; if(sign(lastSpeedError) != sign(speedError)) // Zero crossing, lockup. Used the constant type, but with a lockup method that summed the inertia of the entire driveline and treated it as one part, so the jitteryness wasn't apparent. C++. Engine wasn't mine, but was rolled from scratch for the game.
  10. CombatWombat

    Clutch Modelling Help

    I put something together that may help. Hope .xls can be attached here. If not PM and I will email it. Looking at the chart: First ~50ms or so, clutch is disengaged. You see engine accelerates freely, and gearbox coasts. When clutch engages, engine speed dives down, and gearbox speed increases until they match. In this, I used the linear/proportional model: clutchTorque = SomeConstant*(EngineSpeed-DrivelineSpeed) This works, but there is significant slippage as drivelineSpeed constantly lags behind engineSpeed. So I added an integral term. So the above becomes something like: speedError = EngineSpeed-drivelineSpeed; integralError += speedError; // Make sure not to add to integralError when the clutch is disengaged! clutchTorque = proportionalConstant*speedError + integralConstant*integralError; There is a somewhat narrow range of values for proportionalConstant and integralConstant where this works and is stable. Mostly because I'm using simple Euler integration here at only 100hz. You can experiment with adding derivative term, using better integrators, or upping the refresh rate to get better stability. Or switch to a locked model once the speeds get close. ClutchModel.xls
  11. CombatWombat

    Clutch Modelling Help

    Using that linear model you are simulating something closer to a torque converter (fluid coupling used in automatic transmissions) rather than a clutch. So that's why there's lots of slipping. This can be ok, maybe you just need "stiffer" constants: clutchTorque = 50.0f * (engineRPM - drivelineRPM)... //or clutchTorque = (engineRPM - drivelineRPM)^2 ... //etc Or if you just do: if(engineSpeed > drivelineSpeed) clutchTorque = blah; else clutchTorque = -blah; Then you will have lots of torque as soon as you have 0.00001 slip. You might need a combination of the two to get enough clutch "grab" but not have an unstable simulation. which is a very small amount of torque. Why is it a small amount? You get to choose the frictionConstant to be whatever you desire. Maybe I confused you with using frictionConstant as the name. I did not mean to suggest using something like 0.5 mu friction coefficient. A real clutch has friction coefficient (0.5ish), heavy springs (~5000N+ normal force), and a mean radius (~0.125m) = ~312Nm. Using something like 500-1000 for frictionConstant is not unreasonable. engineNetTorque drives the whole engine blob of mass. Full stop. Period. Do not confuse yourself with fractions of anything. SideB of the clutch doesn't know what engine is doing. It has no idea if there is an engine there at all. Maybe its a hamster in a wheel. Doesn't matter. SideB only knows that SideA is rubbing against it with some normal force and coefficient of friction. You don't have to. You have some torque acting on SideB of the clutch (again, because SideA is rubbing against it, nothing to do with engine). That gets multiplied by the gearbox. You give this to your UnityWheelThing, it performs integration and has a new speed. Next frame, you read that speed, multiply it by gearbox ratio, and that becomes the new speed for clutch-side-B.
  12. CombatWombat

    Clutch Modelling Help

    Your implementation looks close, but let's put some numbers and see where it's going awry. // Let's pick some reasonable starting conditions for trying to accelerate. // EngineRPM: 1000 [104.72 rad/s] // DrivelineRPM: 0 [0 rad/s] // EngineTorque(1000) = 400 Nm // 1st Gear Ratio: 3.00 // Final Drive Ratio: 3.73 float clutchTorque = (engineSpeed - driveTrainSpeed) * (1.0f - clutchInput) * clutchStrength * gearClutch; // (104.72 - 0) * (1.0f - 0.0f) * 10.0f * 1.0f = 1047.2 Nm // This is a lot of torque and should definitely accelerate something! // I would lean towards calling this "clutchReactionTorque" or something similar. // It is the torque acting between the two discs. float engineOutputTorque = currentTotalEngineTorque - clutchTorque; // We're saying engine is making 400Nm, so 400Nm - 1047.2Nm = -647.2Nm. // I would call it "engineNetTorque". We're not actually "outputting" it anywhere. float clutchOutputTorque = (engineOutputTorque + clutchTorque) * (1.0f - clutchInput); // I don't understand this, really. I think it might be where the problem is, but let's try anyways... // (400Nm + 1047.2Nm) * (1.0f - 0.0f) = 1447.2 Nm. // I think correct line would be clutchOutputTorque = clutchTorque; // This is because if you draw FBD of the clutch output plate, it only // knows about clutch input plate and gearbox. It has no idea what engine is actually doing. // It only knows that clutch input plate is rubbing against it with some friction force. float outputTorque = clutchOutputTorque * currentGearRatio * finalDriveRear; // 1447.2Nm * 3.0 * 3.73 = 16194.17 Nm. This is a big number of torques. So something should drive somewhere. currentEngineRPM += radsToRPM((engineOutputTorque * Time.fixedDeltaTime) / engineInertia); // so, we saw that engineOutputTorque is actually -647.2Nm, so the engine should slow down. //finally drives the wheels RR.motorTorque = outputTorque / 2.0f; RL.motorTorque = outputTorque / 2.0f; // Each wheel receives 8097.09 Nm. So assuming the sign is correct (positive number rotates so the car goes forward), // then wheel speed should increase. Drivelinespeed should increase. Enginespeed will decrease as we saw above. // This brings clutch plate speeds closer together. So things appear to be close to working. // Try outputting debug numbers and see if things are behaving as above. What was said above about switching to a "locked clutch" model when speeds equalize is a good idea, but it shouldnt be necessary to get things driving presuming your integrator is stable enough that things don't completely explode. Edit: I would like to clarify that for the model as shown, the clutch and gearbox are both kinda of "virtual". We have not assigned mass or inertia to them. In a way they are just typedefs or "specially named attachment points" of the engine and wheel, since those are the only things with mass in the system. Specifically, the "A" side of the clutch will always have the same speed as the engine. It is effectively part of the engine, but we give it a special name for convenience. Same with the "B" side of the clutch, the gearbox, and the wheels being one "unit". See the following, because MSPaint is THE tool of the future: FreeBodyDiagram
  13. CombatWombat

    Clutch Modelling Help

    Well. It's been a while since I've done this stuff, but let me see if I can help. Let us refer to this diagram. Engine will look like: torqueProduced = throttle * torqueLookup(RPM); // throttle 0.0f - 1.0f frictionTorque = frictionTorqueLookup(RPM); // could be a constant value or linear to RPM. You need to experiment engineNetTorque = torqueProduced + clutchReactionTorque - frictionTorque; engineAngularAcceleration = engineNetTorque/engineInerta; Gearbox will look something like: outputShaftSpeed = drivenWheelRPM; // Let's ignore the differential gearratio and bake it into the gearbox overall ratio. inputShaftSpeed = outputShaftSpeed * currentGearRatio; // Lookup based on current gear selection. outputTorque = clutchReactionTorque * currentGearRatio; Driven wheels: netTorque = reactionTorqueFromGround + (gearboxOutputTorque / numDriveWheels); angularAcceleration = netTorque/wheelInertia; Now the bit to put it all together... The clutch. clutchASpeed = engineRPM; clutchBSpeed = gearboxInputShaftSpeed; // Now, when the clutch is engaged, it wants its two speeds to be equal. // So it should apply reaction torques to try to achieve this. // A naive approach might look something like: clutchTorque = frictionConstant * clutchFactor; // clutchFactor = 0.0f -> 1.0f if(clutchASpeed > clutchBSpeed) reactionTorqueA = -clutchTorque; reactionTorqueB = clutchTorque; else reactionTorqueA = clutchTorque; reactionTorqueB = -clutchTorque; // This may have problems where is oscillates around equal speeds. // Depends on your integrator timestep, masses, etc. // You could experiment with making the reaction torque linear to slip speed, // putting limits as the speeds get close to equal, etc. So, what should happen, is when the engine is faster than the input shaft of the gearbox, the clutch generates a torque that tries to slow the engine and tries to speed up the gearbox. Vice-versa when the engine is slower than the gearbox input. The gearbox multiplies this torque and sends it to the wheels. (Divide it up by the number of drive wheels). As I said, it's been a long time since I've done this. So I could have missed something somewhere, but a similar approach has worked for me in the past.
  14. I don't know if you're still having problems, but what you are describing sounds like a Trapezoidal Motion Profile. Maybe that search term will help you.    
  15. I have made an input system based kind of on this: http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/   I have my raw input -> context map -> actions.   I have a dispatcher / subject / observerable (whatever) that will do the notifying when actions are triggered. Implemented very roughly as: vector<*listeners> I have a listener which registers to the dispatcher to handle certain actions. It is implemented roughly as vector<*dispatchers> /// to automatically unregister on destruction map<actions, std::functions> /// function to call given an action, bound to *this with std::bind I would like to place this listener as a member of any game object which should do something with input. class Camera { Camera(); InputListener m_listener; } Camera::Camera() { dispatcher.register(m_listener, event::CAM_MOVE_LEFT); /// probably occurs someplace else, really. m_listener.addCallback(event::CAM_MOVE_LEFT, std::function<void()>(std::bind(Camera::moveLeft, this))); } Problem #1 I had to use std::bind to bring along the *this so that the callback can call the member function.  This isn't a problem unto itself until... ...The parent object is copied. The callbacks which are stored in the listener are now pointing to the pre-copied-object.  This means that any object which decides to have an inputListener as a member must implement a non-trivial copy constructor to rebind all the callbacks with the proper *this.  Kinda stinks of poor design.   I could make the member static, but then wouldn't *all* cameras move left when this callback occurs?   I'm overcomplicating this somehow.        
  16. CombatWombat

    Discombobulated input callbacks

    I don't know.  What happens when the camera dies?  How does the dispatcher know to unregister that dangly pointer?  Seems like this just moves that responsibility to the camera object, which then needs to be reimplemented for every game object that registers functions to the dispatcher.  Unless I am misunderstanding.     How do you handle storing the objects (like the camera) in a container (std::vector or similar).  Doesn't that require a copy?   What is the alternative?  Are you saying that the entire Input->MapToActionsWithAContext->ActOnThoseActions model doesn't work well? Or are you saying that the final step of resolving the action via callback does not work well? How else does the game object act upon the action event?   Thanks to both of you.    
  17. I've read everything I could find on these things, and I'm starting to implement this and questions are arising.  Sometimes I find typing all this out helps get my head in order...A lot of this might be duplicates of prior threads asked in a different way and much of it will be just plain hypotheticals...  Without further ado...   I am using SFML and want to sort by texture, and then by depth (really layer, since this is a 2d game).    So.  I can store all the sf::Drawables in a vector (that gets filled by the scenegraph/culling/whatever system). std::vector<sf::Drawable> allOpaqueDrawables; std::vector<sf::Drawable> allAlphaDrawables; Should these be pointers to the drawable which is instead stored in the game objects themselves?  Should there be a master list of all drawables in the game that "owns" them, letting both the game object and these "sub-drawables-within-the-scene" use pointers to this master list? Some other third option?     Now, I need to sort this.  So I can make a render queue which is just indicies into the vector of all drawables. I'm not positive how to implement this... a first try might be something like: std::map<sortKey, int16_t> renderQOpaque; std::map<sortKey, int16_t> renderQAlpha; // with sortkey being a POD integer type built from the texureID and layer value of the drawable I guess the idea is that the small int16 keys are the only thing that needs to be copied around to sort the map?   1) Is this a sane way of doing this part? 2) Is std::map a reasonable choice for the implementation?   Then the map can be iterated through taking the int16_t as indicies into the vector allDrawables to call draw() on each one.   A few problems: 1) Where to store and generate the sortKey, if it needs to be stored at all?        a) I need an integer representation of a texture.        b) (At least part of) the sortKey needs to be updated if the objects layer (depth) changes.   My texture storage assigns a unique integer ID number and prevents duplicates from loading.  Does it make sense to actually store this value in the texture?  Right now it is only kept in the texture storage (as a std::map<texID, sf::Texture>). I could inheret from sf::Texture and create a version that contains the texID.  Unnecessary?   SFML uses an sf::Drawable which contains the geometry to be drawn as well as the "rules" to draw it (actual draw() call). It also uses an sf::RenderStates which holds... 1) *Texture 2) *Shader (if used) 3) *Transform 4) BlendType   Since this RenderState holds damn near everything I need to generate the sortKey, it almost sounds reasonable to create my own RenderStates which derives from sf::RenderStates so that I can contain the sortKey in it and regenerate the sortKey anytime one of those three items are changed.  Yea/Nay?   I realize most of this is just my thinking out-loud/rambling.  Any feedback is appreciated.      
  18. CombatWombat

    Yet Another Rendering Queue Thread

      Going to try this.  Might do an index instead of the pointer for round one.   Apparently I'm kinda stuck with something like this.  I tried creating my own texture inheriting from the sf::Texture to add the texID integer in there. Then I started inheriting a new RenderStates type from sf::RenderStates.  But then painted myself into a corner because it's implementation uses an sf::Texture and there isn't really a way I can see to override that to use my type without reimplementing the entire thing.  Kinda hokey.     Yeah, I've seen that one.  Also there's a few good ones on LSpiro's page.  Good explanation of the concept, but not enough ideas for implementation for my programming inept skill level.    
  19. CombatWombat

    Drag equation

    I would be inclined to treat the wing and tail as two lifting surfaces and then apply some NACA Lift & Drag curves. You could do a similar thing for the fusalage (treat it as a long-chord wing section). 
  20. CombatWombat

    Calculating pressure transfer between pipes

    If it's for a game, it's got to be a pretty strange game where the incompressible assumption causes problems.   If it's for an engineering problem, there are off the shelf products both paid and open to solve fluid problems.  Computational Fluid Dynamics code.   If it's purely to learn and play: When you lose the incompressible assumption it becomes simultaneously a fluid dynamics and thermodynamics problem.  You will need to learn about: Bernoulli / Energy equation Thermodynamic Properties The basic laws of thermodynamics   It's a big subject and it's hard to advise you more specifically without knowing where you are starting from.
  21. CombatWombat

    Modeling some flight physics.

    I think you're having a hard time because you may not be clear what your end goal should look like.  A well described question is halfway answered.   You say it's on rails.  But then you want to account for angle of attack and wingspan while having a constant force driving you forwards.  You seem to be creating a hodgepodge of rails and physics based behavior.  I caution that such a hybrid may create strange edge-case behaviors and may tend to be unintuitive.   Let's break this down to the simplest forces you need to fly.  Airplane, dragon, whatever. Lift, thrust, drag, gravity.   You can use simple lift coefficient for lift force. Its sounds like you want thrust to be constant forward.  You can use simple drag coefficients to get a drag force. Gravity is gravity.   For your rotional control you have 3 axis. Pitch, roll, yaw.   Here is where you need to better define your control scheme.  Should the triggers roll you directly?  Should they be mapped to angle of attack of left and right wings?  Should they be mapped to give an aileron effect (left wing down, right wing up)?  How do you pitch?  You need a tail.  Ditto for yaw. 
  22. CombatWombat

    Whats a good mathematical model for heat transfer?

    Start by thinking about it as heat energy, not as temperature. You can get temperature from the internal energy by having the mass and thermal heat capacity of the objects. The difference in temperature drives a flow of heat energy between the objects. A thermal resistance slows this flow.   It works like Ohms law.  (E=IR) But with thermal-ness it would be (T = QR) where T is temperature delta, Q is heat flow, R is thermal resistance.   How you calculate R is the crux of how complicated your system is!  For a simple "looks good enough" you can just base it on surface area of the objects in contact with a scaling factor.  For a more accurate effect, you'd have to deal with things like arriving at a convection coefficient which is brilliantly convoluted to calculate.  For round objects there are some natural logs that show up in the calculation of R.  There are Nussault numbers and Prandl numbers.  You can go nuts here.   Your specific example of heat transfer from oil->water is an example of a heat exchanger.   If you can be more specific about what you need to accomplish, we can advise you better.
  23. CombatWombat

    A Rose by Any Other Name...

      Hey, it's not entirely useless if you want to play with microcontrollers.     (Ok, most of them have C compilers these days...ahem...)
  24. CombatWombat

    Cars differentials, open, locked and preload

    First you need a more general description for the velocities.   A differential is a bevel gear implementation of a planetary gear train.  For an automotive type differential where the bevel gear ratio is 1:1, the velocities must satisfy: (VL - VH)/(VR - VH) = -1 where VL = left drive shaft velocity VR = right drive shaft velocity VH = housing & ring gear velocity   You can see the derivation of this here: http://books.google.com/books?id=QNj87rJZIpUC&pg=PA373&lpg=PA373&dq=KINEMATIC+EPICYCLIC+GEARING+DIAGRAMS&source=bl&ots=w9OLebHeMw&sig=1Ut2U15xCnXa53MPhdU8bEHbI_A&hl=en&sa=X&ei=RYZzU7HyHc6zsAT9-4H4DA&ved=0CDsQ6AEwAzgK#v=onepage&q=KINEMATIC%20EPICYCLIC%20GEARING%20DIAGRAMS&f=false (Or refer to any kinematics of machinery text)   Add up net moments on the components: The ringgear/housing has a moment on it from the pinion gear.  (This comes from your engine/transmission model). A reaction moment comes from the pin which mounts the center bevel gear. The center bevel gear in turn applies moments to each output shaft. The output shafts have reaction moments from the tire & brake models. The output shafts have reaction moments between them to enforce the velocity rule from earlier.   The various locking & lsd differentials add more forces/moments to these components.  Exactly which components are effected depends on the specific type. Simple example would be viscous style which has a locking effect as a function of velocity difference between the shafts. Add another moment to each axle.  Essentially (leftAxle Velocity - rightAxleVelocity) * someConstant.   To directly answer your question on "preload". Certain types of lsd utilize friction clutches to couple between the two output shafts.  Usually these are angled to be sensitive to the torque input to the differential.  "Preload" means that even with zero torque transmitted, there is still some coupling torque between the output shafts.    A good search term would be "torque in epicyclic gear trains".          
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net 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!