Categories & Tags
Archive

High-performance physics in Unity 5

July 8, 2014 in Company News and Info, Tech by

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.

Performance

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.

Compatibility

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

Share this post

Comments (109)

8 Jul 2014, 3:16 pm

Very nice!

    Anthony Yakovlev
    8 Jul 2014, 9:06 pm

    Thanks! :)

PawelM
8 Jul 2014, 3:24 pm

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

    Anthony Yakovlev
    8 Jul 2014, 9:07 pm

    Not with 5.0, but it might get supported with later 5.x. It’s on radar, but not on exact schedule yet.

greenland
8 Jul 2014, 3:30 pm

^ agreed.

Pavel
8 Jul 2014, 3:33 pm

Will be possible GPU acceleration?

Richard Fine
8 Jul 2014, 3:52 pm

“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?

    Anthony Yakovlev
    8 Jul 2014, 9:19 pm

    Richard, I totally agree with your theoretic thoughts on this. However, we’ve had lots of internal & external discussions that ended up with this solution. I completely understand that this change comes with a price, it may not be welcome by some developers, and that’s why I’ve highlighted it in this post — it’s for users to be aware of what happens.

    Speaking of the ‘right’ ways, I think we’ve done everything we could to educate our users about static colliders. We have this outlined in profiler, we have it mentioned in documentation, we had a talk at Unite about that, we have the whole Learn team spreading the word of not moving static colliders, we have the Evangelism team talking to our users worldwide. Nevertheless, it causes a LOT of confusion with our dear users. After ~10 years of living with this behaviour we’ve decided to give the alternative solution a go and see what happens. Speaking of cost, I think it’s not THAT dramatic. I believe you’re an active alpha user. Why not give it a try? :)

GorroRojo
8 Jul 2014, 4:16 pm

will all this work for 2D?

    Anthony Yakovlev
    8 Jul 2014, 9:20 pm

    No, it’s only about 3D physics. 2D physics are based on Box2D.

Yukichu
8 Jul 2014, 4:27 pm

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.

    Anthony Yakovlev
    8 Jul 2014, 9:23 pm

    I don’t have a test scenario for this yet, but we could work together and see where it ends. In general, simulating 3D physics is a little bit more expensive, so I’d not expect the performance boost here leaving alone the fact that it’s much easier to get some specific behaviour with 2D than with 3D.

8 Jul 2014, 4:34 pm

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

    Anthony Yakovlev
    8 Jul 2014, 9:28 pm

    I’ve put some thoughts on this in the reply for Richard’s post (please see if it makes sense to you).

    Plus, the performance of static colliders is not decreased, it’s actually improved a lot. They are just requiring a little bit more memory on creation. Just a little bit. All operations cost the same as before: casting, sweeping, anything. I believe that a huge amount of developers were moving colliders, and the most advanced ones were adding kinematic rigid bodies just about everywhere anyway. So it’s not a regression here we talk about. It’s on the positive side of the world! :)

JIM
8 Jul 2014, 4:43 pm

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?

    Anthony Yakovlev
    8 Jul 2014, 9:30 pm

    Yep. Having kinematic rigidbodies instead of static colliders would increase performance for you in Unity 4.x.

Ana
8 Jul 2014, 4:44 pm

I agree with Richard Fine.
Looking forward to physics improvements. It was about time.

Awesome Nick
8 Jul 2014, 4:52 pm

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.

Luke
8 Jul 2014, 4:55 pm

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

    Anthony Yakovlev
    8 Jul 2014, 9:31 pm

    This is something we should look into with later releases. It’s one of the most frequently asked features.

Jesse
8 Jul 2014, 5:25 pm

@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.

Me
8 Jul 2014, 5:38 pm

And what about ship sails?

F.Salka
8 Jul 2014, 6:18 pm

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.”

Cayl
8 Jul 2014, 6:19 pm

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?

Sebastian
8 Jul 2014, 6:26 pm

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.

    Anthony
    8 Jul 2014, 9:45 pm

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

Dave
8 Jul 2014, 7:35 pm

So does Physx work on iOS? For some reason I was thinking that was Nvidia technology.

    Anthony
    8 Jul 2014, 9:46 pm

    Yes it does. GPU acceleration is exclusive to Windows\PC at the moment (and not exposed with 5.0), but this might be subject to change in the future as well.

8 Jul 2014, 8:33 pm

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)!

8 Jul 2014, 8:42 pm

Will there be soft bodied physics added?

    Anthony
    8 Jul 2014, 9:48 pm

    Not in 5.0, but once we have our users migrated to PhysX3 and hungry for new features, there will be new stuff coming for sure: soft bodies, liquids, etc.

8 Jul 2014, 9:03 pm

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.

8 Jul 2014, 9:31 pm

“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!

Keith Boshoff
8 Jul 2014, 10:04 pm

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

Jes
8 Jul 2014, 10:31 pm

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! :)

Jes
8 Jul 2014, 10:33 pm

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

8 Jul 2014, 10:49 pm

any plans to support Nvidia Apex? http://www.nvidia.com/object/apex.html

    Anthony
    9 Jul 2014, 5:55 pm

    Not with 5.0, but it’s constantly on radar for 5.x.

Sinister Mephisto
8 Jul 2014, 11:04 pm

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

    Anthony
    9 Jul 2014, 5:56 pm

    Could you briefly outline what data does your project lack from?

Richard Lawrence Harrington
8 Jul 2014, 11:07 pm

“CUDA only works on Windows on NVIDIA hardware”

Yeah, that’s not true. I use CUDA on my Mac all the time.
Here are the drivers: http://www.nvidia.com/object/mac-driver-archive.html

    Anthony
    9 Jul 2014, 5:57 pm

    Yeah, not an accurate wording here, sorry. PhysX+CUDA does not work on anything but Windows. Linux got supported recently, but Mac support is still on it’s way.

Steve Yeager
9 Jul 2014, 12:02 am

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.

Kain Shin
9 Jul 2014, 12:37 am

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

Ray
9 Jul 2014, 12:43 am

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.

Christopher Ellis
9 Jul 2014, 1:06 am

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.”

Ray
9 Jul 2014, 1:10 am

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.

    Anthony
    9 Jul 2014, 6:01 pm

    Please see Kier’s reply below. The memory impact is not that dramatic as static colliders are still static internally, we just use the same pruner both for static and dynamic bodies to save on moving them.

David
9 Jul 2014, 1:21 am

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?

9 Jul 2014, 1:50 am

I hope this will speed up creation of mesh colliders for voxel type engine implementations.

Landon
9 Jul 2014, 2:13 am

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.

    Anthony
    9 Jul 2014, 6:03 pm

    No, I’m afraid, but editor-wise, this is not the best solution.

Landon
9 Jul 2014, 2:14 am

Also, I’m on an ipad and can not see the vehicle demonstrations.

Landon
9 Jul 2014, 2:14 am

Also, I’m on an iPad and I can not see the vehicle demonstration.

9 Jul 2014, 2:36 am

mouth watering…. cant wait… release it soon.. pls pls pls :)

Richard Fine
9 Jul 2014, 3:11 am

@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…

9 Jul 2014, 3:47 am

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
    9 Jul 2014, 6:07 pm

    All multicore devices are expected to get performance boost. We’ll have x64 for iPhone. We’ll have the neon-optimised code in PhysX SDK for Android.

Wes Jurica
9 Jul 2014, 5:56 am

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. ;)

thylaxene
9 Jul 2014, 6:50 am

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?

Matthew
9 Jul 2014, 7:11 am

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.

9 Jul 2014, 9:55 am

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

Sinister Mephisto
9 Jul 2014, 10:05 am

Custom collision callbacks and penetration depth data?

Alkis Tsapanidis
9 Jul 2014, 10:10 am

@MATTHEW:

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.

Sebastian
9 Jul 2014, 10:12 am

“Anthony:
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”.

Mark Velthuis
9 Jul 2014, 10:33 am

Will there be separate layers for rendering and physics in this update ?

Obaid B
9 Jul 2014, 11:12 am

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)

    Anthony
    9 Jul 2014, 6:09 pm

    We’ll update cloth editing in 5.x; in 5.0 the weight painting stuff is likely to stay.

CynicatPro
9 Jul 2014, 11:32 am

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.

    Anthony
    9 Jul 2014, 6:10 pm

    Actually, this is due to PhysX dropping support for ‘interactive cloth’…

NITIN
9 Jul 2014, 11:41 am

Hi
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

Jes
9 Jul 2014, 12:15 pm

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

Kier Storey
9 Jul 2014, 12:45 pm

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)

9 Jul 2014, 2:18 pm

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!
Seriously!
:D

Andrew Gratta
9 Jul 2014, 2:50 pm

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?

    Anthony
    9 Jul 2014, 6:14 pm

    I’m not sure I completely understand the usecase. Can you describe it on Skype or email?

Richard Fine
9 Jul 2014, 3:16 pm

@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.

Peter Dwyer
9 Jul 2014, 5:20 pm

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

    Anthony
    9 Jul 2014, 6:18 pm

    How should it? It’s only about handling the movement of static colliders in physics. Nothing to do with batching for rendering etc.

AtomicJoe
9 Jul 2014, 6:03 pm

PLEASE DON’T GET RID OF DINAMIC CLOTH !!

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??

WHY REMOVE FEATURES YOU ALREADY HAVE ?

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.

paulo
9 Jul 2014, 6:27 pm

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?

9 Jul 2014, 7:00 pm

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.

9 Jul 2014, 9:28 pm

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.

Kingchurch
9 Jul 2014, 10:37 pm

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?

Thanks!
King

MGB
9 Jul 2014, 10:41 pm

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

Kerry Baldino
10 Jul 2014, 6:04 am

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.

10 Jul 2014, 12:02 pm

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.

Unisip
10 Jul 2014, 3:33 pm

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.

Tks

ado
10 Jul 2014, 9:50 pm

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.

Tobi Mayr
11 Jul 2014, 7:58 am

“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. :-/

shadowndacorner
12 Jul 2014, 3:32 am

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?

Andrew Gratta
12 Jul 2014, 6:53 pm

@ANTHONY

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 andrewgratta@gmail.com

Thanks

    Anthony
    14 Jul 2014, 11:44 am

    Sent a ping. :)

Chris
13 Jul 2014, 1:21 am

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?

13 Jul 2014, 1:47 pm

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 :)

13 Jul 2014, 7:58 pm

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

Bryson
14 Jul 2014, 4:13 am

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.

14 Jul 2014, 4:21 pm

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…

Alper
14 Jul 2014, 4:38 pm

Yaşşa lan Edy :)

AndyZ
14 Jul 2014, 4:50 pm

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

ARIKMS
15 Jul 2014, 11:19 pm

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.

16 Jul 2014, 9:37 am

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.

NoiseCrime
18 Jul 2014, 3:48 pm

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?

Robin
20 Jul 2014, 7:13 pm

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.

an
22 Jul 2014, 11:26 pm

Please work on large terrain . Unity in large Terrain is unstable ! ( shaky objects )

23 Jul 2014, 9:00 am

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.

fiesta
27 Jul 2014, 2:21 am

What about real-time destruction?

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

Frank
22 Aug 2014, 12:22 pm

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)

Leave a Reply

Please enter your name
Please enter a valid email
Please enter a comment
Spam protection error

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>