Search Unity

[Official] 5.0 - Feedback request for PhysX

Discussion in 'Unity 5 Pre-order Beta' started by Erik-Juhl, Dec 1, 2014.

  1. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    i agree that layers should be separated custom 24 layers for both is a bit 'meh'

    in addition tags system could be optimized and i would like to see multi tags as well see this ext from assets store https://www.assetstore.unity3d.com/en/#!/content/25715 this support multi tags and - suprise, suprise! - according to small test from author this is faster than builtin even if we compare grabbing objects with 1 tag (unity) versus 3 tags (extension) per obj. So there is definitely possible some optimization(s). Multi tag, as i think, could be really helpful for managing streaming in future...
     
    Last edited: Jan 29, 2015
  2. Issam

    Issam

    Joined:
    Dec 18, 2012
    Posts:
    37
    1) In our case 32 is limiting just because of how our game works. Unless it's a limit of Physx I just don't see why it's there anymore. Also, why can't objects have multiple layers if we are limited to 32? Especially since layers are used for triggers and not just physics collisions.

    2) I agree.
     
  3. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    Yeah, actually, it'd be great if a game object's layer wasn't just a single layer and was a layer mask instead. Would be immensely useful.
     
  4. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    Definitely not a limit of PhysX, even 32 bits is not the limit (they now allow 128 bits per shape), although I think 32 is the best choice, that's a bit of a longer discussion. IMO, you should be able to supply a profile, which defines one or more of the groups you are in, as well as one or more of the groups that profile interacts with. When the two objects agree on the interaction (ObjectAGroup&ObjectBFilter && ObjectAFilter&ObjectBGroup), the two objects hit. The filtering/profile is also useful for casts. In the end, this is certainly more complex to setup profiles, but less complex than the hackery or poor organization spawned from the current system, and could hidden behind 'advanced collision' if you want current system to become a basic collision system.
     
  5. Issam

    Issam

    Joined:
    Dec 18, 2012
    Posts:
    37
    I think we agree here. I need more than 32 because of the way things work now, but I would prefer a better way for it to work over just bumping the number. I guess it's mainly a question of what's the easiest/quickest thing to do first from Unity side.
     
  6. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    Ehh, I'd disagree there, they've already done quick and easy, and it's limiting and weak. When it comes to infrastructure, I want solid infrastructure, and it takes the time it takes, how long it takes to implement should be of low concern. Take the new UI, they took a really long time to do it, but they also absolutely nailed it, IMO. It was lame waiting for it, but I also don't feel like it's limiting, it's very liberating and thus far I've rebuilt all my major UIs and have had no fear of being blocked by the tech, nor do I feel like it's forced me to build data/code in undesirable ways just to work around poor design decisions in it. That's what I want to see out of physics, and if it takes them years... I'd hate it, but I'd prefer that.

    That said, none of these solutions should take very long.
     
    Last edited: Feb 2, 2015
    Cynicat likes this.
  7. Nemox

    Nemox

    Joined:
    Feb 16, 2010
    Posts:
    396
    I have only one significant issue with Unity's physics. I haven't been able to try the beta yet, so I don't know if this is still an issue or not, but here it is:



    Basically, sphere and capsule colliders are all kinds of messed up on terrain. One time I even tested this with a rolling ball, and it actually gained momentum while going uphill.
     
  8. Panzerhandschuh

    Panzerhandschuh

    Joined:
    Dec 4, 2012
    Posts:
    15
    I would love to see a function similar to rigidbody.SweepTest() for manual discrete collision detection. SweepTest() is great since it can be applied multiple times on a single frame which is necessary to resolve cases when a fast moving object is about to collide with a corner or curved wall. Also, I perform rendering manually with camera.Render() on FixedUpdate to sync input and physics with rendering. OnCollisionEnter/Stay are called immediately after FixedUpdate though, making it so collision response is not applied before rendering a frame. Something like "bool rigidbody.OverlapTest(out Collision collision)" would be good.
     
    Last edited: Feb 12, 2015
  9. sqallpl

    sqallpl

    Joined:
    Oct 22, 2013
    Posts:
    226
    I'm doing some tests with triggers.

    I have about 100 sphere colliders set as triggers and about 100 small spheres set as triggers with kinematic rigidbodies. The small spheres with rigidbodies are inside the big 100 sphere colliders/triggers.

    Everything works fine, trigger enter and trigger events are working.

    The weird thing is that I'm getting profiler peaks for Physics.ProcessReports -> Physics.TriggerStays. It shows 3-10ms every 3-5 frames in the profiler. It depends on the number of objects.

    Even when I don't have any scripts active it looks like that. Is it normal?
    profie34434.jpg
     
    Last edited: Feb 9, 2015
  10. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    226
    Thats messed up for sure, 3ms for 200 colliders is ridiculous
     
  11. sqallpl

    sqallpl

    Joined:
    Oct 22, 2013
    Posts:
    226
    @Roni92

    Everythingis fine until I move the spheres with rigidbodies into the spheres without rigidbodies. The peaks in profiler are only visible when XXX colliders are inside other XXX colliders.

    I've also noticed that the performance is very different in editor and in the build. After adding more small colliders with rigidbodies (1000 actually) and placing them inside 100 triggers I'm getting like 300ms-400ms every frame in editor, while it's about 3-5ms in the build with same scene. Most of the 300-400ms is used by 'Physics.ProcessReports -> Physics.TriggerStays.' in the profiler.
     
  12. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    226
    And btw, physx vehicle SDK have much more than wheel collider, why not to implement/exposure those in Unity, too? I mean simulation of differentials, gearbox, clutch, engine(!) etc...
    Its lot of work and its not easy to implement such things by scripts.
     
    Last edited: Feb 11, 2015
    sluice and DanSuperGP like this.
  13. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,485
    Bug report :)
     
  14. DanSuperGP

    DanSuperGP

    Joined:
    Apr 7, 2013
    Posts:
    383
    Yes, this seriously!
     
  15. Freezy

    Freezy

    Joined:
    Jul 15, 2012
    Posts:
    232
  16. Licarell

    Licarell

    Joined:
    Sep 5, 2012
    Posts:
    434
    Or even a map slot to put in a grayscale map to determine what is dynamic and what follows parent object, great for hair.
     
    KRGraphics likes this.