Unity 5 and Physx 3.3.0 details...

Hi, all, great News and a lot of fine features announced regarding Unity 5.
But the most important one for me is the physx update to Version 3.3.0.

So what is implemented to Unity?
GPU support (Guess not)
Artikulated joints? (more precise joints, rope?)

web76

 

It's supposed to have better performance and a new cloth solver. We probably won't know exactly was implemented until Unity 5 is released.

 

http://physxfiles.com/PhysX_3-3_release_notes.html

 

http://physxinfo.com/news/12346/unity-5-announced-incorporates-physx-sdk-3-3/

Sounds promising! I wonder how it will affect / benefit mobile? (/me heads off to read )

 

I'm guessing APEX is separate.

 

I'm very curious about the advanced vehicle model in Unity 5, and what parity it has with the PhysX 3.3 vehicle (i.e. steering coefficients, tank vehicle support).

I'm using a third party vehicle physics package, unfortunately it's very difficult to configure, and the author is rather unpleasant to deal with (when non-responsive for weeks), if not downright rude.

 

There is no Unity 5 Apex support. You will have to add it yourself.

 

will it be easier to do then? right now we its a pain in the mind

 

No, it won't be easy afaik. But you can all chat to unity/ask them why (I don't know why).

 

I wouldn't expect every feature in NVidia's changelog to be present in the Unity implementation, since it's very likely several adjustments will have to get done to properly support all platforms. I am very excited about this in any case though, it's not just the better cloth and perf boost even, the joint solvers are much improved, collision handling too, pretty much every aspect of the simulation has been improved in some way, so whatever makes it in will be a very welcome addition already.

Cheers

 

The most important thing for me, would be syncing physics in multiplayer.

I just can't get it right, and I think its related to the physics.
It just lags horribly.

 

You don't 'sync' physics in multiplayer. You have one server or client calculating the physics simulation and the resulting transform results from those physics calculations are sent to all the other clients. If you're talking about destructible environments (i.e a wall collapses and crumbles), the only thing being sent to other clients should be the fact that the wall was hit at some point. The actual crumbling/destruction will be unique on each client.

What networking API are you using and how are you trying to synch the physics?

 

Is Box2D multithreaded... or at least running in a separate thread?

More to the point, would PhysX 3.3 have better performance than Box2D?

Curious as to thoughts on this.

 

Me too, actually.

 

Any possibility of expounding on the features of the new WheelCollider? New friction model? Mobile performance gains?

 

Please tell me you're at least going to make ControllerColliderHit a struct and give us the long-awaited "fill this List<> instead of instantiating a new array" method signatures for operations like OverlapSphere...

And if multi-threaded physics are performant and reliable enough it could greatly simplify code and enhance the what game mechanics are possible for anyone doing latency compensated multiplayer networking. That is, if we get a way to tell the physics engine when to step.

Edit: I'm assuming from the Physx release notes that continuous detection now works correctly at high speed... Can anyone confirm or deny this?

 

Will the current wheel collider be supported for legacy 4.0 projects? It's just that I'm using the wheel collider in my current project that won't be released before 5.0 is released. I've pre-ordered 5.0 and will be updating the project. Just wondering whether I should spend a lot of time refining the handling, or just wait for the new collider and refine that.

A cylinder collider would be nice btw

 

I honestly think keeping legacy stuff around between major versions isn't a very good idea. Two versions of physx? bloat anyone? It's probably better all round for sanity's sake to make developers choose to upgrade or not. If this means tweaking something, then it's lesser evil than bloat and bugs.

 

I'd like to echo this. I won't be upset about not having new features, but I'd be disappointed if reworking existing ones like this didn't make the cut.

 

Agreed.....as long as it is running fine tho

 

On the other hand, this can end up being a mess on its own because we often get features half-implemented, which means that major version updates would end up effectively crippled.

 

Then we've got good cause to really make a stink on the forums. But I don't think that's going to happen in this case because unlike shuriken or mecanim replacing legacy (with massively different feature sets), we're merely upgrading the same thing, and Unity's said they aim to keep the same functionality.

 

Plus, since it isn't going side by side with a similar existing system it'd actually make the engine unusable if it didn't work properly. Collision detection and resolution is pretty fundamental to an engine.

 

I'm fine with that. For me it's just a matter of refining the *feel* of the vehicle handling. If I know it's going to change, no matter how little, I'll just delay the refinement until after upgrading.

 

I do not like the physx Joint.
I need to add mass to make a joint stronger.
as consequence a rope can not be to much long because is to heavy.
or a hand must have a lot of mas in proportion to the body.
I wish a fix for this.
the mass do not must influence or affect the the joint strongness.

 

UT gimme PhysX v3.4 or go home
And v3.4 100% implemented; and I mean it.

 

What exactly is the issue with adding Apex Destruction?

 

Isn't Apex destruction only editor for fragmenting meshes? Or did i miss something?

 

It looks like you might be on about Physxlab where you set the deformation and "slicing", you still need to import it into the engine as an Apex physics actor / asset. Then you can control destructible parameters / fracture materials etc. like you can in UDK / UE3 and UE4..

 

Ah, tnx for clearing it up

 

I hope in unity 5 Physx integration are easily upgradable (not by end user, but by unity), so we can get updated Physx every unity updates

 

+10 , If they make the dot dot versions integrated asap, it shouldn't be something as big as from 2.8 to 3.3 and alot of changes, it will be only small changes from here to there, right?

 

Hi,

For basic functions, how much more efficient (in %) is 3.xx?

 

I'd like to 3rd, 4th, and 5th this lol. When I first started working with OverlapShere, I couldn't believe they actually made it instantiate a whole new array each time. I still can't believe they do this lol.

I also wanted to to be able to say, okay do a spherecheck, but only grab the first 3 or 4 nearest colliders you hit and not every single collider in the radius. Creating an array every time seems like they're trying to be performance unfriendly lol.

 

Is it possible know the first 4 nearest colliders in the first place, if you haven't checked all of them in the sphere?

 

But since the function creates an array every time no matter what, I wanted it to stop at 3 or 4. Not necessarily even the nearest colliders, just if the array is going to be created, only create an array of a small amount of slots, not a huge one.

Stuff like that. But you're right, Carpe Overall, I just want the physics checks to be as performant as possible. I don't care how it happens. But creating a new array every time doesn't seem optimal.

 

???

 

Look at this post and the ones following: http://www.codercorner.com/blog/?p=748

 

You say PhysX is a performance update and then proceed to say no Apex Destruction like if a built-in destruction system has nothing to do with performance.
Wouldn't look as bad if Unreal Engine didn't have it.

 

So that means we're only going to get a full PhysX 3.3 update in Unity 6?
What is the issue with doing a full update for 5 and why are there going to be no new features implemented, aside from the WheelCollider and Cloth updates?

This sounds like another half-baked implementation yet all the marketing is boasting a PhysX 3.3 upgrade.

 

For 5.0 it's wiser to have feature parity. Once everything is perfect, there's room to add new features to it. Adding new features to something as dangerous as an entire physics replacement isn't clever or smart. It's better they're aiming for feature parity (for 5.0 at least).

 

Hum... multi threaded support? Better veichle modules? Cool!

 

What, exactly, does multithreaded support mean here? Isn't the physics system already multithreaded behind the scenes? Is it going to be things such as allowing raycast from another thread or allowing procedural mesh collider creation from another thread? Or do I have the wrong idea?

 

the actual physic simulation run on only one core of the CPU. The rest of the game is multi threaded.
With the new physX 3.3 we have a multi threaded physic, better colliders, better cloth and better performance everywere.
To see how unity actualli uses only 1 core, open a scene, put in it 200 cubes with rigidbody and physic, then it play and let them collide, see the task managerand you will see the 1 core of the CPU go to 100% and the other cores to 20%.

 

[QUOTE=" Don't expect any significant feature changes in Unity 5.0 - we don't plan any additional features for 5.0. However, expect changes in behavior for the wheel collider and cloth components, as the underlying implementations have been rewritten from scratch. (Behavior for other physics components is also likely to change, but in a less drastic fashion).[/QUOTE]

Jonas:
Will Unity 5 integrate the "articulation" joints of PhysX 3.X ? If not, is there a plan to integrate it in Unity 6 ?

 

Even if it's worthy to update (say if there's a major improvement in new physx version)? Just curious

 

Interesting find on vehicle physics in Unity 5.0:

 

Good find!