To simplify this a bit (longer explanation’s below - if that helps), I was just wondering if there was some way to get rid of the shakiness in the unity joints, or even just where that comes from. If not, is there some other less shaky alternative to the Unity Joints? (All I need is a hinge joint of sorts that attaches an axel (that’s attached to an entire car) to a wheel - and that wheel rotates and propels the car with friction - Is this possible? It was just jumping around so much it became impractical to use the built in joints as they were)
Maybe this is unnecessary, but I was just wondering if there was some sort of simple/not simple (that’s fine – as long as it works) scripting/other alternative to the default joints in unity.
The reason I ask is because it seems like whatever you do (increase the solver iteration count, switch to a configurable joint and fiddle with all the settings, etc.) the joints always seem to either jump bizarrely around (this isn’t usually to much of a problem though), or (more significantly), if they’re constrained well enough, they just seem to wiggle a bit every once and a while – but that makes any project seem terribly unprofessional – as object will be randomly bouncing over seemingly invisible object every once and a while – or just twitching slightly but annoyingly uncontrollably.
So, to go back to where I’m having this problem, I’m trying to make some sort of project where a user can make their own robots by making plates (flat textured stretched cubes), then attach axels on these cubes, than attach wheels on these axels. All that part’s working fine and basically done, but when I try to apply the physics to these wheel axel systems, everything seems goes downhill. To clarify, the system I have right now takes all the objects (it splits them into separate robots too – but that’s not important – just assume there’s only one robot) that are part of 1 robot (plates (flat boxes), axels, and wheels), sets all their parents as one object named robot 1, then gives this parent object (robot 1) a Rigidbody. This allows all of these objects to be stuck together in one solid blob, which works great for all intensive purposes – except where the wheels come in. You see, I needed some way to have wheels that, as they spin, the friction between them and the floor creates a forward motion. I can’t just use a forward force from where the wheels might be hitting the ground because the users are going to be driving over more complex obstacles than a simple flat floor, so, instead, I need a more generic solution that works in any situation – which would just be movement from the friction of the wheels trying to rotate against the floor. These wheels have a sphere collider around them but look like wheels, and are ignoring collisions between them and the axel they are attached to, just to make sure that that isn’t causing any problems. (don’t worry, I tested this and they are really ignoring collisions - this is not the problem).
So, first I tried just rotating the wheels themselves – when they were just objects parented to the main robot 1 with a Rigidbody (with transform.Rotate()). The wheels rotated as needed, but I guess this rotation doesn’t actually create a frictional force between the surface and the object (since I assume the engine uses angular velocities instead to calculate this). If there is a way to get forward force from contact points here – that’d probably be preferable (just let me know if you have any (maybe like finding all the contact points and calculating the normal and applying a force or something…?)) – but if there isn’t I’m happy to go some other way – because I figured a simple joint shouldn’t be too difficult.
So, I separated all the wheels under a separate parent, and gave each wheel individually a Rigidbody and a Hinge Joint and connected them each to the main Robot 1 Rigidbody parent holding all the other objects. Then, I made sure their axis were aligned right, and tried rotating them – and that worked ok – and even provided forward force from the friction against any surface, which was what I needed. But the wheels kept sort of bumping up and down (as I explained before) – which made them look worse than before. So online, lot’s of people had been complaining about this and praising the configurable joints as the solution, so I used these, and they seemed to be working much better - much more stable and controllable and such – and so I fine tuned them for a bit and they seemed not too bad, but the wheels would still occasionally just bop up a little bit – offsetting the robot and the whole driving robot experience – and ruining all professionality that this program might have – which is what I’m hoping to go for. If it helps, here’s the part of the script that adds a configurable joint and Rigidbody to the wheel (and still parent’s it to the same robot 1 rigidbody object – this didn’t seem to make a difference). I tried fine tuning tons of stuff (that’s what most of this is) – but it still didn’t seem to make a difference. (it’s in c# if that helps - and wheels is the current wheel we’re working with, wheelDensity is the mass of the wheels (sorry for the terminology confusion), and temp rigibody Robot is that bit robot 1 object that I was talking about earlier - just feel free to ask for any further explanations if there’s anything I missed)
** **wheels[b].robot = a; wheels[b].transform.parent = tempRobot.transform; wheels[b].gameObject.AddComponent(typeof(Rigidbody)); wheels[b].gameObject.rigidbody.mass = wheelDensity; wheels[b].gameObject.AddComponent(typeof(ConfigurableJoint)); ConfigurableJoint tempJoint; tempJoint = wheels[b].transform.GetComponent<ConfigurableJoint>() as ConfigurableJoint; tempJoint.connectedBody = tempRobot.rigidbody; tempJoint.axis = new Vector3(0,0,1f); tempJoint.anchor = new Vector3(0,0,0); tempJoint.xMotion = ConfigurableJointMotion.Locked; tempJoint.yMotion = ConfigurableJointMotion.Locked; tempJoint.zMotion = ConfigurableJointMotion.Locked; tempJoint.angularXMotion = ConfigurableJointMotion.Free; tempJoint.angularYMotion = ConfigurableJointMotion.Locked; tempJoint.angularZMotion = ConfigurableJointMotion.Locked; tempJoint.projectionMode = JointProjectionMode.None; tempJoint.projectionDistance = 0.001f; tempJoint.rotationDriveMode = RotationDriveMode.XYAndZ; JointDrive drive = new JointDrive(); drive.mode = JointDriveMode.PositionAndVelocity; drive.positionSpring = Mathf.Infinity; drive.positionDamper = Mathf.Infinity; drive.maximumForce = Mathf.Infinity; tempJoint.xDrive = drive; tempJoint.yDrive = drive; tempJoint.zDrive = drive; tempJoint.angularYZDrive = drive; drive = new JointDrive(); drive.mode = JointDriveMode.Position; drive.positionSpring = 0; drive.positionDamper = 0; tempJoint.angularXDrive = drive; //the x free’d motion (here and up above with tempJoint.xMotion) seemed to line up with the z rotations later on - I’m not sure why – if you know that’d be great too, but it’s not as important** **
And the wheels can rotate around their axis with this script (wheel is a gameObject for the wheel, and wheelJoint is it’s configurableJoint component assigned earlier - and wheelSpeed is the desired wheel speed and torque power is the acceleration speed of the wheel used to get to that desired speed)
** **Rigidbody tempWheelRigidbody = wheel.rigidbody; wheelJoint.targetAngularVelocity = new Vector3(0,0,wheelSpeed);//set the target angular velocity of the joints to the angular velocity we want to reach so they will help us with this - not hinder us if(wheelSpeed > 0){//if we aren't at the set speed yet - speed up angular velocity until we get there - then limit the speed at the desired speed if(tempWheelRigidbody.angularVelocity.x < wheelSpeed - torquePower * Time.deltaTime){ tempWheelRigidbody.angularVelocity += new Vector3(0,0,torquePower * Time.deltaTime); } else{ tempWheelRigidbody.angularVelocity = new Vector3(0,0,wheelSpeed); } } else{ if(tempWheelRigidbody.angularVelocity.x > wheelSpeed + torquePower * Time.deltaTime){ tempWheelRigidbody.angularVelocity -= new Vector3(0,0,torquePower * Time.deltaTime); } else{ tempWheelRigidbody.angularVelocity = new Vector3(0,0,wheelSpeed); } }** **
Both of these scripts are applied to every wheel at the start when all the objects are done being made and ready to have physics applied – and then the second script is applied to every wheel every frame (in the Update) after the first script is done.
My biggest question is this then: Is there some way to consistently get rid of that twitchiness that inherently seems to be in every joint, and, if not, is there some other way to do this I missed altogether? I’m just at a loss now as for what to do - because knowing Unity and everything amazing they’ve done, I’m sure there’s is some better way that I’m missing - or something simple that I need to do to fix this - I just have no idea what to do now. Thanks to anyone that’s willing to help for a bit – and sorry this is a bit long, but if you have any suggestions or ideas - could you post below?
Well, if anyone is having a similar issue, we did somewhat find a solution to this problem. It’s not necessarily a “solution”, but it seems that joints act in a rather buggy way on the mac (as described above), but, once they’re moved to the windows, they act perfectly fine. Why - well, we’re not sure (possibly to the outdated DirectX Support or something?), but, as long as our project is ran on a windows, it works fine, which works for us. If you have any other suggestions for getting joints to work this way on a mac, we’d be happy to hear them though =)
Thanks,
Xilo27
I think this is the same problem I’m describing here, and I can’t understand why nobody answers anything…
Joints are “loose”, they only stay in place if the forces applied are very very small.
Just let some connected bodies fall down and hit something and the joints will be distorted, hinges out of place, etc.
I would only know if it’s correct like that, and if there’s some way to turn around this problem or if I have to code myself a working physic model with hard joints working.