Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Bug Wheel colliders behave very strangely

Discussion in 'Scripting' started by fheronax, Mar 18, 2023.

  1. fheronax

    fheronax

    Joined:
    May 2, 2020
    Posts:
    13
    I decided to write the control of the machine on the wheel colliders system, everything would be fine, only this system in the unit is implemented, as for me, very crookedly. But not the point.

    Faced the problem that the wheels just fall under the terrain when driving (in my case, one of the wheels, and always the same (I tried a bunch of options with this wheel, copied it, recreated it, changed the values, but everything is even)). In addition, it really pissed me off that you don’t even understand what the problem is, because there are no errors, the wheels are exactly copied from other wheels, and one of them behaves very strangely. In this case,

    I don’t understand if it’s a bug or it’s my mistake, which I don’t see, but I’m already on the verge of writing my own logic for the operation of the wheels, but the only reason is that I will have to tie up the work of other scripts under my new logic, which I don't want to do.


     
  2. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    39,013
    Wheel colliders are a tricky beast. I implemented this approach and it worked pretty well:



    If you insist on wheel colliders, check out this multi-part presentation:

     
    fheronax likes this.
  3. fheronax

    fheronax

    Joined:
    May 2, 2020
    Posts:
    13
    Yes) I just started to study this video. I just didn't have the nerve to set up the wheel collider, so now I'm watching this video. I think I will stop there. Since the wheel collider is certainly a good thing, but quite difficult to set up, where, well, there is no way to choose the values for the wheel so that it behaves at least close to what I want.
     
  4. fheronax

    fheronax

    Joined:
    May 2, 2020
    Posts:
    13
    Hi again! I was able to create wheel physics based on the video above, however there are a few questions about the physics. Since I'm giving force to the object based on incoming inputs vertically, it's pushing based on where I've pressed, however after fully decelerating, I see that the rigidbody velocity values are constantly increasing even if I don't press any buttons.

    Z axis keeps moving
    upload_2023-3-19_16-13-23.png

    Current Behavior: When I press the brake button, I will invent a force in the negative direction and the object stops, but after stopping it again starts to pick up speed exponentially.

    Expected Behavior: When the brake button is pressed, the car should stop and be unaffected (freezing along the axes is not suitable, neither is rigidbody drag)

    I don't quite understand what needs to be done, but I think there must be some resistance for the z-axis
     
  5. fheronax

    fheronax

    Joined:
    May 2, 2020
    Posts:
    13
    Now I'm trying to play around with rigidbody drag, but I'm not entirely sure if this is the right solution, since it creates friction in all directions, not just forward, it helps me a little, however, the velocity is still not equal to 0, it is close to this value (0.013...). Any ideas how this can be worked out?
     
  6. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    39,013
    Assuming you don't have a bug, perhaps you just need some of your own damping on the velocity?

    Code (csharp):
    1. rigidbody.velocity -= rigidbody.velocity * DampingAmount * Time.deltaTime;
    Otherwise, time to start debugging! Here is how you can begin your exciting new debugging adventures:

    You must find a way to get the information you need in order to reason about what the problem is.

    Once you understand what the problem is, you may begin to reason about a solution to the problem.

    What is often happening in these cases is one of the following:

    - the code you think is executing is not actually executing at all
    - the code is executing far EARLIER or LATER than you think
    - the code is executing far LESS OFTEN than you think
    - the code is executing far MORE OFTEN than you think
    - the code is executing on another GameObject than you think it is
    - you're getting an error or warning and you haven't noticed it in the console window

    To help gain more insight into your problem, I recommend liberally sprinkling
    Debug.Log()
    statements through your code to display information in realtime.

    Doing this should help you answer these types of questions:

    - is this code even running? which parts are running? how often does it run? what order does it run in?
    - what are the values of the variables involved? Are they initialized? Are the values reasonable?
    - are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)

    Knowing this information will help you reason about the behavior you are seeing.

    You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as
    Debug.Log("Problem!",this);


    If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.

    You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.

    You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.

    You could also just display various important quantities in UI Text elements to watch them change as you play the game.

    If you are running a mobile device you can also view the console output. Google for how on your particular mobile target, such as this answer or iOS: https://forum.unity.com/threads/how-to-capturing-device-logs-on-ios.529920/ or this answer for Android: https://forum.unity.com/threads/how-to-capturing-device-logs-on-android.528680/

    If you are working in VR, it might be useful to make your on onscreen log output, or integrate one from the asset store, so you can see what is happening as you operate your software.

    Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.

    Here's an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:

    https://forum.unity.com/threads/coroutine-missing-hint-and-error.1103197/#post-7100494

    When in doubt, print it out!(tm)

    Note: the
    print()
    function is an alias for Debug.Log() provided by the MonoBehaviour class.
     
  7. fheronax

    fheronax

    Joined:
    May 2, 2020
    Posts:
    13

    Yes, I try to debug the code all the time, but there is a problem with what I'm trying to look at, for example, there is an object and I need to look at all its values and methods. Here if I want to output an array of

    Code (CSharp):
    1. float[,] values a = new float[width, height];
    2. Debug Log(a);

    This will output as Double. However, it would be very helpful if the unit had an advanced lookup tool, like the browser console, where I can see each array value without having to access them by index. I tried to google it, but it's too time consuming and looks like duct tape.
     
  8. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    39,013
    Unity's serialization and inspector window can only handle scalars and certain 1-dimensional arrays.

    It does not handle 2D arrays.

    It's fairly common to write either CustomPropertyDrawers or else just some ad-hoc code to dump out your data during the debugging process.

    Remember, code is irrelevant: data is what matters, so the sooner and more rapidly you write this code in order to get a useful view into your data, the faster you will be moving to your solution.