Unity 5 and Physx 3.3.0 details...

Are you guys going to add force fields, I think tornados, box character collifers, rubber frogs, fluid simulation etc. thing is all old stuff that was added to physx from like 5 years ago that should be added to unity. It looks like after noida acquired physx they haven't added as nearly new features as before

 

No, it's designed to be comparable to 4.x physx. If in the future Unity expand it, it will be after 5.0 is out.

 

Could you add overlap tests? That would be my number one request and something that might be easy to do?
I'm desperately missing a simple and reliable way to check if one object is colliding with anything else if I place it somewhere. Having to use the OnCollision-events for that is really hacky and error-prone (for example because destroying an object doesn't trigger OnCollisionExit )

 

You can use this.

 

Then I hope they will implement it.
P.S. Since it is not planned we can post this idea in Unity Feedback

 

About the static colliders, I'm moving sliding doors that have a simple box collider in it. I move it by transform inside a coroutine, so I should avoid that for now, how of a bottleneck is having let's say 50 static colliders moving by transform?

 

In terms of physics, a "static" collider is any collider without a Rigidbody. It'd be nice if the documentation and/or interface (preferably both) made this clearer.

 

My the biggest question about physx is: are wheel colliders will be fixed in 5.0 ? I know they will be reworked, but I mean are they will be AT LAST fixed friction model, which now has NOTHING to do with reality, I mean doing racing game right now is pointless. And dont tell me about complicated solutions like carPro which are not much better, too.
Another big questions are: will it be really multithreaded, how faster will raycasts be and will we have possibility to change physx calculations make on GPU. Please, its really important. I know, multi platform and other androis-like compatibility bullsh*t, but PLEASE think about well equipped PCs too!
Now, time for some rant;
Why Unity must be cripple because of all that multiplatform bullsh*t. Im making game for high-end PCs and I completely dont care about stupid I-sh*ts and stupid android minigames and for now Unity is cripple, I can't really use all nowaday's PCs power, because of all that phones-compatibility sh*t.

 

Regarding performance: I tested 1000 falling cars (box collider, rigidbody, 4 wheels, 2 of them powered...) on my i5 laptop. The first two or three frames were lagging (all cars spawned at 0,0,0, at the same time), but then it got to 30fps.
U5 physics are much faster than U4.

Edit: the same test in U4 on the same machine could handle about 100.

 

On my project I have 150 tanks, every has got 22 wheelColliders, so yeah, numbers of rays are comparable.
From what you saying looks like its really much faster, so yeah, appreciate your input on that, thanks.
Wow, Unity is fast, they just posted vid about physx on YT , just like on demand^^

Hehe just kidding, but they really posted few very interesting vids on UT5, so yeah, I got occupancy for next few hours

 

Would you be willing to talk about memory management - such as having a NonAlloc character controller (controller hit callback) and similar things as Physics2D? I can see 3.3 will be very useful going forward for weaker devices too, given the performance enhancement.

 

Sorry if this was answered already, but will the physics be any faster on a next gen mobile device such as a Google Nexus 5 or an iPhone 5?

I'm making a mobile game at the moment, and I have to keep my time steps quite low or else the frame rate stutters when lots of cars are colliding.

or is the multi-threading improvements mainly seen on desktop PCs?

 

Sounds fantastic

It's great to know unity have the ball now and intend not to drop it!

 

I have a big question: cloth not exist anymore in unity 5, so there is the new skinned cloth, but it works only for player as far i know, how we can simulate cloths in unity 5?

 

Thank you Jonas for answering my questions and activity in this thread! Unity5 will be awesome. To be fully satisfied with physx in Unity we need only apex with destruction and turbulance effects

 

It's been said a few times that these extra nice additional features could possibly come in the 5.x cycle, but the initial release is aimed at fast, stable upgrade of the current physx system.

 

Greetings all, physx seems only a small part of all that is available. Any support for the full suite of goodness .

NVIDIA GameWorks™ Overview:

 

Unity needs to step up and give us PhysX 3.4.

I'm wondering why they went with 3.3 instead?

 

newest version of psyhics is 3.3.1 ; read - http://physxinfo.com/news/12283/physx-sdk-3-3-1-is-available/

 

My bad! A friend of mine said to me that it was already released, I guess I'm gonna have to kick his butt.

 

Just curious is the future physX in unity updateable??

 

Has there be any videos of the new character cloth system yet whatsoever? I've been really interested in it. I'd like to know if it's good enough to replace Shroud altogether.

 

That's interesting, and by updating of course not the user that doing the update but from Unity side.... thanks for the info

 

Seconded, I get that keeping the API identical to unity 4 is the primary goal for compatability and speeding release, but even adding a few more functions like these could mean a world of difference.

Overlaps
An overlap query searches a region enclosed by a specified shape for any overlapping objects in the scene. The region is specified as a transformed box, sphere, capsule or convex geometry.

Currently if you want to have an auto targeting turret, you have to do a lot of raycastings and angle checking to enforce certian rotational limitations. Far harder then it would be to create a mesh for physx to test once in a while.

I would like box and mesh for easier implementation.

 

Hey guys, it'd be awesome if you could keep discussions going in our new forum dedicated to the Unity 5.0 beta: http://forum.unity3d.com/forums/unity-5-pre-order-beta.72/

 

@SaraCecilia
Perhaps this post could be moved to the new subforum? As the topics covered still seem relevant?

 

Done

 

Man, sounds like the Webplayer compatibility is holding Unity back from upgrading to a lot of stuff

I mean I knew that going in, that Unity was for multiple platforms and so has to only implement tools that can work for everybody, but this means seriously lagging behind the competition in terms of desktops and beefy gaming consoles for the sake of being able to publish to "weaker" mediums.

I completely get why they do it. And they're the game engine of choice for such things, but I personally don't like the fact that desktop gets held back from extremely cool upgrades because of platforms like Webplayer and mobile I just don't like it at all.

Just wanted to rant about that. I will still continue to use Unity, but I see more and more where being the game engine for every platform has major drawbacks for specific platforms.

 

Could you explain why the web player should hold Unity back? It is usual for almost any software to break the compatibility only at well defined version steps, usually major ones, like the one to Unity 5. No one wrote that PhysX wasn't update just because of the web player. The main reason is clearly that a game that was fine tuned in Unity 4 and that is heavily relying on physics, will most likely need to be adjusted for Unity 5. Breaking the compatibility from Unity 4.1 to Unity 4.2 and again for the next one would be far more annoying in my opinion.

 

Jonas said:

I'm not saying it should. I don't want it to either. But Jonas said it DID. And was one of the main reasons why they didn't or couldn't.

 

I am sure you see the first point that Jonas mentioned as well. And from a Unity user's perspective that makes a lot of sense. Breaking compatibility would be extremely painful in many cases. Let's take the example that someone is working on a game and started it in Unity 4.0. At a certain point a bug in Unity is found that can hardly be overcome, but is already fixed in Unity 4.2 that was released meanwhile. But Unity decided to upgrade PhysX to a newer version and breaking to compatibility like that. That would be very frustrating and in my opinion a very bad move.
This is clearly the main reason that holds it back and that for a really good reason.

 

Either way we are getting it now.
Perhaps they can solve this by using the modules approach, want to keep using the 'old' physx? use that module

 

The consequence of such an idea would be that Unity would need to support several PhysX versions at once. That doesn't sound like a solution to me, as for the old version they still would need to provide bug fixes while preserving the backward compatibility and at the same time it would need to be possible to switch between the two versions. I don't think this would be a practical solution.
Further there would be consequences for any publisher in the asset store who has some kind of physics based asset.

Having a clear cut to break backward compatibility is in my opinion still better.

 

The support would actually be legacy support as that API is unlikely to change, priority could go to the latest and greatest version. Open sourcing PhysX modules would allow us more control and possibly community maintained versions.

They most likely would not add a module for the older PhysX api until much later if at all, but when they create a module for the current PhysX the next version could become a new module that brings the new bells and whistles, while keeping the legacy modules for developers that do want other new features but not the newer PhysX.

Different is not always better or worse, so far the PhysX api looks mostly identical to the old one, which saddens me a bit as I was hoping for more of the underlying api being exposed. Either way, I do truely believe that modules are an awesome way forward. They could allow us to pick and choose API versions and even remove unused elements from the games we ship decreasing the required size (Android and iOS builds are huge)

 

There is never a benefit to keeping older versions. It's better for the greater good that you adjust your code instead of asking the masses to have bloat and potential bugs. There is nothing good about 2.8 physx, in any shape or form vs 3.3.

And likely you won't need to adjust anything much. Plus wheel colliders are worth adjusting for - they're so much better.

3.3 is a lot faster too, which means you can have more impressive games. Why keep old? if you want old, ship on 4.x

 

For once, I agree with Hippo. It doesn't happen too often though.

 

Eventually everyone agrees with a hippo. It's hard not to if it's lumbering in your direction toward the water.

 

I still disagree

Modular design allows us to use the old stuff we need with the new stuff we need.
PhysX 3.3 will be surpassed by PhysX 4 in the future, so why not make sure we can go forward without needing to break everything for everyone.

Unity could use modules to allow new features on platforms that support them.
Developers could then easily see that if they need support for a specific subset of platforms, then they must rely on a subset of specific versions.

Module updates would naturally stop once a newer API version comes out, or at least slow down to critical issues only.
Best of both worlds.

I have no problem with Unity needing to break backwards compatibility with major version releases.
We always have access to the older builds.
But if unity just came as a Unity Core.
Consisting of the most basic items and the interface needed to load multiple modules (Physics, Audio, Networking, etc.).
Each module would contain all the stuff related to that subset, perhaps with some 'weak dependency' where additional micro modules are included if two modules can do something amazing together.
They could release specific updates sooner without the need to test EVERYTHING in Unity.
And once you have the modular design, you can use the older modules in case you need them to remain the same.

Yes updating is awesome and can certainly bring a lot of smiles, but sometimes it's just not practical to redo the entire project just because you needed a bugfix for something completely unrelated to why you should not upgrade a specific project.

For example:
On an existing project you want to add something using Feature A, which you were able to do before.
Feature A is suddenly not working as you expect (throws an error that you are adding too much and maybe even chrashes).

You could download a newer version of Unity (as this bug was fixed in a later version).
But this project also uses Feature B, which was replaced with a newer version that would require you to redo a lot of work (like manually alter script settings in 100 scenes).

In a modular design, you would only update the Feature A module and could just keep the other modules untouched.

Options, we all love em

 

It's not as simple as you make out. Physx is deeply embedded in multiple parts of Unity, not just the physics you see on the surface. So there's not a good way to make this modular.

Even if they solved this, many assets on asset store will have issues.
Also, Unity 5 with Physx 2.8 would break Unity 5 if they decide shuriken should use Physx 3.x for some things and so on...

I still do not know why on earth you would prefer 2.8. It's not sane to prefer 2.8 - but each to their own - for your needs you're welcome to add Physx with any kind of version you wish - by using a .dll

Regardless, Unity is modular where it can be, for example iOS or other larger components that can be updated at a different rate.

 

Sorry for getting a bit off topic here.

But I feel strongly that you disregard the idea before understanding the point of view I am trying to portray.
I do not want 2.8 PhysX, I never said I need it. And it is totally fine that upgrading requires some additional tweaking when relying on PhysX for game mechanics.

But the modular design still makes sense.
If they manage to wrap the new PhysX system into a separately update-able module, it would require much less testing.
At little to no additional cost, the NEXT major module version could either break, extend or change the API, users could then stay with one of the older modules for old projects. Still being able to take advantage of the beneficial changes other modules bring to the table. Sure it might not survive a Unity core revision, but when stripped clean of all the random modules this is much less likely to result in API breaking changes.

Just look at all the deprecated code, it is a mess. I would love it if all those functions were wrapped in a deprecated backwards compatibility module. Simple enough to add to the compilation process by using partial classes or extension methods.

If feature A uses stuff from feature B those dependencies can be added with smaller bridge modules that activate when all dependencies are met.

In your example if you disable particles, PhysX wouldn't care either way (to PhysX particles are just a point or maybe a simple collider), if you disable PhysX, particles would disable PhysX related components like world collisions.
Collision callbacks however would still be exposed, no use in blocking those (extracting the struct / class definitions for collision data is rather trivial).
If the users still wants something like simple planar collision, this would be easy to add without using PhysX .

Component, GameObjects and Transform should be the only things in the Unity Core. It's fine if the editor still has all the modules ready to go, but even there certain items could disable based on the activated modules.
Everything from input, audio, 2D ui, 3D graphics, PhysX, networking etc. might all be modularized at some point. Allowing for developers to create drop in replacements, getting access to more API as Unity itself would need all those hooks to function. For unity they could create teams that do everything related to a single module, making sure it runs on as much as possible, documenting / exampling the API and such.

Including my own version of a library already included, like FMOD or PhysX, always proved to be more trouble then it's worth. There is a lot we can do, but also so much we just don't have enough access or documentation for.

Assets on the Asset Store already have version related issues, as there is little to no version control or dependency checks built into the asset store. Just the 'minimum version required to download'. Locking out users that could use a plugin or giving them false hopes about compatibility. Perhaps they will hook up cloud builds to test the assets and display the warnings / errors next to the package when buying / downloading a asset to a specific version of unity.

 

Modular stuff is interesting, but I really struggle to imagine it happening during the 5.x cycle, and its certainly not the sort of thing they are suddenly going to pull off during the beta and subsequent release of 5.0.

And I have no trouble imagining that it would be hard enough for them to achieve that they would need to see a number of hugely compelling use cases that a large percentage of their user base were calling for in the strongest of terms, over a sustained period, before they would consider taking such a journey. Especially as there are downsides to the modular approach, such as the increased number of issues that will in practise occur due to the large increase in number of permutations and combinations of different bits of code working together.

I expect Unity will continue efforts to do things that optimise build size, especially with WebGL being the future of Unity in the browser, but I just don't expect to see the sort of modular Unity you are on about.

 

Thinking some more, I would guess the closest Unity will get to your modular approach is going to come down to what parts of the system they manage to include in their 'open source initiative' going forwards. And I don't think I see many indicators of how far such aspirations will stretch yet, even though its clear that there is some competition that may motivate them on this front.