Search Unity

Unity 5 and Physx 3.3.0 details...

Discussion in 'Unity 5 Pre-order Beta' started by web76, Mar 19, 2014.

  1. Aiursrage2k

    Aiursrage2k

    Joined:
    Nov 1, 2009
    Posts:
    4,794
    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
     
  2. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    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.
     
  3. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    I expect instancing of colliders to be significantly faster in Unity 5.0 - as well as moving static colliders, which has been a major performance pitfall (unknown to many) in Unity up until now.

    Not planned right now.
     
  4. Sebioff

    Sebioff

    Joined:
    Dec 22, 2013
    Posts:
    183
    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 o_O)
     
    Freezy likes this.
  5. Infernno

    Infernno

    Joined:
    Dec 15, 2012
    Posts:
    104
  6. Infernno

    Infernno

    Joined:
    Dec 15, 2012
    Posts:
    104
    Then I hope they will implement it.
    P.S. Since it is not planned we can post this idea in Unity Feedback :)
     
  7. Neurological

    Neurological

    Joined:
    Jun 25, 2012
    Posts:
    350
    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?
     
  8. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,030
    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.
     
  9. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    226
    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.
     
    Last edited: Aug 26, 2014
    vx4 likes this.
  10. Carpe-Denius

    Carpe-Denius

    Joined:
    May 17, 2013
    Posts:
    804
    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.
     
    Last edited: Aug 26, 2014
  11. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    226
    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 :D
     
    Last edited: Aug 26, 2014
  12. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    Yes, WheelColliders in 5.0 use a different friction model which is much better, IMO.

    Yes.

    Not sure about raycast performance. As for GPU physics, no, we will not have that in 5.0. I have seen impressive tech demos of GPU physics (running on super high end GPUs, of course), but, personally, I am not convinced that it GPU physics are widely useful in real life. Some problems are that you are competing for resources with the renderer (which is usually also resource hungry in games these days), many implementations are tied to specific hardware, and then usually, you don't get consistent results between GPU and CPU physics (ie, your game would play different on supported or unsupported GPUs). That said, it might still be worth to have this available as an option.
     
  13. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
  14. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    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.
     
  15. Gooseman_1977

    Gooseman_1977

    Joined:
    Aug 15, 2013
    Posts:
    89
    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?
     
  16. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    A reasonable request, but not planned right now, AFAIK.
     
  17. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    The Nexus 5 is quad core, and the iPhone 5 is dual-core, so both those devices should see a significant speedup from having multi-threaded physics.
     
  18. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    Sounds fantastic :)

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

    zRedCode

    Joined:
    Nov 11, 2013
    Posts:
    131
    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?
     
  20. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    The new cloth in Unity 5 is based on the old SkinnedCloth component. But we have made it possible to use it for more varied purposes, you can now use the SkinnedMeshRenderer and Cloth components to simulate cloth on an arbitrary mesh with no bone structure.
     
  21. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    226
    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 :)
     
  22. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    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.
     
  23. DingusAUS

    DingusAUS

    Joined:
    Dec 2, 2013
    Posts:
    9
    Greetings all, physx seems only a small part of all that is available. Any support for the full suite of goodness .

    NVIDIA GameWorks™ Overview:
     
    Nanako likes this.
  24. AwesomeX

    AwesomeX

    Joined:
    Sep 10, 2013
    Posts:
    109
    Unity needs to step up and give us PhysX 3.4.

    I'm wondering why they went with 3.3 instead?
     
  25. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    226
  26. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,536
    My guess would be "because PhysX 3.4 is not released yet"...
     
    Venryx and calmcarrots like this.
  27. AwesomeX

    AwesomeX

    Joined:
    Sep 10, 2013
    Posts:
    109
    My bad! A friend of mine said to me that it was already released, I guess I'm gonna have to kick his butt.
     
  28. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,372
    Just curious is the future physX in unity updateable??
     
  29. Zomby138

    Zomby138

    Joined:
    Nov 3, 2009
    Posts:
    652
    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.
     
  30. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    If you mean user-updateable, then, no.

    As for us updating PhysX: In the past, we have rarely updated PhysX. The biggest reason holding us back was backward compatibility:

    -Backward compatibility in terms of breaking existing projects as developers will need to re-tweak their setups. We are doing this for 5.0, because we believe that the benefits outweigh the cost for PhysX 3.3.

    -Backward compatibility for web player games. We cannot arbitrarily change behavior as that would break existing games running in the web player. However, 5.0 is a new runtime which will never be used to play older content, so here we can do it. But, with the direction things are moving in terms of web plugins being deprecated, I believe this won't be a problem we will have any more in the future, which should make it much easier to do PhysX updates - especially minor ones which would not have such a big impact on projects.
     
    hippocoder likes this.
  31. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,372
    That's interesting, and by updating of course not the user that doing the update but from Unity side.... thanks for the info :)
     
  32. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
    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.
     
  33. SaraCecilia

    SaraCecilia

    Joined:
    Jul 9, 2014
    Posts:
    675
  34. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
    @SaraCecilia
    Perhaps this post could be moved to the new subforum? As the topics covered still seem relevant?
     
  35. SaraCecilia

    SaraCecilia

    Joined:
    Jul 9, 2014
    Posts:
    675
    Done :)
     
    Freezy likes this.
  36. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,292
    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.
     
    shkar-noori likes this.
  37. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    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.
     
    Last edited: Oct 28, 2014
  38. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,292
    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.
     
  39. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    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.
     
  40. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
    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
     
  41. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    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.
     
    elbows likes this.
  42. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
    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)
     
  43. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    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 :)
     
    shkar-noori likes this.
  44. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,292

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

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    Eventually everyone agrees with a hippo. It's hard not to if it's lumbering in your direction toward the water.
     
    Venryx and Dantus like this.
  46. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
    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
     
  47. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    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.
     
  48. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
    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.
     
  49. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,302
    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.
     
  50. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,302
    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.