[Official] 5.0 - Feedback request for PhysX

Who are you?
Shkarface Noori, Lead programmer at Kurdify Technologies,

What kind of game are you trying to build or would like to build?
Third-Person & First-Person shooter games.

How does Physics fit into that? What use-cases do you have?

• Collisions, rigid bodies.
• Mesh Destruction.

What are the GOOD things about Physics that you like?
It just works, and the new 3.3's performance is amazing.

What are the BAD things about Physics that you dislike?
It really bothers me that we don't have native bridges with the other built-in solutions [ex. Animator], and we don't have native support for APEX Destruction, it took us nearly 10 months to implement something like APEX destruction which of course was not accepted at the time of Unity 4 for the horrible performance, so APEX Destruction is a must have for our works.

How can we make it BETTER?

• More speed.
• Native implementations of other PhysX modules, for example APEX Destruction.

Do you like the Physics workflow?
Yes, but it could've been better.

How do you spend most of your time working with our Physics features? Anything bogging you down?
Not for now. i really like the 3.3 implementation.

When you learned to use our Physics, what stumped you or had a steep learning curve?
I've been using it for almost 5 years now, so the only thing I couldn't get around was the performance of the < 5 versions.

 

Who are you?
I'm Brian Chasalow, an artist and programmer, developer of Video Texture Pro 2.0 and Syphon for Unity and several other plugins- I am also one of the developers behind the Treachery of Sanctuary by Chris Milk, made in Unity. I develop interactive installations, iphone software, and live performances.

What kind of game are you trying to build or would like to build?
Without giving too much away, I'm working on an app that does procedural plant generation with Physics2D- basically dynamically adding/removing physics objects/branches at runtime.

How does Physics fit into that? What use-cases do you have?
Every time the plant grows, I add a new HingeJoint2D dynamically.

What are the GOOD things about Physics that you like?
Hmm...

What are the BAD things about Physics that you dislike?
1) hingejoint2D is fragile, and often the simulation breaks if I move the root object that the joints are connected to. The joint min/max rotation limits seem more like 'suggestions' than proper limits.
2) It would be nice if there were more options for joints in the 2D system. There are a lot of missing joint types that are available in 3d or in 3rd party packages.
3) A built-in 'rope' type of joint would be amazing. Currently I need to calculate a spline based on the joint positions of the hingejoint2d chain- but if there was a way to simply render a textured spline based on a physics rope joint... it would make everyone's lives easier.
4) When I dynamically add a new HingeJoint2D from code, i get basically a little bit of an 'explosion' happening for a couple frames as the joint is connected and moves/rotates into place within its limits. I can't for the life of me figure out how to 'pre-warm' the physics system to avoid this, or if this is a real bug, or what.

How can we make it BETTER?
Fix the above issues with HingeJoint2D- especially make a way for joint rotation limits to be truly limits.

Do you like the Physics workflow?
Yes and no. mass vs size vs gravity influence is finnicky and seems like I'm just making up values- some kind of standard reference for expected behavior when these things are changed would be helpful.

How do you spend most of your time working with our Physics features? Anything bogging you down?
working around the above issues

When you learned to use our Physics, what stumped you or had a steep learning curve?
Deciding which joints to use in the 2d system- they seem kind of limited, and HingeJoint2D was really the only feasible option.

 

Thanks for sharing this.. APEX destruction looks insane. I second this request

check it out: https://developer.nvidia.com/apex-destruction

 

Hello Erik!

My comments are for 5.0 physx 3.3.

www.simiansquared.com - we're making a game for PS4 and vita at the moment, with Sony's blessing.

We're building a complex mix of RPG and action game set in large world spaces with complex physics.

We just built a rigidbody character controller for full interaction. We have lengthy driving sections too so vehicle physics are important as well.

I like that performance is important to you. This is the most important thing to me, although having more features and performance is never a bad thing.

I absolutely loathe and detest the amateur hour garbage allocations with callbacks such as Character Collider Hit, and OnCollision...

OnCollisionStay is unusable in a real game, period. There is no point to it if you're doing any kind of number of interactions with multiple objects. Enter is bearable but still allocates far too much.

We really need to be able to remove the garbage allocations. If it means we can pass by ref, and it will fill the data "up to the length of what is passed" then all the better. We just want to avoid allocations at runtime. There really isn't any actual reason for spewing garbage out. Or let us tell physx how big it's pool should be and let it preallocate a fixed amount of data that it can work with.

In addition, setting up ragdolls or joints is a complete chore, and has a horrible workflow. It's very hard to see the joint limits, there's no nice pie charts showing angle limits and no real help for ragdolls except an out of date wizard that gives less than desirable results.

Make it faster. Make less garbage. Add proper visualization tools to joints for limits and to see clearly the angles it uses. Currently, its just not good enough joint-wise. It's poor to try to make complex behaviours, with lots of guesswork involved. Remove allocations, let us set pool sizes so that you may deal with callbacks up to pool size limits. Often, developers have the data. They know how much an object will collide, or only care about 2-3 collisions at a time. Being able to specify that to improve performance would be a possible improvement.

Yes, it's nice. Simple and easy to use, except for joints.

I spent 4 days replacing Unity's character controller with a rigidbody controller to avoid garbage allocations and bad performance.

Yes, in particular, setting up ragdolls and trying to visualize joints is amateur hour at best. It's a horrible workflow with very poor visualization and manipulation of joint parameters.

Final thoughts:

I think you need to document everything a bit more. We like to know as much as possible about the process. We also want better in-editor visualization of joints and limits. We want to clearly see visually, as the artist or designer sets it up. We above all prioritise performance. With physics, performance is everything, or you end up with not much physics, kind of defeating the point.

As a side note, I'm still not sure why unity's layers system is shared by the graphics and physics engine. This isn't a big deal at all really since one can abstract the meaning of each layer in code, I thought it was still worth a mention.

Thanks for asking and listening

 

Who are you?

My name is Kashif Riley, artist.

What kind of game are you trying to build or would like to build?

I am working on a fighting game with high detail characters

How does Physics fit into that? What use-cases do you have?

I am planning on using cloth simulation on characters with a great level of detail. I am also using rigid bodies to aid with dismemberment and environmental destruction.

What are the GOOD things about Physics that you like?
I like that the cloth is a bit easier to use this time and much easier to set up.

What are the BAD things about Physics that you dislike?

Currently for the cloth simulation, I don't like that even if I set the collider to continuous, the cloth doesn't recognize that it is there. I also don't like having to select vertices to determine what is fixed and what is dynamic.

How can we make it BETTER?

I would love to see a paint based setup, similar to painting weight maps for a character rig. It would much easier for me to paint on the cloth based object. Such as if I want cloth to simulate, I want to simplify this by painting on the model. I would love to see better self collision and more options to simulate a variety of materials.

Also, if I create a cloth component on an object, it should assign the mesh automatically... I don't like having to search for it.

Do you like the Physics workflow?

Yeah.

How do you spend most of your time working with our Physics features? Anything bogging you down?

Atm, for cloth, if I want to change something, I have to select vertices and sometimes they are hidden behind other objects such as straps.

When you learned to use our Physics, what stumped you or had a steep learning curve?

It took a while to get the hang of the physics, but I caught on quickly.

 

I developed a few games, of which Drei and Krautscape use Unity 3d physics. In newer project I often use 2d physics, but that seems to be not the topic here.

Simple games with a good game feel. Which means if physics is involved tweaking of it is a big part of the work.

Physics in my games are often very important in the gameplay, so it's important to have good control over the degree of freedom. It often only involves a few physical objects, so performance is not so important (of course it's nice if it is performant, so it works well on mobiles).

It just works, the default values make sense, the most important properties are easy to understand.

JOINTS! The simple ones work well, but for slightly more complex behaviour/constraints I have to use the configurable joint. Even after a lot of time wasted on it I still don't completely understand some of it's properties. Maybe it's also a documentation issue, but I think it would be great to have some more simple preconfigured joint setups.

Please display more information about what is happening. For example the joints could show the constraints, rigidbodies could show their applied forces, trajectories etc. Some of these things could be built with scripts of course, but I think it would be much easier to use if it was builtin. Documentation is also not very good, eg. for the wheel collider.

In general yes, but like I mentioned in the last point there should be more debug information, especially for joints.

A rewind/resimulate function would be nice, for example for networking physics, but also for gameplay it would be interesting.

And a thing that currently bothers me a bit, is the new implementation of the wheel collider in Unity 5, because it will probably make it impossible to upgrade my racing game Krautscape to this version. I was not a big fan of the old implementation and I waited a long time for a physx update in Unity 4, but after a lot of work & tuning I managed to make it work somehow. But now everything is broken completely and I have no idea how to recreate the old behaviour, I don't even know what exactly changed (except it is "better"). For this reason, it would be great to have the old one as legacy component next to the new one. Or at least good documentation on how the behaviour changed.

Easy to get started, hard to master all the details.

 

Who are you?

I am a programmer working on a tiny team of just two people.

What kind of game are you trying to build or would like to build?

I am working on a voxel-based sandbox game, where the focus is on the building experience for the player rather than on adventuring.

How does Physics fit into that? What use-cases do you have?

I have been relying on mesh colliders for chunks of procedurally generated terrain. For optimization, I only generate mesh colliders on the chunks directly surrounding the player, and not any others. (May consider use of greedy mesh algorithm in the future).

The player uses a character controller to collide with these mesh colliders.

Raycasting is used for block placement/deletion.

And I use trigger colliders to detect when new chunks should be loaded in the distance.

What are the GOOD things about Physics that you like?

It's very easy to use. Mesh colliders, though computationally expensive, are not hurting my frame rate at all.

What are the BAD things about Physics that you dislike?

My main problem is the inability to register a procedurally created mesh collider with Unity in a background thread. I'm referring to that part where I say:

meshCollider.sharedMesh = someMesh;

There's no reason, from my point of view (without understanding the internals of the engine), to require this on the main frame.

How can we make it BETTER?

Allow me to use meshCollider.sharedMesh = someMesh in a background thread, so that it can happen in parallel with the rest of the engine.

Do you like the Physics workflow?

Yes.

How do you spend most of your time working with our Physics features? Anything bogging you down?

Most of my use of the physics is through code, controlling mesh creation, assigning it as a collider, and activation/deactivation of colliders depending on where the player is moving. Additionally, controlling positioning of the trigger colliders which control chunk loading.

The only thing that has bogged me down was running into errors when trying to run some code in the background.

When you learned to use our Physics, what stumped you or had a steep learning curve?

I haven't had much of an issue so far.

 

I don't use Physics in any of my projects (does not support flight dynamics) but when I did, I ran into a major problem. That is that it doesn't support model sized car wheels. Maybe it is a floating point rounding error issue and I didn't try the Unity 5 Physics yet, but if this is still an issue, it needs to be addressed.

One Unity developer told me to scale the world. Don't forget to change the mass. Oh, and then change gravity as well. To make it all add up. And last but not least, change the scale and mass of all other objects in the scene to counter the different gravity parameters. Right...

 

I second and third that.

 

Who are you?

Edy, author of Edy's Vehicle Physics.

What kind of game are you trying to build or would like to build?

Fun and realistic vehicle simulations, either as development tools or as part of other projects.

How does Physics fit into that? What use-cases do you have?

Physics are essential for any kind of vehicle simulation. There are three main aspects:

1. Rigidbody dynamics: applying forces, managing collisions.
2. Suspension forces: this specific kind of damped spring forces are not trivial and they're important to be properly simulated.
3. Wheel and tire forces: 80-90% of the behavior of the vehicle depend on how good is the wheel and tire simulation. This is the most critical part.

What are the GOOD things about Physics that you like?

Rigidbody dynamics look wonderful in PhysX 3 (point 1 from the list above). The tests I've performed so far show that this aspect has been greatly improved. Now it's most precise and results are more predictable.

What are the BAD things about Physics that you dislike?

The Vehicle SDK in PhysX 3 is a nonsense, to say the least. It's based on a very questionable basis. In my opinion its design is plain wrong. It works as expected in the exact situations it has been designed and tested for, but in all other situations the result is barely predictable and prone to all sorts of unexpected issues.

With regards to the list above:

2. Suspension is horribly faked in PhysX 3. I've been managed to make it work properly by means of ugly hacks. It could work correctly by setting a specific PhysX configuration within Unity.
3. Tire forces don't make any sense, other that looking like they slide and push the vehicle allowing some "arcadish" gameplay. Other than that, any other behavior is far from being realistic. I've discarded using PhysX tire forces and I've implemented my own correct wheel and tire simulation.

I plan to write a post on my blog demonstrating my point by next week.

How can we make it BETTER?

I've repeatedly sent demonstrations, test cases, and proposed fixes to the persons involved. I can see several choices for improving the vehicle simulation capabilities in Unity:

• Exposing specific PhysX properties allowing third-party developers to provide serious vehicle physics as Asset Store packages (I've already sent the suggestions).
• Allowing the suspension system to work correctly by setting a specific configuration in PhysX vehicles (I've already reported the exact details). This would be a great help if Unity doesn't want to move further.
• Adopting my upcoming Vehicle Physics Pro package as the vehicle SDK in Unity instead of the PhysX 3 Vehicle SDK (in the same way as other tools like Substances and SpeedTree). Based on the actual state of the development I'm fully confident that my package will be a state-of-the-art vehicle simulation model at the same level of actual AAA vehicle simulation engines. I expect it to enter the beta stage next month.

Do you like the Physics workflow?

Yes. I only miss some physics debug tools, especially around joints and collisions.

How do you spend most of your time working with our Physics features? Anything bogging you down?

I spend most of time working with rigidbodies, forces, and collisions (physic materials). Making vehicles move, collide and behave realistically.

Anything bogging you down?
Having to do low-level hacking and debugging in order to overcome the awful design and limitations of PhysX 3 Vehicle SDK. I fear that the hacks I'm using right now might stop working in the future, leaving Unity 3D without the ability to provide users with serious vehicle physics for their projects.

When you learned to use our Physics, what stumped you or had a steep learning curve?

Learning to use and configure joints. This required experimentation, as many times it's not clear from the editor or from the docs how they will behave and to do specific things.

 

I just use the bare minimum of physics stuff (basic colliders, everything's kinematic), so answering most of the questions would probably be a little silly, especially since others probably have a better feel for what works great and what doesn't!

I will re-iterate this though:

I've had a similar experience here in that I found OnTriggerStay to be unusable, (which I'm assuming to be similar to OnCollisionStay, someone can correct me if I'm out of my mind here). To avoid it, I ended up using a list and having OnTriggerEnter/Exit handle those, which requires the additional work of null checking everything in the list in case something's removed without it triggering the OnTriggerExit (rare, but happens with the way I've got things set up). It feels like a bit too much framework to be setting up for something simple - I just want to know what's currently within a sphere, darn it!

Anyway, I too would like to see a way to reduce garbage allocations. Physics is one of the few areas in Unity where I struggled to minimize them.

If the pass-by-reference suggestion mentioned is possible (or anything, really), then great! It would be nice if that could be extended to Physics.OverlapSphere as well, since there are times that 4-5 lines of code to do that is preferable to attaching colliders, making lists, etc (quite a few more lines of code), all to avoid piles of extra GC allocs. As it stands, OverlapSphere every frame just generates too much garbage if there are a large number of objects which is a shame because it's beautifully simple otherwise.

Thanks!

 

the ability to raycast against visible geometry like you can in ue4 would be really nice. as well as more physics control. like passing an array of objects to be ignored. one way collision (only one object registering a collision while both are rigidbody's. really useful for larger physics simulated objects and small ones being cheaper). more controls and customization. as much as you can expose.

 

> Who are you?

A hobbyist how does a couple of pet projects for fun.

> What kind of game are you trying to build or would like to build?

I'm trying to design a foundation system for in-game building: houses, furniture, everything.


> How does Physics fit into that? What use-cases do you have?

Everything in this project relies on physics. All the building blocks are rigidbodies. They can either be combined into compound objects or interconnected with joints.

> What are the GOOD things about Physics that you like?

It works fine. I understand that game physics can't be physically ideal, and when I started I wasn't sure I could build something more or less stable, but then realized that my buildings collapse much less often than I expected Now I feel pretty optimistic about the project.

> What are the BAD things about Physics that you dislike?
> How can we make it BETTER?
> How do you spend most of your time working with our Physics features? Anything bogging you down?
> Do you like the Physics workflow?

1. I see no way to know whether a pair of arbitrary colliders intersect, other than placing both of them in given positions and waiting for OnCollision event which may or may not happen. Imagine, there are objects on the scene and you try to place a new one the way it won't intersect the existing objects.

I would be nice to have a basic method that would run narrow-phase collision detection between two arbitrary colliders with given positions and orientations, or something like bool CollisionCheck(rigidbody, position, rotation) that supported any type of colliders.

2. Rigidbody has the option to manually tweak its inertia tensor, but if you actually do that, you will never be able to make it automatically calculated again. It's frustrating then you add a new collider to a rigidbody, whose inertia tensor was a bit tweaked for some reason, and have no idea how to reset the value.

Two solutions: either to have a method that discards the manual tweak and recalculates the tensor automatically, or a method that calculates and returns the correct tensor value (what Physx thinks it should be), so I could apply it myself.

3. As was said already, joints really lack informative visualization. The current joint gizmos are barely visible and not informative at all.

4. Since all the physics activity should be made in FixedUpdate and user input depends on Update frequency, it's kind of tricky to properly apply forces, based on user input, on active rigidbodies.

Well, I don't know how to do it properly. Right now I just do everything in Update and run both Update and FixedUpdate at 60fps, but it doesn't solve the problem, it hides it.

 

Who are you?
I am the sole proprietor of 10101 Software.

What kind of game are you trying to build or would like to build?
A 3D, space-based RTS in the vein of the Homeworld series. Spaceships, asteroids, planets, starts, etc. There are NO static objects in my scene.

How does Physics fit into that? What use-cases do you have?
Everything moves using the physics system in my game. Everything is collide-able and movable. The AI needs to know how to use the physics system to move to locations or do do damage to targets.

Also, things break apart when they die which creates a bunch of extra colliders.

What are the GOOD things about Physics that you like?
I like the documentation and the flexibility. I really can do anything I want (up to a limit).

What are the BAD things about Physics that you dislike?
While 3.3 is certainty faster, it is still run on the CPU. That makes it perform badly on low-end systems for my game. This is probably just how it is going to be until CPUs get faster.

How can we make it BETTER?
Speed, speed, speed. I rely so heavily on the physics system that I can run into issues of scalability without trying very hard.

One, possibly unrelated item that I want is for Unity to fill a mesh with a user-configurable number collider primitives so I don't have to try to do that manually. Unity would determine the best fill for the primitives and make a compound collider.

Also, include a stone/rock Physic Material.

Do you like the Physics workflow?
Like I said above, it is a pain to use primitives in lumpy objects because it is hard to position them by eye.

How do you spend most of your time working with our Physcs features? Anything bogging you down?
Creating compound colliders is taking up the most time. Otherwise it is OK.

When you learned to use our Physics, what stumped you or had a steep learning curve?
Learning how to make forces simulate explosion effects on objects in the environment.

 

There is asset for this. Its called concave collider from what I remember.

 

EDIT : Never mind, I re-created the scene and project and the FPS was good.

 

Their physx in U5 is bugged, so it can have performance problems. But they don't want admit that. For now I'll just wait till they fix it. And I recommend it for others, too.

 

What makes you say it's 'bugged', any specific issues you've had yourself?

 

Yup, http://forum.unity3d.com/threads/physics-performance-bug-or-not.278892/

 

Who are you?
Maxime Charbonneau, main programmer on Kôna

What kind of game are you trying to build or would like to build?
A First-Person adventure game with controllable vehicles.

How does Physics fit into that? What use-cases do you have?
I use them primarily for the character controller and the vehicles (a pickup truck and a snowmobile).

What are the GOOD things about Physics that you like?
It's easy to use and quite fast now with PhysX 3.3.

What are the BAD things about Physics that you dislike?
Weird bugs happen now and then since Unity 5 beta, but I guess it's to be expected. Some weird things seems to be happening with the wheel colliders in particular, situation where the suspensions act in totally unrealistic ways, like weak springs overcoming springs order of magnitudes stronger. Those bugs seems to be hard to reproduce reliably. I guess it has something to do with how PhysX 3.3 works, but anyway, I decided to wait a bit, report some bugs, and if it doesn't settle down, I'll probably have to develop/buy a custom wheel collider.

How can we make it BETTER?
Finding a way to properly implement PhysX 3.3 vehicles. Also, ways to eliminate allocations for all Physics functionalities would be nice. I'm not sure how difficult that would be, but supporting things like Apex Destruction or Apex Particles for shuriken would be nice somewhere in 5.X.

Do you like the Physics workflow?
Yes.

How do you spend most of your time working with our Physics features? Anything bogging you down?
Well, I lost quite some time on getting consistent results with vehicles. Other than that it's fine.

When you learned to use our Physics, what stumped you or had a steep learning curve?
I didn't have much trouble to be honest, except for configurable joints. Its inspector is a bit of a mess.

 

Who are you?
Lead programmer at BattleByte Games.

What kind of game are you trying to build or would like to build?
1: Finished a tactical ballistics simulator using my own ballistics code.
2: Working on a RTS game. Since unity 2.5

How does Physics fit into that? What use-cases do you have?
Mostly vehicle physics also simple stuff like raycasting.

What are the GOOD things about Physics that you like?
Mostly works ok.

What are the BAD things about Physics that you dislike?
Wheelcolliders are limiting and a blackbox. Making WheelFrictionCurves polling able functions would help.

In order to calculate the turning radius of a vehicle, using a simple bicycle model for example, you need to know some values that are hard to find currently. Calculating turning radius of torque steer vehicles is actually easier but vehicles with steerable wheels are harder.

1: One you need to know be able to find the force value at an arbitrary slip value on a WheelFrictionCurve

2: You need to because to find the derivative (slope of the tangent line) at a point on the WheelFrictionCurve. You can get close to this just with polling.

I have for years been using linear approximations of the WheelFrictionCurve which work ok but it would be nice if 5.X had something better. Last time I checked WheelFrictionCurve did not allow polling.

Do you like the Physics workflow?
Yes

How do you spend most of your time working with our Physics features? Anything bogging you down?
Physics has a good foundation.

When you learned to use our Physics, what stumped you or had a steep learning curve?
Physics is fairly basic in video games.

 

One of my biggest gripes about the physics engine is the layer system. The fact that it’s shared between multiple systems is a bit of a problem, but the significant issue IMO is you choose a single layer per object, and not a mask. Essentially, I’ve always had physics implementations where the collision bits are bits, therefore they define properties, not types, and can thus combine properties. Currently, to have properties you have to create multiple types for each permutation you need to use, it’s very clunky in code and use.

For example, let’s say I’m doing a game where I have bullets that can go through some types of walls, and I have some types of walls that are shields some objects can pass through, and solid objects no dynamic object can pass through. So I’d have to have…
Walls bullet passthrough
Walls bullet stop
Shield bullet passthrough
Shield bullet stop

So I’ve burned 4 groups instead of 2… Add one more property and I’ve burned 8 instead of 3, add one more property and I literally can’t add anymore… scary.

The current non-Unity project I’m on uses filter bits in the way I’m accustomed to, uses it only for physics, and still ran out of bits. Now, it’s a large project, and I wouldn’t say all the bits that were used were smart decisions, but still, when you run out of those bits you’ve got some unfun code and likely data refactoring ahead of you, which sucks alot. Unity’s super barebones, shared layer system’s lack of scalability is scary.

I imagine the impetus for the current implementation is simplicity, but you could actually have both fairly easily I think, just add the ability to activate the layers as masks and store them as such, and when an object has only one bit set then it’d look like the current implementation.

The collision group system could be improved beyond what I've discussed here, but this would fix most of the problem IMO.

 

I can't Like RElam's post above enough.

"Unity’s super barebones, shared layer system’s lack of scalability is scary."

This, 1000x this.

 

Because, its sad true that ambitious devs are very minority. Most will do S***-mobile "games", so dont need things like this. Sorry for english.

 

Thanks for support Dan, and Roni, you are correct. It's a bit difficult, because for Unity devs, even if disregarding implementation time completely, they have to consider simplicity vs power, and you have to tread very carefully when sacrificing simplicity for power... very carefully (devs of all skill level and team sizes benefit from simplicity). In this case, I believe they can have both, there are ways to fix this so that the deeper system is totally opt-in, so it doesn't have to be any worse/different for the casual developer.

This just happens to be one of those areas where the simplicity actually makes things complicated in the real world for medium to large developers because the ways you have to work around it are effectively more complicated. Tricky stuff, engine development .

 

Who are you?

My name is Gabriel Burdeti, lead programmer at Allumage Studios.

What kind of game are you trying to build or would like to build?

We are making a game that has gravity in all directions (think Mario Galaxy).

How does Physics fit into that? What use-cases do you have?

We use AddForce calls on specific rigidbodies with gravity direction computed every fixed frame to simulate gravity in a planet's atmosphere. Because of this, we need to sleep rigidbodies ourselves. We compute the squared velocity of a rigidbody and compare it to the squared sleepVelocity set in the physics parameters.

What are the GOOD things about Physics that you like?

It is definitely faster.

What are the BAD things about Physics that you dislike?

When I create joints in my imported project from Unity 4, U5 goes haywire, results are unexpected. Also since we're not using the generic gravity, we need to sleep the rigid bodies ourselves. The new version only has sleepThreshold. I need the sleepVelocity to be able to sleep rigibodies.

How can we make it BETTER?

Please give us a function to get a rigidbody's current threshold so we can compare it with the sleepThreshold and make it sleep or give us a way to get the sleepVelocity and sleepAngularVelocity back.

Do you like the Physics workflow?

It's ok.

How do you spend most of your time working with our Physics features? Anything bogging you down?

It works fine most of the time. I had trouble making a simple pressure button with a spring joint, it never worked out the way we wanted. In the end I just did it by not using physics.

When you learned to use our Physics, what stumped you or had a steep learning curve?

Collision data is not ordered so I had to do some workarounds by iterating the contact points and finding the other/this colliders that were not part of the object getting the collision call. It wasn't hard but this is kind of like a trial and error thing. Also configurable joints parameters are not that simple to understand.

 

Who are you?

3d artist, designer, programming. solo dev. etc...

What kind of game are you trying to build or would like to build?

primarily PC. always wanted to make a 3d hack and slash, but i love making a wide range of games.

How does Physics fit into that? What use-cases do you have?

a strong physics framework makes many branches of games easier. as well as making existing games more stable. i mostly use raycasts and sweeps for my action games but i also use many physics elements for my characters.

What are the GOOD things about Physics that you like?

i love how exposed the API is. odds are that if you don't support something i can usually add or hack it in(not ideal but better than nothing and way better than most engines =3)

What are the BAD things about Physics that you dislike?

lack of features. layer system. lack of one way collision detection(one object hits another without the other reacting. really useful for having variance in the size of your physics objects. you don't want your giant space ship reacting to the people walking in the hanger). you currently have to attach 2 components to every object with physics. the rigidbody and the thing that drives it. while this sometimes makes sense in many cases it does not help very much. i almost always want to mess with physics and that means extra components.

How can we make it BETTER?

Add a function to allow one collider to ignore a whole layer(useful for custom collision setups without needing to create more layers, currently you can only ignore specific colliders which while awesome lacks generalization. eg: sometimes i want something to still be on the Actor layer but ignore collision with WorldDynamic layer).

Add a bool to raycast for raycast visible. this would perform an expensive visible mesh raycast. while expensive. its necessary for almost any shooter and helpful to almost any game. think about click detection, bullet tracing, etc... if you really wanted to be bad-asses you could actually add it to things like spherecasts as well(though i understand how hard that can be :3). currently to achieve this effect you have to have a bunch of mesh colliders in your scene.

Allow one way collision detection. so very, very useful. eg: Amnesia the dark descent used this to allow for really stable object stacks. you could stand on a chair, block a door, dump bottles on a chair, etc... they where all really stable! because the chair was never effected by anything hitting it except things that where set too. this allowed for things like barrels to block doors without the player being able to just slam the door a bunch or cause bugs. try playing with the physics in there sometime ;3.

Remove the really random default layer names(they just give me an eye-twitch. why is water considered important enough to be a built-in layer?).

More character related physics. bind mesh to cloth(low poly cloth with high poly clothing bound to it), chains(for ponytails and such), etc...

Finally i would like to be able to extend rigidbody/colliders. this way i could extend rigidbody for things like arcadey vehicle physics. much cleaner workflow in many instances. could create a custom character movement rigidbody type with special functions =3. honestly i would just like to be able to have a place to extend most unity components with custom logic. would be so useful for frameworking and would yield so much cleaner code.

Do you like the Physics workflow?

pretty good. biggest problems have more to do with prefabs than the physics system. it is a little barren. a lack of helper functions and features often leaves me having to develop my own solutions, or if i don't have time, just hacking around the problem (see above for details).

How do you spend most of your time working with our Physics features? Anything bogging you down?

most of my time is spent with designing character movement logic and the checks that come along with it. the main thing that seems to waste my time is

When you learned to use our Physics, what stumped you or had a steep learning curve?

IsKinematic. made no sense. took me a long time to realize it just makes it track velocity. use when you want something to track velocity while not being actually simulated by physics. not sure about renaming it as i'm a firm believer in using the correct name but maybe calling it something more descriptive and putting the isKinematic bit in the tooltip. id prolly have made it "VelocityOnly" but thats just me.

 

As usual mostly i agree what people posted already.

Request for PhysX :

- Better physX cloth authoring tool
- This is not directly physX related thought, so let me know if i shouldn't put it here, beside we didn't have a general Feedback/Request for unity 5.
WindZone and PhysX interaction, basically windzone affect physX object such as rigidbody, particle and cloth.
Also a WindZone volume would be a great addition, for example if we have a tight area that works as a windtunnel the wind strength would be bigger in that area/volume.
- Better character controller maybe, that basically a hybrid between rigidbody controller and character controller.
- Adopt PhysX Flex
- PhysX Destruction

 

I'd say integration of these Nvidia technologies would be great, as long as all platforms are supported. Maybe Unity and Nvidia could work together to get some of those things cross-platform? Eh?

 

imo NVidia's fleX could be the future...

 

Hey guys, does anyone know if cloth with work with box and mesh colliders in the final version of Unity 5? I was doing a cloth test and noticed that the cloth completely passed through a cube I was testing.

 

Only capsule and sphere collider only

 

that is weird... what happens if I have a character who falls on the ground plane and the cloth is simulating?

 

The cloth will pass through the ground plane.

 

And I don't want that happening

 

Well, you should ask unitydev about it

 

I think the feedback I want is to add more collider support for cloth. So far it is good, but I hope that they include brush based weight painting and self collision... if there is, I don't see it.

 

I have not tested Unity 5 but please bear with me.

I most physics engines you have a collision callback which unity has represented with OnCollision events
My questions
-Has Unity finally decided to provide us penetration depth in the Collision data structure? This feature is beyond important (I have inspected this class and it seems there were data unity had in mind to provide us through this and then decided not to).
-Does unity finally provide us a way to disable the original collision resolution?
When in most engines using a call back allows us to use custom resolution.


I am working on a project simular to Natural Motion and It is painful to have to raycast for penetration depth
Also painful to have to figure out ways to cancel out the resolution forces unity applies to the other object
(My object is a frozen rigid body and I wish to control it's resolution as well as the other "regular" rigidbody)

 

I'm I the only one who can't get the Cloth to collide with other Colliders, I know they deleted the interaction between Cloth and colliders but can't we select some colliders that the Cloth will react to?

 

Hello Eric and the Unity team! Here is my feedback as I'm currently working with a few Physics things right now in my game -- using Unity 5.0 beta 14.

Who are you?

I am an independent hobbyist developer that has been working with Unity for about 3 years now. I am working all by myself on an RTS game, and have been for over 2.5 years now.


What kind of game are you trying to build or would like to build?

I am currently building an RTS (real-time strategy) game (think Starcraft 2-ish or Command and Conquer-ish in nature).


How does Physics fit into that? What use-cases do you have?

All of my units/characters (and buildings) have colliders and rigidbodies attached. And my plan is for around 300 total units maximum in my game at any one time. My biggest physics "feature" however, is that certain structures will be "destructible". Currently, I have to pre-break the structure's mesh in a 3d modeling program, import it into Unity, and then attach mesh colliders and rigidbodies to those pieces of the mesh manually. Mesh colliders are a must on these structures in order to achieve a semi-realistic destruction simulation. So, I would love to see a "Fracturing" tool in Unity at some point as well (or destruction tool) to make this process much easier. But overall, performance matters a lot as well.


What are the GOOD things about Physics that you like?

So far, from what I've tested with my "destruction" system in Unity 5.0, the performance is much better compared to Unity 4.x. This is great! Now, when my structures begin to "destruct" and mesh colliders begin to collide, I no longer get a major framerate drop (that is obvious) when this begins to happen -- like I did in Unity 4. However, I've only tested this with one structure so far. But it already seems to be a big performance improvement, which is fantastic! Thank you.


What are the BAD things about Physics that you dislike?

It has some odd behaviors that took awhile to figure out -- I just came from working with it.

#1. Firstly, I had pieces of my structures set with rigidbody constraints to not move (both position and rotation were all checked to NOT move). Then, through code, I was quickly moving these pieces to a precise location, and allowing the pieces to react to physics by then "unchecking" the position and rotation on the rigidbody constraints (i.e. rigidbody constraints set to None). But then I noticed for some reason the rotation of the pieces was still acting as though it had rotation constraints still! So the structure fragments would fall, but not rotate. PM me if you want more information about this.

#2. I also noticed that when my "destructible" mesh pieces were falling, the mesh colliders on them were actually offset from the actual mesh piece itself (i.e. the mesh collider didn't line up properly with the mesh rendered object)! I found out that the pieces had to have a uniform scale! My pieces were of non-uniform scale, and for some reason this messed up the mesh colliders on them somehow? Once I set my parent GameObject to have a uniform scale, and the child objects under it to have the same uniform scale, then the mesh colliders lined up perfectly once again with the mesh! But I'd like to have a non-uniform scale on my fragments (and parent structure), and still have it work.

#3. I use long names for my "Layers" and the physics matrix in the settings is always too small, so a large portion of my layer names get cut off......just a little thing



How can we make it BETTER?

#1. Try to work on a robust "destruction" system that can be integrated with Unity. One where you can fracture the mesh, and have it react to physics (voronoi algorithms, etc).

#2. Continue to work on performance. The upgrade to the new PhysX version was excellent! I hope to see more like this. Of course, performance is always a big thing.



Do you like the Physics workflow?

Yes, it's pretty good. I don't really have much to say about it right now. It works pretty good.



How do you spend most of your time working with our Physics features? Anything bogging you down?

I spend most of my time adding colliders and rigidbodies to objects. The ability to multi-select game objects and add colliders or rigidbodies to all of them at once is a huge time saver -- although they ALL have to be exactly the same for mutli-object editing to work. Sometimes this is a pain if one of the objects has a slightly different setting.



When you learned to use our Physics, what stumped you or had a steep learning curve?

How the correlation between colliders and rigidbodies worked. I had no idea why a rigidbody was even needed honestly. Also, the way in which a parent object and child objects collider centers/transforms, and the actual game object's transforms worked was kind of odd (and still stumps me sometimes).


Thanks for wanting more feedback from your users! I hope you guys continue to do this.

 

I reported this bug and it has been fixed a couple of betas ago (b17, I guess).

I can't reproduce it. If you believe it's a bug and know how to reproduce it in the most recent beta, just file the bug report. According to my recent experience, there are good chances it will be fixed in a couple of weeks.

 

Good to know. Thanks alexzzz! Glad they fixed that.

Okay. When I upgrade to the latest beta I'll try to remember to see if that behavior is still there.

 

It would be very useful to implement raycast batching.

There are various circumstances where you want to shoot many rays in one frame and I believe that this would help a lot.

See here https://developer.nvidia.com/sites/default/files/akamai/physx/Manual/SceneQuery.html
for batched queries.

 

I noticed that in Unity5.0 with WheelColliders it's critical to set the Fixed Timestep to 0.02, maximum timestep allowed to 0.03333333 (probably lower will do as well) - otherwise you'll get a lot of jitter with the WheelColliders. This even with a simple car with a box+rigidbody + 4 WheelColliders.

 

I thought their new render engine was supposed to include a fast approximating ray tracer (and i thought it was also applicable in physics)

 

Is there any chance we could have more than 32 layers? (well really right now 24 custom ones). Is this a limit of Physx or Unity?

 

Personally, I'd like to see the whole tag/layer system overhauled.

1.) The current layer limit is fine because it allows a layer mask to be packed into a single 32-bit integer (as it most likely is, internally), but having to share layers between physics and rendering is kinda stupid. Those should be separated somehow.
2.) One tag per object is really limiting. It'd be nice to have a list of tags on an object.

 

Regarding step 1, I complained briefly about that but then realised, really it's not. It's only that in name and if we abstract it, they're not really shared for anything. The problem is the naming is shared plus the default entries.

With 2, this can also be abstracted with dictionary or whatever.... but I agree with the 2 points if only not much of a priority for me. Seems like hangovers from an earlier time.