[Official] 5.0 - Feedback request for PhysX

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

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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?

 

Thats messed up for sure, 3ms for 200 colliders is ridiculous

 

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

 

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.

 

Bug report

 

Yes, this seriously!

 

This please:
https://developer.nvidia.com/content/new-flex-features

 

Or even a map slot to put in a grayscale map to determine what is dynamic and what follows parent object, great for hair.