Unity 5 and Physx 3.3.0 details...

Yep - I can see the long term benefits but it requires pretty much a rewrite of Unity at this point, when a dll will solve the issue in the meantime. It's a good suggestion and probably one Unity's thought about many times. The UI for instance is open source.

And I'm still not sure it actually stops people from doing anything given there is dll support. It just means less bloat for those who would have to be capable of dealing with dlls to begin with, or at least that level of competence. In any case a good suggestion for Unity 6 or such.

 

Well they are working on it, at least in some parts, Unity 5 is a great step forward towards less cross-class dependencies.

 

I thought doing something like meshCollider.sharedMesh = otherMesh; would work on a background thread.

Apparently I misunderstood the 'fully multithreaded' thing!

 

thread safety is most likely the key here. If you need to change the item in a safe way set a temporary mesh reference to the new mesh, then have it update the mesh just before rendering (and set the temp to null).
You can't work around speed limitations this way though, as the 3D scene still needs to lock to allow updates to meshes and then recalculates everything it needs for efficiency. You can however offload the actual generation out of the locked state this way, possibly gaining huge performance benefits because it now does most of the heavy lifting elsewhere.

Threaded means that multiple things are working at the same time, not that you can willy nilly hop and skip cross threads without needing to lock the thread or part that you are editing first, or creating some kind of buffer that gets checked for changes.

 

If someone is interested in new wheelCollider - http://forum.unity3d.com/threads/unity-5-wheel-colliders.278088/

 

Yes, I know how threading "works", and yes, I'm quite new to it and so I still have a great deal of knowledge to gain when it comes to how to make it work most effectively.

One thing I definitely lack knowledge on is what Unity is doing behind the scenes in many cases, including with the Physics system... knowing this information would help me understand the multithreaded nature of it better. I'm not entirely sure where to learn this, though.

 

sorry to say this, but physx multithreading is bullsh*t.... 90% or more of calculations is done on main thread, and physx never uses more than 30% of cpu power( like it would be still limited to one thread ). So yeah, it uses other threads than main, but like once time on every few seconds.

 

Yes, im looking at new timeline profiler, and as I said sadly it very rarely uses other than main threads. Maybe physx using other threads only for some calculations?
Because I use lot of trigger kinematic rigidbodies(as field of views), so it's not typical usage of physx, just lot of collision tests( I am in this trigger ? ).
A little ot; I really appreciate engagement of Unity team on forums, it's really nice to see that developers DO care about typical users problems

 

The most iritating weakness of physx is the week precision of the joints.. I really hoped that the articuladed joint type would get implemented, the precision on that kind of joint is way higher..

 

Did you set solver iteration cout to 100? It is responsible for "strength" of physx joints.

 

Yes, it is just hard to get realistic movement on lets say a crane with robotic gripping mechanism in the tip.. Heavy rigid bodies and light ones in the same jointed crane... The tip then seems soft.. And not metal robotic like when you lift other heavy masses with it...

 

Does anyone have any performance comparison tests of 16 wheel colliders in a scene in Unity 4 compared to Unity 5 running on an iPhone 4?

I have 16 wheel colliders in my scene and iPhone 4 CPU performance is absolutely horrible with the physics.

 

oh my god that fire

eeeeeeeeeeeeeeeeeeeeee