Unity Car Physics
Charolette Antosh
Unity helps you simulate physics in your Project to ensure that the objects correctly accelerate and respond to collisionsA collision occurs when the physics engine detects that the colliders of two GameObjects make contact or overlap, when at least one has a Rigidbody component and is in motion. More info
See in Glossary, gravity, and various other forces. Unity provides different physics engine implementations which you can use according to your Project needs: 3D, 2D, object-oriented, or data-oriented. This page provides the links to their documentation.
You can achieve some basic physics goals with the user interface, but for more control over the simulation, you need some familiarity with C#. To develop your C# skills, see the Unity Learn Junior Programmer course.
But I could have used tags, right? Not really as they were already being used for gameplay purposes.These days I think I could achieve similar results with command buffers but they significantly more time to setup due to lack of proper examples and something you just need that simplicity which layers offer.
Can we get an official Unity clarification on on that? Normally I would not push so hard for an official response but Unity staff always suggests putting a feedback ticket. One was created in 2011 and has 278 votes so far so what else there is for me to do?
Physics and graphics are coupled simply because you use the same layer system for both camera culling and physics channels. If you need a gameobject to be placed in Layer A which would be used for camera culling but you need it to be using Layer B for physics, both at the same time, you need to clone this gameobject, place one copy into Layer A, and another one to Layer B. This way one can be culled by the camera and the other can be used for physics. Like I said - not a problem for a small game but for something larger with complex physics and culling setup aaaand large amount of gameobjects, this spins out of control quite fast. Have I mentioned that maximum amount of layers allowed is 32?
Yes, sure. I guess two objects could be passed to the broadphase for the collision computation once their masks being &-ed give a non-zero value (i.e. if they belong to at least one common layer). The old pair-wise collision ignorance should be remained as is I think. That would give the full scripting coverage as well as full editor coverage. Makes sense?
I found this to be happening on 2021.2.12f1 on intel builds as well as apple silicon builds. It appears to be more severe if you call Physics.RebuildBroadphaseRegion. Submitted a bug report case #1406765.
Ah my apologies, I thought you were talking about the physics debugger. I see what you mean now. I checked the physics section of the profiler in my build and found no appreciable difference between a Physics.Processing 10ms spike and a regular frame:
In my bug report I found the easiest way to make this happen was to stick a camera in an empty scene, call Physics.RebuildBroadphaseRegion, then move the camera around and observe the Physics.Processing spikes.
The repro project was just sent as an example of what I was seeing in my larger 80gb+ project. Right now these spikes are preventing me from updating from 2019 on macOS. These spikes are not present in my 2019 builds which use the same code, the same settings, the same everything other than the engine upgrade.
On the other hand, if you could save a profiler capture and send it to us, we may be able to at least examine this spike and either confirm our first suggestion or maybe find something else. To save a capture, record some frames in the Unity profiler and save those into a file, by clicking the appropriate button. Then just send us that file and we will be able to open it in the Editor on our side.
This is a full scene, but the same thing also happens adding a box to an empty scene. The following two screenshots show an empty HDRP scene with a box. The one with the physics spikes is with the box collider on the box enabled, that other one is disabled. As you can see, there is in fact a drastic difference in performance. (And the only thing that is changed is enabling a box collider.) By the way, this is the apple silicon editor on an M1 Max if that helps.
Havok Physics for Unity raises the bar of your physics implementation with seamless integration for ECS-based projects. While Unity Physics is optimized for most real-time 3D use cases, Havok Physics for Unity can elevate the stability and performance of physics in spacious open worlds or in scenes with a massive number of rigid bodies. The Havok Physics for Unity simulation backend can be swapped with the Unity Physics backend easily at any time without needing to change existing physics assets or code.
NVIDIA PhysX SDK is an open source, scalable real-time physics engine that enables advanced simulations for more immersive game play with true-to-life simulations and real-time dynamic effects. PhysX is a library for representing 3D worlds that lets you create and destroy actors and tracks their explicit or proximity-based interactions.
Objects anchored to another object also can benefit from physics with 2D Joints, adding realism to a sliding platform, chain, spring, or car. To simulate buoyancy or magnets, 2D Effectors can add non-contact physics effects.
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
I'm working on a 2D top-down open-world game in which there is a character who can be moved by keyboard functions. The movement is caused by Rigidbody.AddForce().
The problem is that the moving speed is not the same in different screen sizes.
The character's mass is the same, the float speed is the same but yet, after I switch the game view to full screen, obviously the character moves faster. (Which is odd, and shows that it's not a performance problem.)
I've tried to test the standalone build, everything's fine there (however it seems a bit slower in android build.) but I need to have a common speed in the editor because I have to design levels that depend on the timing and the timing depends on the speed.
Physics works in WorldSpace and has nothing to do with ScreenSpace, so your problem is beyond what it seems to be. The performance drop on android is expected, but in standalone, make sure you use FixedUpdate for physics operations (which you do here) and make sure nothing is causing FixedTimeStep to change during the game by any chance.
What I'm not sure is, are physics steps commonly behind current time, or ahead of current time? In other words, how is Unity's decision made for doing physics or not, like while (currentTime - previousPhysicsUpdateTime >= fixedDeltaTime) or like while (currentTime > previousPhysicsUpdateTime)?
It is a bit like to opposite. Physics is done regularly on a fixed time basis. That means that FixedUpdate is called on a fixed time basis. It is the Update, that can vary depending on the fps of the game (60 fps, Update was called 60 times per second).
Now, we usually thing from the Update point of view. Meaning that if you have a high fps, maybe you can have two Update calls before a FixedUpdate happens. In the same way, if you fps drops you have less Updates, but still the same amount of FixedUpdate, so you will have several FixedUpdated between two Updates.
So for example, let's say FixedUpdate happens 50 times per seconds (that's the default in unity). It you game runs at 60 fps, It means most of the time you will have one FixedUpdate and one Update call. Occasionnaly two Updates will follow (because Update is a bit more frequent). If you reach 100 fps, it is sure that you will always have at least two Update calls before a FixedUpdate.
There are many different ways to manage physics simulation in multiplayer games. Netcode for GameObjects (Netcode) has a built in approach which allows for server-authoritative physics where the physics simulation only runs on the server. To enable network physics, add a NetworkRigidbody component to your object.
c80f0f1006