[Official] Physics Improvements

Who are you?

Angel García "Edy", developer of Edy's Vehicle Physics and Vehicle Physics Pro.

What kind of game are you trying to build or would like to build?

I develop vehicle physics and dynamics kits for Unity as Editor Extensions.

How does Physics fit into that? What use-cases do you have?

Physics drive the rigidbody, collisions, and the suspension via WheelCollider. In summary, my use-case is:

1. Vehicle is a standard Rigidbody subject to regular Physics.
2. WheelColliders are used in friction-less mode (all values of the friction curves are set to zero). Physics then handles the suspension part only.
3. I gather information on the wheel contacts from the WheelColliders via WheelHit. The most important value is WheelHit.force, as currently there's no other way of getting a precise force value in such type of interaction (spring / damper).
4. I then calculate the tire force values and apply them at WheelHit.point via Rigidbody.AddForceAtPosition.

What are the GOOD things about Physics that you like?

• Rigidbody dynamics, collisions and joints work fine.
• Spring / damper values at WheelCollider use real-world SI units, and work mostly fine (except for some weird bugs - see below)

What are the BAD things about Physics that you dislike?

• WheelColliders are badly implemented, even the suspension. One major faulty effect is described at this video. Other bad effects are exposed here and here (case #698973).
• WheelCollider suspension can apply negative forces (like if the wheels were magnets over a metal surface) if damper is too high, which is completely unrealistic (Case #725365).
• There's no way of getting the force being applied by joints when enforcing the joint's constraints (joints might be a possible alternative to the WheelCollider only if that force is exposed).
• Standard friction among bodies. Most essential friction laws are arbitrarily violated. I couldn't believe my eyes when I first read this paragraph from the PhysicMaterial help:

So if I've understood this correctly, what you recommend for realistic friction is:​

• • Examine each collision via OnCollisionEnter / OnCollisionStay
  • Get the number of contact points.
  • Dynamically clone the PhysicMaterials from the colliding objects (as using the actual PhysicMaterial references would affect other collisions using the same materials).
  • Divide the friction values of the PhysicMaterials by the number of contact points of the collision.
  • Assign the cloned physic materials to the colliding objects.

All of the above in runtime, per frame, if we want to achieve physically realistic friction effects. Is that correct? Is there another way of having realistic friction?​

How can we make it BETTER?

Fix the mentioned WheelCollider suspension bugs. All of them are easily reproducible, and I had submitted repro cases:

• Colliders in contact with WheelColliders have incorrect collision behaviors (#698973)
• WheelCollider suspension generates negative forces on high damper values (#725365)
• PhysX 3 Vehicle suspension fails on two wheels (video, I can submit a repro case if this issue is going to be looked at).
• EDIT: Allow to specify WheelCollider.sprungMass from scripting (currently is read-only). I've encountered situations where the calculation is arbitrary, causing further suspension issues (i.e. CoM located outside the boundaries of the wheels).

Expose the forces and torques applied by joints when enforcing their constraints. This should be straightforward, as PhysX already provides a method getForce for retrieving this.

Provide some method for having physically correct friction. Maybe internally divide the friction coefficients by the number of contacts? I'd ask nVidia about this. It might be a global setting at the Physics settings, or a script-only property at the Physics class. EDIT: PhysX provides three different friction modes. Maybe could the friction model be exposed as Physics setting?

Also, a non-alloc version of OnCollisionStay would be great.

 

Who Are You?

I'm Iron-Warrior. I wrote a custom character controller for Unity, and have been using the engine since 2.6!

What kind of game are you trying to build or would like to build?

I'm making a first-person multiplayer combat game.

How does Physics fit into that? What use-cases do you have?

Almost all competitive multiplayer games that require players to execute precise movements use client-side prediction and server verification. For client-side prediction, once the server has received the inputs it will respond with the authoritative position, at which time the client will re-simulate all of it's movements up until that point to keep in sync.

Movements that require precision, like shooting an enemy are calculated against the interpolated position of targets on the client side, while the server "rewinds" it's world state to that point and then verifies the client actually did hit a target (to prevent cheating).

What are the GOOD things about Physics that you like?

I've never had any real issues with rigidbodies and forces.

What are the BAD things about Physics that you dislike?

The built-in character controller offers very little control or fine tuning. It is always fixed on the world Y axis. It cannot be used in any shape other than a capsule.

The larger issue is that very little of the Physics engine is exposed to the developer. Here is a list of things you cannot do, but would be really useful to lots of situations:

• You cannot run a broad phase check against two colliders
• You cannot run a narrow phase check against two colliders
• Physics.OverlapX done not return a whole lot of useful data
• You don't have access to any of the Physics functions (I assume Nvidia has an implementation of GJK and EPA sitting around, as well as basic box-box, sphere-box and so on intersection methods)
• There's no triangle tree component, while I'm assuming internally there's an octree or BSP tree built for each mesh collider
• You cannot run the entire physics step at will.

So what I want overall is just more access to the behind-the-scenes stuff. I think that having the ability to do the above would greatly increase Unity's physics flexibility, while still not interfering with it's philosophy of being easy to use and accessible.

Thanks,
Erik

 

Mark Schultz, tutorials about 3D Unity in Portuguese (https://www.youtube.com/channel/UCsXIdvfp138xs1K1eTsaezQ/videos)

What kind of game you're trying to build or want to build?
-I'm developing several systems for Unity, in order to distribute them free of charge in the form of tutorial. One such system I'm developing is on vehicle simulation.

As physics fit it?
-WheelCollider use to manage the entire vehicle system I am creating a simple and rigid body physics to simulate them.

What are the good things about physics that you like?
-The Simulation is very realistic and works very close to reality

What are the bad things about physics that you do not like?

-The Collision WheelCollider in Unit 5 is horrible, causing errors such as those represented in the image and video, where the vehicle ends up flying when it encounters an obstacle with the wheel.

In my opinion, it would be interesting to improve the way the WheelCollider collision is detected, so that all wheel detect impacts, not just the background.

I apologize for my bad English, I am Brazilian and the only way to communicate is by using the google translator, so I write and just getting a little strange to you.

 

Hi Eric,
long time no see. Hope things have treated you well after Turbine.

What kind of game:
VR Airship, others I can't talk about at my day job.

Use Cases
Rigidbody collisions in VR that don't make people sick.
Lots of guns shooting from the side of the ship (avoiding the ships collision and its shields)

Things I like.
Physics is intuitive, lots of features.

Things I don't like:

1)Make Physics.IgnoreCollision not reset trigger states.
Right now if a character shoots a gun parented to their hand, and the bullet ignores the guns collision, the gun and its entire parent hierarchy leaves and then reenters all triggers. So if the character holding the gun is standing on a pressure plate that opened a door, as an example, the door would close and open as they stopped existing then existed again.

I've had to rewrite entire systems to use triggers and impulses so I could early out in script as there are simply not enough physics layers to support some game types. Imagine a 64 player game, each player wanting to ignore their own rigidbody bullets. That game is currently impossible in Unity unless the game avoids all use of triggers or does some other really hacky workarounds.

2) Make OnTriggerExit or an alternative get called when a Gameobject is destroyed. Its a real pain point to have to track all objects that enter a trigger and then remove them with a event/listener when they are destroyed.

3)Triggers can pass through objects without triggering, even when set to continuous dynamic. (not as big of an issue if Physics.IgnoreCollision works. But would still be nice. Right now I just scale triggers to the number of units they move per frame. E.g. a bullet that moves 90 meters per second would have a trigger "tail" of 90 meters. Obviously not the best for performance. Also currently have to use raycasts for really fast moving objects)

 

Hi Erik,
Thanks for posting this thread.
Just chiming to say that everything Iron Warrior noted applies to us as well. Couldn't have said it better.
So to stress, unlocking the character controller in the Global Y axis would be huge for us, as well as manual stepping would be highest on the list of requested improvements.

Thanks again!

 

Thanks Erik, good summary. I would add:

What could be Better:
Non-alloc versions for OnCollisionEnter / OnCollisionStay.

Memory allocated by Unity invoking these methods can be rather big. Here is an example with profiler pic
It had been discussed briefly in the alpha board as well.

 

Hello!

Who are you?
Simian Squared, we make games for everything (Just PS4 for this current title).

What kind of game are you trying to build or would like to build?
Medium sized open world Action Adventure with lots of stuff that doesn't fit categories.

How does Physics fit into that? What use-cases do you have?
It's our main USP. We have intensive ragolls, custom physics, stacking, destruction, heavy use of vehicles, and perform physics based combat with traversal with hundreds of enemies. We stress joints and ragdoll hierarchies a LOT.

What are the GOOD things about Physics that you like?
Super easy to use, lovely API.

What are the BAD things about Physics that you dislike?
- Bad allocations with OnCollisionStay, lots of GC spikes etc.
- Performance still needs improving.
- There are bugs that have gone unfixed like sweep vs 2 sided objects not ignoring backface, made it impossible to create a swept frustum camera system.

How can we make it BETTER?
- Introduce your own destruction physics on the GPU. This would work on console as well. It would merely simulate a single convex shape or even sphere shape, for particles, for masses of destruction or fluid. This stuff doesn't make much sense on CPU, much less a 'modern' console cpu. Or just introduce a simulation of lots of little bits on CPU if you must, we just want particle-physics basically that can also be used for destruction. Something cyclic we can do "lots of" that works nicely similar to instancing, they'd ideally be working together.

- Apex or similar system.

- Perf increases, less allocations.

- Better visualisation of raycasting (swept, spherecast etc) and colliders. Better joint visualisation and manipulation.

- Convert Mesh -> convex colliders should just work. Mesh collider too expensive. Help!

- Expose heightmap collider so we don't need to go through a fake terrain proxy.

- origin shifting should be supported now in latest Physx 3.x so you'd want to prepare some space for the inevitable requests from people there.

- better joint stability, faster.

- simulate at editor time, simulate n steps, manually simulate in game however much steps we want for setup, for fixing etc, you'll probably need it with origin shifting anyway.

- Speed, speed, speed. Honestly, the biggest limitation I have is how much I'm allowed to do.

No problem!

 

Yes!
http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/OriginShift.html

 

Although I think such a system needs to be a native feature of Unity 6 - extending to much more than just physics, but would be nice to think of the "big picture" going forward.

 

Who are you?

I'm the creator of a new unreleased 2d physics plugin, as well as creator of many 2d physics systems in other engines. I also make 3d games with unique features.


What kind of game are you trying to build or would like to build?

As it stands, I create all manner of games, both 2d and 3d, hi-res and low-res imagery and geometry, but there are 2 types of games I am aiming to create above all -- heavy emphasis on player-generated 3d content, and player-generated physics/states (that can be executed in-game and not just through the editor).

Additionally, I create many 2d platform-based games with old-school console-style physics recreations.


How does Physics fit into that? What use-cases do you have?

2D -- I want the common problems with characters on slopes eliminated, particularly in platform games, where jumpthrough/one-way slopes are involved (as well as slope handling in general!), making it easy to simulate 'retro-style' 2d movement. I also want to be able to easily create destructible terrain (i.e. destructible tiles included! -- not just Worms-like destruction with alpha-masking, etc.)

3D -- I do many things with physics, but I focus particularly on Mario 64-styled movement that takes into account walls and floors as well as slope angles (and jumpthrough floors!). A character controller that does this level of precision is something that should, imho, be included in Unity. Additionally, I enjoy making player-destructible/editable 3d geometry, and would really love something like the Digital Molecular Matter (DMM) engine such as that in "Star Wars: The Force Unleashed" to be included in Unity. I'm aiming to create some added realism to my character physics as well, so the Euphoria engine for ragdoll physics (used in SW:TFU and GTA V also) would be very welcome, though, for now, I'd settle for just a better cloth/hair editor and simulator in Unity that doesn't require any fancy shaders/etc. to be used.



What are the GOOD things about Physics that you like?
So, I'm loving the direction 2d physics are taking with the new 2d graphical features Unity is about to offer us. That being said, I'm glad Unity is supporting 2D a lot better nowadays than it used to. It's becoming a game-making beast.


What are the BAD things about Physics that you dislike?
Other than what's already been said about access to the lower-levels of physics (I also feel we wouldn't need this as much if we had fully-featured 2d and 3d character controllers from the start~!), I don't dislike much about the physics system -- though check out my "How can we make it BETTER" section below to get more of the specifics that I feel Unity sorely lacks in the Physics department.

2D Horizontal Edge Colliders + Horizontal Raycasts/Linecast = ???
So, yeah, they should register a collision. Maybe we need a fatter ray or something, but if the ray's technically on the exact line with the edge-collider, a hit should be registered. 'Nuff said.

Next Up:
Other than the above-mentioned, I do have a few issues not mentioned in my next section. These are not necessarily Physics directly, but they're relevant, to say the least, and I don't know where else to address these issues, so here goes:


1) LAYER MASK function arguments -- these are extremely inconsistent at best. IgnoreLayerCollision, for example, is a huge offender when combined by something like Linecast imo. I do understand somewhat why you need a layer mask vs. a layer index, but making people put a 1 >> LayerMask.NameToLayer() in some places and simply LayerMask.NameToLayer in others is just confusing and unnecessary.

2) Additionally, having Physics options tucked away waaay under Project Settings AND having the options appear differently in the Inspector area when it's in Debug Mode is highly confusing. I once spent days trying to figure this stuff out. I thought it was a Unity bug that my Layer checkboxes were somehow not appearing there.

3) Finally, many physics functions don't really have much in the way of explanations to help users understand them anyway. I'd suggest offering graphics in the manual/scripting areas to illustrate these functions a lot more clearly to users.


3D**) One thing I do have to mention about 3D physics though -- they are becoming stagnant imo. Stuff like Digital Molecular Matter and Euphoria is becoming the norm these days, but even something as common as cloth/hair simulation is really rudimentary in Unity, despite it being highly standardized features in games these days. I only wish there was something we could do, at the very least, about the latter. Cloth/hair is very important to go with the nice new GI feature we have nowadays. Stiff hair/clothes just doesn't look nice with otherwise hyper-realistic environments.

2D**) Also, very little support for on-the-fly skinned-mesh renderers with generated animations of its individual vertexes (such as stuff like the "Edge" section with the guy's nose being stretched: http://esotericsoftware.com/spine-meshes#Edges


How can we make it BETTER?

2D:

Two problems usually come to mind with my 2D use-cases -- first, a separate (user-made) physics engine is generally required, regardless of whether the actual "physics" are required to be custom. It is FALSE to think that every game must have a separate custom-programmed physics engine to suit the needs of their game, when in-reality, all they're really looking for is simply custom-values on particular physics features/properties to suit their 2d platforming game.

Second problem is that slopes, in-general, are poorly handled in Unity for 2d games, and that probably has a lot to do with how lateral movement is dealt with (i.e. rather than an hspeed variable that takes slope normals into account to keep a constant movement speed up the slope [and an option to do otherwise], we are forced to do these calculations ourselves and rather than, say, simply moving to the right -- we must check for a slope angle / tagged object / normal angle relative to our collider / etc. etc. and this pain is further compounded by the need for moving one-way slopes and platforms with multiple edge colliders on them, simulating bumpy-ness (even with the new platform effector 2d help, one must use multiple gameobjects to use the surface arc property across multiple 2d edge colliders, rather than taking each vertex of the edge collider into account to calculate its surface arc individually).

Finally, the ability to stretch and animate individual vertexes for skinned mesh renderers, doing something like the following for animated 2d meshes generated for body parts of a multi-part character (that, of course, can also be made physics-responsive) that may be swapped out at runtime with other meshes (i.e. an arm with stretchy fingers/forearm swapped into an arm with foreshortening with little need to be stretched): http://esotericsoftware.com/spine-meshes#Edges


3D:

1) For movement -- A Mario 64-styled movement controller that takes into account walls and floors as well as slope angles (and even jumpthrough/one-way 3d floors!). A character controller that does this level of precision is something that should, imho, be included in Unity, allowing users to modify it as they see fit, with most of the basic basic work being done already for them, just letting them set parameters for most other stuff.

2) For environments -- destructible 3d -- something like the Digital Molecular Matter (DMM) engine such as that in "Star Wars: The Force Unleashed" to be included in Unity for destructible 3D objects. Additionally, native support for any 3d voxels would be awesome.

3) For characters -- the Euphoria engine for ragdoll physics (used in SW:TFU and GTA V also) would be very welcome, and also a more user-friendly cloth/hair editor (check out iclone if you want a rudimentary texture-based approach to allow people to import at first, but I'd prefer to also eventually have a soft-brush style approach that lets you either manually select or stroke hair/cloth into soft/rigid states).


Both 2D and 3D:

More universal functions -- This is only a loose suggestion, but I can't tell you the number of times I've forgotten to put a 2D behind the function name / collider / raycast / etc., so consider making the physics systems recognize whether you're aiming for the 3d version or 2d version by letting them automatically recognize that you're passing something like a Vector 2 or Vector 3, and change them from 2D or 3D versions accordingly (automatically) from behind the scenes. For those that don't have Vector coordinate arguments, if you can, potentially just use the most recently used coordinate system (or the number/arrangement of arguments in the function, as 3d functions generally require different ones than the 2d version of the functions). To ensure you have the right coord system for certain, you can always add an (optional) argument to the function/name/etc. to specify the system you need.

 

Pretty much what Erik said but a thousand times this in particular:

I've had a really hard time getting into Unity despite how bad I want to use it because I just feel so limited when it comes to dealing with collisions.

 

Who are you?

An indie?

What kind of game are you trying to build or would like to build?

A "per-pixel destruction" game similar to Cortex Command

How does Physics fit into that? What use-cases do you have?

Almost non existent. I suppose box2d and physx were both designed without this use case in mind, but boy it would be great if I could quickly generate 2d colliders for a world like this, allowing me too easily use 2d physics to interact with the "pixel world", and things like edge collider could almost do this, but ends up being a bit performance intensive if you update changes too frequently.

What are the GOOD things about Physics that you like?

They work great in 3d, or static objects in 2d!

What are the BAD things about Physics that you dislike?

I can't complain, because like I said they weren't intended for my use case, but it'd be sweet if the 2d physics had a high speed dynamic collider, where positions of vertex points could be adjusted fast at runtime somehow...

How can we make it BETTER?

Pretty much what I said above. Otherwise it is pretty great, and normal uses seem to work well as far as I can tell! I'm very grateful for the 2d physics at all, as for years I tried 2d without it, and... it's a lot better

 

Who are you?
I'm a hobbyist developer, a programmer.

What kind of game are you trying to build or would like to build?
I'm trying to invent and implement a system that would allow players to construct arbitrary complex structures out of literally nothing - just a small set of basic shapes. For example, you can take a basic cylinder log, cut it into a bunch of bars and planks or arbitrary convex shapes and then connect these parts the way you like using nails, staples and L-brackets to construct buildings, furniture, vehicles maybe. With a certain level of creativity a user can take raw wood logs and build a whole realistically looking village out of it.



How does Physics fit into that? What use-cases do you have?
The project heavily depends on physics. Each building part has its own collider (box or convex mesh). Each independent object is a rigidbody with a single or compound collider.
– I use forces to drag the objects and align them relative to each other;
– switch collisions on and off on per rigidbody and per collider basic;
– switch from kinematic to dynamic bodies and back and forth;
– use a lot of raycasts for orienting objects, calculating cutting planes, finding neighbor parts that should be connected to each other;
– use physics materials to reduce or increase traction;
– use collision events to figure out what other rigidbodies the given one touches (see the BAD thing #2);
– use constraints to stop undesired movements or rotations;
– use joints to create dynamic connections between objects for things like wheels, axles, doors and windows;
– ...

I doubt there is a physics feature left that I don't use or haven't used or at least haven't considered to use, except maybe ragdolls.

What are the GOOD things about Physics that you like?
Performance is really good. I ran some benchmarks, the numbers I saw were pretty nice, and I still know some possible improvements I could do on my side, that would make them even better.

The API is rich and helpful. There are some holes though (see the bad things).

The workflow is intuitive. Physics basically just works.

What are the BAD things about Physics that you dislike?
How can we make it BETTER?

Starting from the most annoying:

1. I would like to have access to [something like] narrow phase collision detection to run custom queries. Sometimes you just need to know, what colliders a given one will intersect being put it in a given position in the world before actually putting the real object there. The practical question is ― is it safe to put an object in a certain position in the world?

From what I've seen, I'm not the only one who runs into this problem.

The current API can't give a simple answer to this question now. There are workarounds, but non of them solves the problem completely:

a) Physics.CheckBox/CheckSphere/CheckCapsule
– there's no CheckMesh,
– returns simple true of false instead of a list of actual Collisions, so no way to figure out what other colliders are and whether they are overlapping or just touching the given one.

b) Use triggers.
I can make a collider to be a trigger (so if I put in in a certain position in the world it won't push away the existing objects) and then wait for its OnTriggerXXX events. Again, it gives Colliders instead of Collisions, so no idea whether the object overlaps these colliders (which is bad) or just touches them (which is totally fine).

c) Temporarily freeze the world setting all the nearby rigidbodies to kinematic, then put the object in its desired position in the world with disabled renderer and wait for its OnCollisionXXX events. They will give the actual Collisions with actual ContactPoints that have separation fields that finally will tell how bad the collisions are.
― But this is the ugliest way I can imagine and I don't want to freeze the world.

2. I haven't found a simple way to answer ― what are the neighbor rigidbodies that a given rigidbody is currently touching?

The way I solve it currently is by
– attaching a script to the rigidbody that listens to its OnCollisionXXX events;
– waking it up and shaking a little to regenerate all the contact points;
– collecting the collision events for a while;
– removing the script and putting the rigidbody back to sleep if it was sleeping earlier.

There must be a more simple and straightforward way to get all the rigidbody's current contact points. I suspect Unity knows them already, it just doesn't want to give us this information.

3. Fix this bug please - 678348, video. It's one year old already and I still can't invent a workaround. It renders continuous collision detection between two dynamic bodies useless.

4. Joint gizmos are not informative and barely visible.

 

After spending the entire day addressing an issue with the suspension in one of my vehicles, I've added a new request to my "How can we make it BETTER?" section:

• Allow to configure WheelCollider.sprungMass from scripting (currently is a read-only value). I've encountered situations where the calculation is arbitrary, causing further suspension issues. Example: when the center of mass is located outside the boundaries of the wheels.

I guess this can be enclosed in the general "Just more access to the behind-the-scenes stuff" request.

 

This is exactly what I am missing as well. +1 to that.

 

Late to the party... I'd like to echo many of the comments above. I've mostly been dealing with vehicles lately, so Edy's concerns are to a large extent my concerns. There are many good points and useful requests already in the topic. I have just a couple of things that I could add to the list that are particular problems we've had with the game.

Who are you?
An indie developer, one of two programmers having worked on Turbo Dismount®.

How does Physics fit into that? What use-cases do you have?
The game is essentially driven by the physics engine. Every dismount (a game run) involves making some initial choices (level, vehicle, character, character pose, vehicle steering path), applying timing and power (pulsating power meter, NPC vehicles moving in scene). Then, physics take over and you are practically just observing what is happening. Everything is recorded and afterwards you can playback the action in super slow motion to see how Timmy managed to lose his head riding a tricycle.
The game is intentionally simplistic visually, to leave room for the player's imagination, and to be less "offensive". The sounds on the other hand are a bit exaggerated. The physics simulation doesn't need to be hyper-realistic, but it has to be convincing enough to set the stage in the player's head and to really build up the anticipation of what is just going to happen.

What are the GOOD things about Physics that you like?
Using unit scales, object sizes and object masses close to their real-life values, you get almost real-life behaviour. The way we set up everything in scenes feels intuitive and easy because of that.

What are the BAD things about Physics that you dislike?
Well, I don't want to go too deep into it, but the WheelCollider in Unity 4 has been a little problematic, especially due to the unrealistic friction behavior. We have managed to circumvent many things by outright hacks and get it close to our liking. With Unity 5 and the PhysX version change our game behavior changes so dramatically we haven't taken the plunge to start redoing the game for the new version. We have spent some time trying to get a feel of how close we might get, but it would never be the same. And not being the same would also practically break user levels tuned to a specific behavior. The biggest single reason still is the WheelCollider in Unity 5. I had trouble trying to get our cars moving and making sense of the WheelHit values. Once I thought I was getting there, I drove over a traffic cone (a small dynamic rigidbody with 10kg mass) and it sent the car barrel-rolling in the air. Our game is full of small objects to be interacted with, and it's obvious the WheelCollider is not meant for dealing with them. With Unity 4 WheelColliders we got away with it. I have since come up with a proprietary wheel solution that does not use raycasts. While I'm personally happy with it, it's not a solution alone for us to port our game to Unity 5. But we might revisit this topic when we have our backs against the wall and some crucial platform support won't make it to a Unity 4.7 patch release.

How can we make it BETTER?
With that our of the way, some more specific things I think could be addressed.

These are worth repeating

I'd just like to mention that it would be ok for us to be able to do this in Update() or the next frame's FixedUpdate() against the "collision lists" gathered in the previous physics frame. For us being able to call narrow phase checks from broad phase callbacks for example would not be important.

Yes. Also, it should be called when you deactivate the object or disable its collider. OnTriggerEnter is called correctly for all the cases as far as I can tell.

This. Pretty please.

These would have been relevant to us:
Automatic isKinematic behaviour switching in case of collisions
In our game we have NPC vehicles that are kinematic and follow a path laid out by the level designer. We send our own dynamic player vehicle and the player itself to the NPC traffic. We would like the collision between the player vehicle and the NPC vehicles to be "dynamic" in nature.
- If we don't do anything, the NPC vehicles will remain kinematic and every NPC vehicle is like a freight train.
- If we register a collision callback and set the NPC vehicles to dynamic upon collision, a collision first happens with a kinematic NPC vehicle and the initial collision response looks almost the same. The newly dynamic NPC vehicle seemed to carry freight train momentum through the initial collision and then in the aftermath it behaves correctly.
- We now move "proximity triggers" in front of our kinematic NPC vehicles to set them dynamic when they are about to collide. The triggers are moved in realtime to predict the collisions, accounting for the NPC velocities. This works mostly ok, but misses happen. Sometimes a close call happens that didn't result in an actual collision, but made the NPC veer off its path. But that's fine. The problematic thing is though, that we have to use considerable amount of processing for the prediction (user levels have hundreds of NPC vehicles), and the physics engine could do all of it for us with a behavior flag.

LayerMask LayerMask.GetCollisionMask(string layerName) or similar
I can't find a way to access the Physics settings' collision layers anyway in the script. Maybe it's hidden somewhere. But basically say I have a gameobject in layer A. Layer A collides with layers A, B, C, and D in the collision matrix. I'd like to do a raycast from my gameobject and give it a layer mask with all the layers the gameobject collides against. Now I have to construct it by hand, like
LayerMask mask = LayerMask.GetMask("A", "B", "C", "D");
If I later change the collision matrix (e.g. add new layers) my raycast could be broken unless I miraculously remember to fix it.

LateFixedUpdate() or similar
We do a lot of gamelogic in our FixedUpdate() due to the nature of our game and also the fact that we record gameobject state for our replays in FixedUpdate(). We need temporally consistent data for fast seeks and overall pleasing smooth motion. In Unity's execution loop FixedUpdate() is called before the internal physics update, the Update() and LateUpdate() both get called after the internal physics update. This means that in FixedUpdate() we always get "old information". For example: we draw a skidmark in FixedUpdate() in our wheel script right at the collision reported by a wheel. The collision info is from the previous frame. By the time the wheel and skidmark are rendered the wheel will have moved due to the physics and animation updates and the skidmark appears behind the wheel.
So we'd just like a temporally consistent LateFixedUpdate() variant, which would be called after the physics update and collision callbacks.

Shuriken update optionally in FixedUpdate()
While on the subject of time, I'd just like to bring this minor thing up. Ok, it's obviously not an issue for most people and only directly related to physics via the particle collisions. We'd like to be able to specify whether Shuriken updates its state in FixedUdpate() or the regular way (upon rendering?). This is directly related to our replay recording. As we do it in FixedUdpate(), it's possible that many replay frames pass without a change in the particle systems. So we have to try to interpolate the missing data.

Detailed collision events with 0 contacts?
This is actually a bug, could be fixed by now. I couldn't easily find it in the issue tracker. We used to get ArrayIndexOutOfRangeExceptions sometimes when processing Collision.contacts in the detailed collsion callback, with 0 elements in the contacts array. We've since added checks everywhere, but I'll go and remove them to see if I can make this happen again.

 

Who are you?

I would not call myself a dev, but I am tinkering with a game in my free time.

What kind of game are you trying to build or would like to build?

A racing game.

How does Physics fit into that? What use-cases do you have?

A vehicle is just a rigidbody with wheel colliders. I use mesh colliders for the scenery.

What are the GOOD things about Physics that you like?
It is possible to get a game going with a minimum of fuss - colliders and gravity work as expected and are easy to understand.

What are the BAD things about Physics that you dislike?
I have experienced most of the bugs that Edy and Marcos described above. Making our own replacement for WheelCollider is surprisingly difficult due to many properties being inaccessible.

How can we make it BETTER?
Please fix the wheel collider bugs. Unity 4 version was actually fairly sensible but required getting the correct values from somewhere. Unity 5 provides a default vehicle therefore obviating the need to enter the values, but introduced new bugs.

 

Who are you?

Professional dev working on a hobby project.

What kind of game are you trying to build or would like to build?

A top-down arena shooter with LOTS of enemies.

How does Physics fit into that? What use-cases do you have?

I'm trying to squeeze out performance to have 500-1000 enemies on the screen, mostly just using kinematic objects for hitboxes, raycasting, finding nearby enemies etc.

What are the GOOD things about Physics that you like?

Easy to use, works for most situations.

What are the BAD things about Physics that you dislike?

Physics layers tied to render layers can be annoying.

Performance. There's also lots of spikes and slower frames whenever FixedUpdate happens. I'm not sure I like the FixedUpdate method in general, since the cost is not constant.

If I just want to use the physics for raycasting against hit colliders, there's a lot of overhead and the performance suffers. Just moving 1000 cubes with kinematic RigidBodies through RigidBody.Position (with interpolation) takes 3 milliseconds on the frames that physics are updated.

How can we make it BETTER?

Improve the performance, especially when there are lots of objects.
It would also be great to have simple colliders that can be used just for raycasting, don't reguire a RigidBody and could be moved via the Transform without much overhead.

 

Nice! hopefully without alloc? or prealloc.

Please elaborate what this means

What does this do?

Thanks!

 

We to be better of supporting pooling of Rigidbodies and Colliders. That will reduce GC pressure.

Internally we can optimize how we read the simulation result from PhysX and apply it to the unity Transforms.

We want to provide a "cutoff" of how long to takes to simulate the physics during the FixedUpdate phase. See the "Spiral of death" here http://gafferongames.com/game-physics/fix-your-timestep/

 

Who are you?
One of the developers working on a game called Gang Beasts.

What kind of game are you trying to build or would like to build?
A physics based fighting game.

How does Physics fit into that? What use-cases do you have?
We use a custom character system which is a constant ragdoll controlled with forces, effectively a "physics puppet". These characters fight in a multitude of hazardous environments with large sections of dynamic and/or destructible constructions (for example on the back of two cargo containers hanging from cranes on breakable ropes).

What are the GOOD things about Physics that you like?
We couldn't make the game without the ease of access and ability to experiment that Unity gave us. The fact we can say "will this work?" and then just make a quick mockup and see the results in minutes. A lot of our stages came about from exactly that question.

What are the BAD things about Physics that you dislike?

• Stability when creating chains of connected rigidbodys (ropes).
• Joint gizmo's are nearly impossible to read (don't think I've ever figured out what way some things going to rotate from the gizmo)
• Linear joints are a pain (it starts at 50%), there're many situations where being able to set a minimum and maximum distance from the connected object would be very helpful (ropes).
• We've actively avoided wheel colliders due to stability issues.

How can we make it BETTER?

• A better visualisation of joints limits (angles and linear limits).
• The ability to run a secondary simulation on a different timestep
• GPU physics simulation (especially for consoles)
• Native buoyancy support
• Native water simulation (buoyancy / splashes / ripples / waves)
• Some sort of solver that takes an array of rigidbodys so they take into account each other instead of working against each other (I guess the ragdoll system does this already, but we don't use it because of the way our characters are constructed). AKA non standard ragdolls. May help with ropes!
• Min and max linear limits for ropes (constrained between start point and connected object), would help with ropes by connecting the start and end points.

As you can probably tell, ropes are currently our biggest headache.

 

Me - I'm me, I poke around with code in my spare time.

Physics improvements - The wheelcollider isn't as versatile as the old one. Free rotation, zero suspension vehicles etc. Also, why can't we get full collision information without actually resolving the collision physically. I could have used this many of times and it seems as simple as adding a checkbox. I know there are workarounds as always, but seems like an obvious one to me.

 

5 yrs later and the box collider still missing a simple ROTATION parameter

 

Your GameObject is the rotation parameter. Use compound colliders.

Compound colliders are where the colliders do not have rigidbody on the same object. This way, each collider can be rotated and positioned as child objects. In this setup, the rigidbody is on the parent object instead.


https://docs.unity3d.com/Manual/CollidersOverview.html

 

I can understand his pain though. This is not straightforward enough to be intuitive.

To have to have the transform overhead of many different gameobject colliders doesn't make sense unless you realize the transform overhead of the gameobject is not costing twice -- thanks to the single Rigidbody -- but it is still costing once for the actual location of multiple gameobjects with empty transforms in the hierarchy -- which I wonder if it actually _does_ cost twice to compute (i.e. computing the AABB while testing collisions, as well as the transform location of the gameobject in the scene/world itself) -- which really doesn't seem all that efficient when you really think about it...

Yeah, I know -- it's pennies. But it's also bad practice for optimization too.
If you're looking at larger-scale simulations, even those pennies add up quickly.
Any decent programmer, wherever possible, _never_ (unknowingly) repeats themselves (and therefore, by extension, the programmer avoids submitting extra "work" to the machine). To make brand-new gameobjects for each collider, compute them, then recalculate the AABB (without reusing gameobject transform's positioning data, as I'm assuming happens) is the very definition of asking the machine to do more work than necessary -- even if only asking it to repeat itself once (i.e. with the single rigidbody taking into account all collision transforms on the base gameobjects in the hierarchy and storing them for later).

I might be wrong about this, but I'd love to know for sure if I am. D: