Search Unity

We’d like to highlight some of the 3D physics changes you can look forward to in Unity 5.0.

We’ve been using PhysX 2.8.3 for a while now. We’ve not just used the plain stock PhysX, but extended it with numerous patches made by Unity engineers over the years. It’s been so long, and we say thanks to PhysX 2 for all the fish. As announced at GDC’14, Unity 5.0 features an upgrade to PhysX 3.3. Let’s give it a closer look.

PhysX SDK 3 is a radical redesign of the good old PhysX SDK 2.x. Basically, the PhysX team have taken the best ideas and best approaches from 2.x and rewritten the whole SDK from scratch. That means the entire codebase is different, all the interfaces are different and most of the functionality is different.

Now let’s give you a taste of how it feels to use Unity 5.0 physics.

To start with something simple, we’ve made the adaptive force switchable and off by default. Adaptive force is a special technique in PhysX to compensate for numerical errors when simulating stacks. However, feedback from Unity developers tells us that adaptive force contributes a lot to overall instability in game content. Expect your stack-like things to behave better in future.

Moving Static Colliders

Moving Static Colliders will be a lot less expensive. A Static Collider is just a gameobject with a collider component on it, but without a Rigidbody component. Previously, since the SDK assumed that Static Colliders aren’t moved, moving a Static Collider would trigger an expensive AABB tree rebuild that affected overall performance badly.

In Unity 5, we’ll use the same data structure to handle the movement of both dynamic and static colliders. Unfortunately, we’ll lose the benefit of Static Colliders consuming less memory than dynamic ones. However, right now, the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games. We wanted to change that.

Collision detection

Continuous collision detection has been improved by an order of magnitude. Continuous collision detection is used to prevent fast-moving bodies from going through other bodies without any collisions detected. Imagine a bullet shot at a piece of paper, or a game of pool where some balls will move faster than others.

In Unity 5.0, the SDK generates all the data required to handle fast movement. You just enable continuous collision detection and it works. PhysX3 features an algorithm used to detect whether the expensive CCD simulation is actually needed given the current body velocity or a default discreet would do just fine. It’s activated once you enable the CCD.

pool table

Rigidbodies on the broadphase

PhysX3 supports more Rigidbodies on the broadphase. In fact, you’ll be able to have several hundred thousand bodies on a single frame on desktop and desktop-like platforms. Previously, there was a fixed 64k limit on bodies. That wasn’t a constant that we could easily increase – it was a consequence of saving a lot on bits all over the SDK. Some console targets, such as PlayStation 3 will still have this limitation. There’s also a limit on physics materials: at the time of writing, you can’t have more than 64k of materials on any platform.

Scaling Mesh Colliders is free (more or less)

In Unity 5.0 we’ve reduced the cost of scaling Mesh Colliders. Previously, when scaling a Mesh Collider, you would have to create a new mesh with scale baked into the vertices, and that required valuable time and memory. With PhysX3 we are able to support non-negative scaling without any baking. It’s basically free.

Next, let’s take a look at two subsystems that differ so much from the Unity 4.x version that you can think of them as new: the cloth and vehicles modules.

Cloth component

Let’s start with cloth. In Unity 4 cloth simulation is supported via InteractiveCloth and SkinnedCloth components. InteractiveCloth has a cloth-like mesh behaviour i.e. “physical cloth” that interacts with other physics bodies, can apply forces and so on. InteractiveCloth is computationally expensive, so Unity 4 has another one, SkinnedCloth, for character clothing.

Since SkinnedCloth is decoupled from the main simulation pipeline, it is able to perform better than InteractiveCloth. The main problem with cloth is that both components were quite unstable and cost a lot. With PhysX3 integration coming, we have decided to drop support for InteractiveCloth and only have one cloth component, called simply Cloth, designed with character clothing in mind.

In Unity 5.0, Cloth no longer reacts to all colliders in a scene, nor does it apply forces back to the world. Instead, we have a faster, multithreaded, more stable character clothing solution. When you add it the new Cloth component no longer reacts to any bodies at all.

Thus, Cloth and the world do not recognise or see each other until you manually add colliders from the world to the Cloth component. Even after that, the simulation is still one-way: cloth reacts to those bodies but doesn’t apply forces back. Additionally, you can only use three types of colliders with cloth: a sphere, a capsule, and conical capsule colliders, constructed using two sphere colliders. These changes have all been introduced to boost performance.

The authoring interface in Unity 5.0 is similar to the SkinnedCloth one, and we are working hard on improving that in 5.x. Expect to see things like integration with Mecanim avatars added during the 5.x cycle.

The new Cloth component supports the GPU via CUDA internally, but we’ve decided to release this later in the 5.x cycle for several reasons. Firstly, CUDA only works on Windows on NVIDIA hardware, and we have a big presence on Mac & Linux. Secondly, we really want to focus our bug fixing efforts on core stuff first and move on to integrate fancy things after that.

New Vehicle SDK

Now, a few words about vehicles. PhysX3 has a shiny new Vehicle SDK which we’ve used to implement our WheelCollider component. The new component delivers much more realistic suspension and tire friction. Plus, it fixes a number of other long-standing issues.

In Unity 5.0, the new component can be used out of the box to generate a simple behaviour. I only expect developers to go for vehicle packages on the Asset Store when they want something that is already fine-tuned, realistic or advanced, like Edy’s Vehicle Package.

Look at what I’ve been able to set up in a couple of hours using a free mesh downloaded from the web (most of that time was spent in Blender preparing the model):

And here is one of the SUVs from Edy’s Vehicle Package:

Edy is currently working on the new version of his package which will bring more amazing stuff. Contact him directly for more details.

The are a lot of fantastic technical details about vehicles I’d like to share with you, but, for now, let’s just take a look at the new WheelCollider gizmos. This will give you an idea of how suspension is going to work as well.

wheel gizmo


In the above picture the wheel circle and wheel diameter are marked in green, the suspension travel segment in orange and the force application point sphere in green. On the suspension travel segment, there are marks for maximum compression position, maximum droop position and target position.

As you’d expect, the wheel can only travel between the max compression and max droop positions. The target position (also referred to as the rest position in technical talks) is located exactly where the sprung weight is balanced by the spring force; i.e. the position where the wheel is located when the vehicle is just standing on a flat surface. It might seem tricky to tune, but, actually, the max compression position is where your wheel is located originally in the mesh.

Next, you specify the suspension distance and target position as a fraction of suspension distance. Just two floats to rule them all, not a big deal! Have I told you that the new wheel gizmo now updates the rotation and position from the simulation data out of the box? You don’t even have to add actual wheel geometry and write the wheel positioning code to preview your settings. It’s all just built in.


PhysX3 is now prepared to run on multicores as the internal computation model is organised in tasks that can be executed on different cores. The SDK does all the multithreading, taking care of all the dependencies itself and granting optimal job decomposition.

From what we’ve seen so far, it’s reasonable to expect a doubling in performance generally just as a result of having a better code base and improved multithreading. In some instances, the improvement is dramatic, with up to tenfold improvements.

Performance ninjas interested in more data should visit Pierre Terdiman’s blog. He’s the core developer behind the PhysX SDK.


The new functions look and feel Unity-like, but there are still cases where the behaviour is different, parameters mean different things or, in some cases, old behaviours are no longer supported. Thus, Unity 5.0 physics is not 100% compatible with Unity 4.x. Be prepared to retune your old projects and rewrite some of your physics code when migrating from previous Unity releases.

There are many more details about physics in Unity 5 than I can share in this post. Please feel free to ask questions in the comments, or if you’re visiting our Unite 2014 developer conference this year, catch my in-depth talk on physics in Unity 5.0 and come say hi and have a chat.

More about Unity 5

109 replies on “High-performance physics in Unity 5”

Will FixedUpdate run in another thread, or are all FixedUpdate calls in the main thread like in Unity4?

For my Unity 4 vehicle plugin I have moved a major part of the calculations into another thread, but I would like to have all physics-related calculations (raycasts, add force,…) in its own thread (FixedUpdate is currently not nice with the catchup, which creates peaks in the profiler when 2 updates occur in one frame)

[…] a server we can hit that easily in about 10 hours. Unity5 uses an upgraded physics engine – so this is fixed, but Unity don’t love us enough to give us Unity5. So in the old version of Rust there were a few […]

What about real-time destruction?

I have seen that cloth will be enchanced. Is destruction in the works, too?

I think a way to simulate a set of rigidbodies after setting their initial state for x frames and not in real time would be really great for network multiplayer games.

Can you separate physics collision layers from camera rendering layers? For deferred, there is 4 layers exclude lighting limit, and for more advanced games, we need to setup physics/renderning layers more than 4.

Great blog post.

I agree with Richard and others in terms of the static/dynamic debate, though my concerns have been alleviated somewhat with Kiers reply. However I strongly disagree with the assertion that Unity did everything they could to educate users, though it might have improved over the years. The documentation was poor on the subject, so poor that the first I knew of this issue was when I spotted a problem with rotating non-rigidbody colliders in the profiler. Even then I didn’t recognise what the issue was (logged it as a bug) as the objects in question were not marked as static, they just had colliders attached, so while I didn’t consider them to be static, the physics engine did.

I think the problem in communication wasn’t that static objects needed rigidbodies applied, but that an object which wasn’t marked as static and just had a collider attached was considered a static object by the engine, but that was not conveyed to the user!

‘the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games’

So what were the other two? Seeing as one of the top three has remained for years because the message wasn’t getting out about static colliders, it might be a good idea to mention these others, perhaps even create a blog post about them?

Why would you remove the old cloth feature? It worked pretty well and it doesn’t appear that you can duplicate that behavior with the new cloth feature.

I haven’t read all the comments, but I think the static colliders issue could be solved easily.
You can make the default behavior of colliders dynamic and add an advanced setting in the preferences.

That way, only advanced users will enable the static colliders option in the setting. When this enabled the collider component will have a static check box shown that can be set as needed.

Nice but is the new wheelcollider still just a 1 direction ray cast or do we get better wheel collision detection as well?

One step forward in Physics simulation for Unity but also one step backwards for static colliders. You guys think making the static colliders slower and fatter because some guys don’t understand the way you expose it in the Editor is the best idea? I mean really?
Do you think no one will notice it? Seriously?
Wrong way to design software…

For the static collider problem, instead of making all static collider rigid bodies, why don’t you issue a warning when a user tries to move a static collider. This will teach people to use rigid bodies and will keep both worlds happy.

Wow, super informative. Thanks for the write up! Really want to go and start working on a car game now.

I’ve angrily given up on physx after the last update broke all my games, but maybe I’ll give it another shot for 5.0 :)

We stream a lot of mesh terrain in our current project, and we’re seeing huge spikes when creating the static colliders. There doesn’t seem to be any way around it currently.

Will the new static mesh collider in Unity 5 eliminate these spikes?


You replied to my previous comment asking if I’d like to discuss the use case in email or skype, but I’m not sure how to reply to you except by leaving another comment. I would love to describe my problem in more detail, so please let me know how to contact you. My email is


This is something that I’m surprised hasn’t been asked yet – given the fact that the newer version of PhysX is fully multithreaded, will we be able to make physics calls from other threads? For example, awhile ago I made a runtime navmesh generator that would have really benefited from being able to run in parallel – will this now be possible?

[…] server we can hit that easily in about 10 hours. Unity5 uses an upgraded physics engine – so this is fixed, but Unity don’t love us enough to give us Unity5. So in the old version of Rust there were a […]

[…] acalmar os ânimos dos desenvolvedores que não aguentam mais esperar, o blog oficial da companhia revelou alguns detalhes sobre a física da engine e a tecnologia PhysX, que vai […]

[…] acalmar os ânimos dos desenvolvedores que não aguentam mais esperar, o blog oficial da companhia revelou alguns detalhes sobre a física da engine e a tecnologia PhysX, que vai para a […]

[…] acalmar os ânimos dos desenvolvedores que não aguentam mais esperar, o blog oficial da companhia revelou alguns detalhes sobre a física da engine e a tecnologia PhysX, que vai para a […]

[…] acalmar os ânimos dos desenvolvedores que não aguentam mais esperar, o blog oficial da companhia revelou alguns detalhes sobre a física da engine e a tecnologia PhysX, que vai para a […]

«Unfortunately, we’ll lose the benefit of Static Colliders consuming less memory than dynamic ones. However, right now, the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games. We wanted to change that.»

Making your engine worse because some beginners are not able to read the docs. And the advanced users with their big projects, where every MB of RAM counts, will pay for it.
This is not the first time this happens, and I bet it won’t be the last time. I don’t get you, Unity. :-/

Bwahhh, i just want physicall movement tthat works like transform.Translate but does not ignore colliders, forces and velocity are sliding after key gets released and i dont like that, moveposition is not relative and sometimes laggy,and one of the biggest problems in my game is camera, if there can only be movement like rigidbody.physicallocation(player.position.x, player.position.y + height, player.position.z -distance)(vector3 value),and also rigidbody.lerpangle(from, to, speed) if possible.

Good to hear the physics is getting a major upgrade. A couple of issues i had in the past using physics on non game projects:
– init cost of using a mesh collider (especially on mobile). I understand why the attachment of a meshcollider would take a long time, but i. Ould love to have a way to multi thread it to prevent hickups (sometimes we’re talking several seconds on ipad3). Lighter colliders may not be an option when you don’t have full control of the input geometry, which is sometimes the case on non game projects. Can we expect any improvement on the ‘meshbake’ cost when initially attaching a meshcollider?
– having a way to perform simple collision queries, such as a simple collision test between collider A and B. This would be VERY helpful for instance for architectural projects or some serious games
To fix these two issues in 4.x i had to totally work around the unity physics and implement my own collision engine, which is not an optimal way of using my dev time.


Since utech is in a sharing mode these days, why not provide some more detail on the static collider choice? GIEF profiling test results!

I’m not saying that this change is necessarily good or bad, since I simply do not have enough data to make such a determination. And THAT is the part I find bad.

It is a behaviour / expectation breaking change which seems quite flimsily backed by a statement of «we gave up because other fixes were hard».

Or to rephrase:
«I think we’ve done everything we could to educate our users about static colliders»
– I respectfully utterly disagree.

Using a rarely used communication pathway in a pro-only part of the editor (profiler warnings are awesome and hugely under-used) and including statements on the topic in various event-bound presentations does not count as an honest effort, given the factor of time.

Bad argumentation for the decision aside, an additional takeaway impression is inconsistency in overall Unity design.

This change is in contrast to the upcoming changes to Unity animation and network systems as prime examples – where existing opportunities are kept, but users are further empowered by more choice.

[…] idee della versione 2.x e ha riscritto da zero l’intero SDK”, si legge in una nota sul sito ufficiale di Unity. “Ciò significa avere un codebase completamente differente, nuove interfacce e nuove […]

A lot of cool stuff but getting rid of actual cloth simulation is a big downer. A big step down. Just integrate Apex Cloth or write a new one altogether. That will help on performance. Just don’t make us spend a ton of money for one on the Asset Store.

[…] a new blog post on its official site, Unity goes in-depth on how it plans to integrate PhysX 3.3 into the upcoming version of its game engine, Unity 5. The […]

Good stuff… but any news on something like collision groups – something I’ve always missed in Unity physics?

Thank you for the update and it’s seriously exciting! Can I ask two questions regarding the Unity 5.0 physics?
1. Is there a plan to integrate the «articulation» of PhysX 3.3?
2. Are there expected joint fidelity and stability improvements to solve the wobbling hinge and jiggling bones problem when you configure a joint with mass ratio larger than 1:10?


Hello Anthony,

I used cloth in the past and I have to agree with GABRIEL PETTERSSON that it is really a nightmare to get it to work, and when it does the results are not really worth it. I am talking about Unity 4.x here but from his post it seems 5 is largely the same.

I would highly suggest you guys integrate Apex Cloth like UE4 does. It is simply a night and day difference and it will be really worth your engineering efforts.

I am actually currently working on a clothing heavy project that can be a great test bed for this sort of tech if you are interested.

Seconding the request for more control over time, object/world state, and update calls so we can do rewinds in authoritative networking.

(Actually, I can record and rewind rigidbody state just fine, but I cannot currently resimulate X seconds in an instant without writing my own solver.)

I want to tell the physics engine to take a subset of physics objects in the scene, initialize them with a certain (recorded) state, and return the result of N frames of non-realtime simulation.

At least, I *think* that’s what I want. I’ll have to ask your networking guys what they think about this issue as well.

just like to know what impact has the physics of Vehicle
in collisions as is normal in the real world collisions between other Vehicle or walls, is imminent.
In the worlds of race cars collision is imminent.
I noticed that in most scenes of physical test of the cars is alone, forgetting that in the real world there is no car alone. :)
I recommend the dev practicing the physical tests of the cars especially in large high-speed collisions against other Vehicle moving to what extent the car spins, rolls, especially in low speeds, which at the moment is what happens in current version.

I noticed that the demonstrations, only came to see cars and two-wheelers?


Skined cloth is a nightmare to setup with high poly models and, like others here, I don’t like the idea of painting vertices in the editor AT ALL.
Nvidia allready has a technology for this called APEX CLOTHING that seems awesome and artist friendly. If you were implementing this instead it would be VERY COOL.
Until now, the only clothing that worked for me in Unity was Dinamic Clothing, and you are saying you will deprecate it for the Skined Clothing??


Put the 2 clothing systems and let the users decide!

I pre ordered Unity 5 just because Physx 3, streaming levels and SpeedTree.
I’m starting to get worried now.

Obvious question. How does the change to how statics are handled affect static batching?
Not sure if anyone has asked already.

@KIER: Thank you for the insight!

I’ve looked up the pruner stuff in the PhysX SDK and I see the bits you’re talking about now – PxSceneDesc::staticStructure has changed from PxPruningStructure::eSTATIC_AABB_TREE to eDYNAMIC_AABB_TREE, yes?

Would exposing PxSceneDesc::dynamicTreeRebuildRateHint help us at all?

The streaming use case is fair enough. I guess it’s not supported in PhysX at the moment, but it would maybe be interesting if, in the future, more than two pruning structures were supported – for example, maybe letting us have a separate static pruner for each Region of Interest. Then we could define each streamed chunk of game world as a separate Region of Interest, with its own binary-serialized static pruner, and stream in a new chunk of world without disturbing any of the other pruners.

Using unity 4.x it is difficult to find the closest point from the collection of nearby colliders/meshes. Imagine a collision check that consists of an expanding sphere, centered at a query point. The first point that the sphere collides with as it expands is the closest point. Will a function like this be provided in unity 5?

Thank you that I am already allowed to test Unity 5 with PhysX 3 as an ( restored ) alpha tester to prepare my Robotics Simulation Package to be compatible with Unity 5 when it is released!
So it was really worth signing the wonderful, friendly NDA and purchasing Unity 5 Pro!
I am very happy because I don’t have the double work to code it for Unity 4 and then Unity 5!
Much LOVE!

Hi guys

Just a little follow-up on the debate over this modification to static actors. In fact, the static actors are still static actors (PxRigidStatic) and both memory footprint and simulation performance will not be affected by this change. What has changed is the use of a dynamic pruner instead of a static pruner for the static scene in the scene queries instead of using a static pruner.

Whenever any static actor in the SQ scene is updated, inserted or removed, the static pruner is rebuilt from scratch. This can be very expensive if you either move a static actor (clearly not recommended) or simply have a streamed environment when your static scene consists of lots of shapes. The dynamic pruner, on the other hand, is incrementally updated so inserting, removing or teleporting actors causes less of a spike because the cost is spread over several frames.

You still have 2 separate scene query pruners – one for the static actors and one for the dynamic actors – so if you don’t insert/remove or update any of your static actors, it is not expected that you will observe any performance regressions. It is just that they are both now using the same type of pruner instead of using 2 different pruner types. The performance of scene queries in general in PhysX 3.3 are significantly faster than PhysX 2.8.3 so you should see nothing but performance gains when you upgrade.

I hope this helps to clear this up

Many thanks

Kier (NVIDIA PhysX engineer, in case you were wondering)

Please Add Explicit CompoundCollider. It will be useful for trigger zones and in cases when we dont need RigidBody just collider and callback OnCollide from entire compound collider

I am making pool game using Unity3d Physics, single player works fine but now i want it to be multiplayer .

I am facing issue with physics synchronization like collision points,collision force. When two clients are connected to a room they exchange data through sockets instead of sending all ball data. I just send input like force vector by which the white ball is hitted. Theoretical,for same action ie.force in this case same response or effect should happen in game but it is not happening in my game.

I apply a known force in one client game connected to room & transfer that force to other client game connected to same room but displacement /position of balls due to collision is different.

I am unable to understand why this happen? I found Unity Physics engine behave slight differently on different device or platform due to different floating point precision.

I even try to sync the positions but it seems unrealistic & weird.

please suggest me way to make multiplayer pool game ,its really painful because i am not having any other thoughts how to achieve this .

Is Unity 5.0 physics is deterministic on various platform?

Thanks In Advance

why are you guys removing interactive cloth? you didnt give a real reason. is it an option on the new cloth component? its still necessary for many games. for example soccer games often need the net the stop the ball when it hits it while also stretching back. please make sure you are not stripping features.

About Cloth, I hope it is not too late, but I request to have a better solution rather than painting manually the vertices(?) of a mesh, shouldn’t it import groups/bone weights for easier assigning for properties?

Does this mean the cloth won’t interact with the character mesh directly? does it have to have capsule/whatever colliders? What about third party colliders? (Concave Collider, SAColliderBuilder)

Yes, sure. Couldn’t you do this before with Rigidbody.SweepTest?»

No. I don’t want to know if it collides with anything on the way if I’d move the object through the scene to it’s target location – I want to know if it collides with anything if I instantiate it at the target location. A way to check «is it safe to spawn something here, or would it intersect with anything».


It doesn’t. If you have an object with a rigidbody on and then you have lots of colliders without rigid bodies on child objects of it, you have a dynamic compound collider, not static colliders. In fact, the rule is that you shouldn’t parent rigidbodies, so you’re using it correctly.

Hey thats my billiards template model :P
Nice stuff can’t wait to test them out

[…] The Unity 5 engine will be getting a significant physics update. [More…] […]

I’m actually very excited about the change to static colliders, unless I’m missing something.

I’m building an airship game and need a ton of colliders per object. Hitboxes, Collision, AI Monitors, AI avoidance, etc…

Right now even with a massive amount of layer management. I need a lot of these «compound colliders» to not have rigid bodies so they don’t collide with the parent. My understanding of the way unity handles things is compound colliders like this that don’t have rigid bodies become static colliders. Sadly It would be impractical to put rigid bodies on all the children and keep them from colliding with parents etc…

I have huge performance hits due to this setup (though manageable) and am excited to get any performance boost this change will provide.

Yeah I use CUDA on OSX as well. Can you please explain? Don’t the CUDA OSX Drivers not work properly with 3.3? Or is it because OSX users need to install third party drivers which is an issue if you have sandboxing turned on? So distributing games becomes like the old days. First download all these drivers then run the game? (Obviously to be avoided) Is CUDA part of base Windows installs?

The new PhysX is by far my most looked forward to feature of Unity 5.

This decision with the static colliders though is mind boggling. For a mobile developer that makes heavy use of colliders in scenes, I am not looking forward to anything that make the already difficult Unity memory management even more difficult.

If it is such an issue to communicate this to users, why not have the message in the editor itself? If a game object has a collider but no rigidbody, display a message in the collider component in the inspector. (this is just one idea, off the cuff, but there must be many other ways to get the message across)

The solution talked about in this post is no solution at all. You must have been cringing when writing that part. ;)

I’m very excited for this! The speed improvements alone are very welcomed. I wonder how this affects the performance on lower-end devices such as Android, iOS and 3DS?

@ANTHONY: Yeah, I can appreciate the exasperation that must have led to this point. But I hope you can see the irony in you saying «that’s why I’ve highlighted it in this post — it’s for users to be aware of what happens.» I think the users who read the Unity blog are mostly the ones who already read the manual and are doing the right thing :)

But, this is why I chose my words carefully – to say that this is a failure of ‘documentation / usability.’ You’ve been trying the documentation approach; for me the next step would be to change the way the feature is exposed.

Under 4.x, moving a collider in a performant way is essentially an ‘opt-in’ arrangement; you opt-in by adding the rigidbody, and if you don’t have it then the system is free to assume you’re not going to move it, and to penalize you if you do. The problem is that users aren’t opting-in to this because, try as you might, they’re just not getting the message that they have to. So, why not change to an opt-out solution – assume that all colliders are dynamic (as 5.x is doing at the moment) unless the user has explicitly ticked a box that says ‘never moves.’ As Jes suggests, using the GameObject ‘static’ flags would be one way of doing this, though a checkbox on Collider itself might be better for runtime purposes.

I’d test the performance in the latest alpha but unfortunately I’m still blocked by other bugs…

Wouldn’t it make more sense to do this method with colliders:

If the object is marked with «Static» flags, the collider is static.
If the object is marked without «Static» flags, the collider is dynamic.

No rigidbody bull.

Is there a way to run some backend code to determine if the static game object will be moved at some point, and then treat it the less expensive way automatically? Or treat it like a static collider if you determine it doesn’t have any code to allow it to move?

The only thing I dislike is the change about the static collider, mainly because I don’t understand it. I don’t see how that is beneficial. Why would you attempt to move something marked as static? I maybe can envision some cases if using some of the static subtypes like Occlude or Lightmap, but it’s a stretch. We’ve always taken care in our design to flag only the appropriate items as static, and never moved a static collider until now. It’s easy to remember «if it’s moving it shouldn’t be static» and it’s one of the first things you learn about with Unity if you want performance, unless I learned that wrong. If we absolutely need to have this change, can you provide some comparisons? I’d like some benchmark data run against current PhysX with the static vs non-static vs. static-and-moving situation to better understand how bad this change could be for us. Or give us a option to keep using the current way.

About the static colliders: Would it be possible to create a new/differently named collider called «Static Collider» that doesn’t move? It would be exactly the same, only a different name to make things clear that «This is static.»

Several questions:
– Will there be any new collider types?

– Jiggle bones / hinges are they more reliable to create now? Like ponytails on a skinned character, is that now possible or will the physic engine still freak out like mad if attempting to use joints or even the previous cloth system? Hair and jiggle bone extras have been my long standing wishes for Unity Physics and while I managed to sort of hack it in (with some residual issues like stretching on startup until it balances itself), it never was satisfying until now.

– Are Ragdolls better now, and is there a new Ragdoll creator?

– Can you provide details on the improvements on the clothing authoring interface? Previously attempting to use it on a skinned mesh it would after going into runtime flip 45-90° or worse, forget assigned vertices or not let you select if you had more than a handful of verts. You can understand how hearing «similar to the SkinnedCloth one» is REALLY scary so I really want to know in which ways is this improved, can we see it and know more about it?

– So does this mean vehicles won’t flip over when doing acceleration / curves anymore? As a amateur to vehicle physics it has been the main reason I couldn’t do vehicles so far since you had to counter-steer or block rotations with a strong effort from script. Ideally I’d want to define my wheels (I like what I’m seeing from the new Wheel Colliders), and accelerate and see it just work. Your videos appear to use Edys Vehicle stuff and I can’t tell what the «long standing issues» are that have been fixed, it’s too vague.

Will we still need to implement our own sliding down inclines for char controllers? Is static/kinetic friction represented?

So you are removing memory improvements in the case of static colliders so people who don’t look at warnings will have slightly faster games? I love everything else about this post but I’m going to have to disagree with losing any kind of performance/memory gain when it is a simple fix on the user’s end.

Please Tell us about the OnCollision Event and the available data in the collision object. Older version of unit never gave enough data

Will we have ability to set different timescale for different RigidBodies?
This will be very useful for gameplay based on Time.

Static colliders can be used for GameObjects that has static check.
This will be very understandable. If I check GO as static then his collider will be static! :)

Great stuff!

Two questions: why remove interactive cloth completely? Seems a bit extreme. Improving features is great removing them is a bit… eh.

I’m with Sebastian with regards to collision/intersection queries. Rigidbody.SweepTest returns false if two collider’s are already intersecting.

Third question (I lied), can you give us a method to extract the convex hull from a mesh collider? :D

«Instead, we have a faster, multithreaded, more stable character clothing solution.»
Yes for as long as I can remember cloth has always been rendered with multiple (cotton) threads :-P . So, yeah, you’re finally doing cloth right!

Great to hear the improvement for vehicles! One thing, is the new wheel collides with car stops precisely? The current Wheel Collider can’t handle it.

Also, is there any plan to support variable simulation time step? In some game genres (e.g. high speed action games, bullet hell shoot-em-ups), I would like to make Update() and FixedUpdate() perfectly synced to get rid of the interpolation latency. In that case I currently set very small time step and make FixedUpdate() 200Hz or so, but it is not ideal.

I’m also agree with richard. Static is Static and static stuffs doesn’t move, because if they do, they weren’t static but dinamic!!!

So my walls now will expend memory implementing movement psysics??. Is nonsense to «move stuffs» and is nonsense to sacrifice something that is working fine because some developers misschoice the right answer.

Just for adding something new to this thread: Isn’t there a way to apply polymorphysm and add dinamic psysics in runtime to a static object, just when an event happends? and if that were the case, shouldn’t be better implement a baked psysical animation rather than apply psysics to static objects? I think that «Top 3 performance cost» is fault of the final designer, not the tool.

Like Awesome Nick Said, if it is usabillity’s bad driving problem, then you should add 3 states and implement in background what should it be right.

Sorry for my bad english, not my motherlanguage.
Greetings and beers (and pizzas)!

Is there now a way to do collision queries? As in, «if I place this object over there, would it collide with anything else»? It is a feature of PhysX that I wish I could use with Unity. OnCollide/OnTrigger is useless for this.

The new Cloth component supports the GPU via CUDA internally, but we’ve decided to release this later in the 5.x cycle for several reasons. Firstly, CUDA only works on Windows on NVIDIA hardware, and we have a big presence on Mac & Linux. Secondly, we really want to focus our bug fixing efforts on core stuff first and move on to integrate fancy things after that.
Does that mean you’ll find a way to have GPU cloth on non-nvidia systems? can you implement OpenCL for mobile platforms? and what are the other aspects of PhysX that harness the GPU as well.
One last question: did you guys have to extend PhysX 3 like you did with 2 or is it just plain vanilla SDK from Nvidia and can future updates be expected in the 5.x cycle?

I have an iOS app where it generates 40000 static colliders on the fly, it runs fine and consume very little memory…..because…it is static colliders..but now with the new physics my app memory usage will go through the roof? i hope the dev addresses this issue before unity 5.0 release….i don’t want static colliders to be treated as dynamic ones because some noob programmers don’t know that they need to attach a rigid body to any moving collider -_-

“In Unity 5, we’ll use the same data structure to handle the movement of both dynamic and static colliders. Unfortunately, we’ll lose the benefit of Static Colliders consuming less memory than dynamic ones. However, right now, the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games. We wanted to change that.”

@JIM As long as all your characters hit boxes are children of your character, you only need one on the root. A rigidbody on a game object aggregates all the children under it. I believe the character controller also does this if you are using that instead of a rigidbody.

Will we be able to manually rewind/fast-forward? E.g. for lag compensation. This would be hugely useful.

I agree with Richard, though I like that moving an object without a rigidbody is much cheaper. Perhaps there can be three states instead of two? Dynamic with Rigidbody, Dynamic without Rigidbody, and Static.

Wow, as someone new to unity, I didn’t know about this issue with static colliders – should I have kinematic rigidbodies on all my players hitboxes in that case?

I agree with Richard Fine. Communicate this fact but don’t «solve» it by decreasing the performance of Static Colliders. Just my two cents.

I asked this in the forums, no reply but… with PhysX 3.3 being multithreaded, any idea on how performance compares to the Box2D implementation?

Would be interesting to know.

«In Unity 5, we’ll use the same data structure to handle the movement of both dynamic and static colliders. Unfortunately, we’ll lose the benefit of Static Colliders consuming less memory than dynamic ones. However, right now, the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games. We wanted to change that.»

What were the actual use cases for wanting to move Static Colliders? I get that people often didn’t realize that moving them without a rigidbody was bad, but that’s a failure of documentation / usability, not a failure of the way things actually worked. Why change this, and make things more costly for those of us who really do have static colliders, instead of just better communicating what’s going on?

Will unity 5 support non uniform gravity fields? Ability to modify gravity vector would be awesome!

Comments are closed.