Hello guys,
is possible to reach similar results http://www.youtube.com/watch?v=-DlPJpT5OQM with new unity cloth system?
Is there any good example or tutorial about unity cloth system?
Kenshin
Not at that detail level, cause a single processor / core just doesn’t have the power to pull that off while doing the rest of the calcs
Havok likely relies on the gpu and multiple cpu cores
There’s a simple example in the bootcamp demo and the docs, although sparse, should be enough to get you going. I ran some experiments and on my i5 with nVidia GTS 360 a 10x10 poly mesh was roughly the highest resolution mesh I could use and still get 60 - 100 fps.
Unity does neither support multithreaded physx nor does it use the precompiled dll to support hw acceleration, so thats unhappily not that much of a surprise 
What a pity… I was just thinking about precompiled dll.
Multithread is a very important feature for AAA games an visual simulations.
Is there any plan for add multithread in unity3D? and what about 64bit support?
+1 Even if the other platforms wouldn’t benefit from this, why don’t they just add this to the Windows builds?
using a precompiled DLL doesn’t get you anything, you can’t touch the mesh from outside unitys main thread so you will get the same hit again in the end …
and yeah multithreading for physics and networking would be well welcome and expected, I guess at latest when the ps3 / x360 versions appear we will have it as the engine would be laughed at and crushed to death if it runs as badly and single threaded on those consoles as it does at the time on windows which is hilarious for a 2010 released engine. even T3D was more parallel than that.
But I guess first the whole bugs in the async handling need to get fixed (for example if you disable “don’t run in background” on windows, the startup logic can go totally wrong if you click on something else while it loads and stuff like this. or the get thread context errors you get all the time when you are on pro and use async operations offered by default like loadasync or www) before threading is even tackled.
I personally expected that U3 would finally be significantly more solid on this end as already in 2.6 days no further single core cpus were sold and 2.6 with the introduction of async operations for standard stuff become rather instable for me.
I don’t know about you guys but I’ve got decent performance in a test similar to this. Obviously the better your hardware the better your performance; for all we know the havok test could have been done with the latest from intel/nvidia at the time.
I made a test with a mesh of similar detail to the one in the video (my computer has a 2.4ghz dual core processor) and the framerate hovered between 90-130 fps (90 when it was moving alot and 130 when it wasn’t moving much). Granted there wasn’t much else in the scene but then there wasn’t much in the Havok one either. The mesh was pretty detailed too, my dress had about 1176 tris which seems similar to the video. I’d say it was pretty good all things considered and lowering the poly count increased performance drastically. Lowering the tri count to 720 got between 160-200fps+. Tri count of 512 got 300fps+ but the deformations weren’t the best.
For all of them the framerates would gain between 20-40 fps when not touching another game object with a collider or when not moving at all.
Unity skinned cloth is only good for demos and showcase, not for a real game right now. It is hellish slow and the skinned cloth editor needs better vertex manip tools/features.
Also Unity PhysX version is outdated, at least more recent one versions are faster (provably 2-4x faster) with physics sim.
We are planning to develope a non-game application with unity and I am really interested to know if PhysX version improvement is already planned for future updates.
I will appreciate a lot an answer from somebody of the unity dev team.
Thanks in advance for any information.
The PhysX version used in unity is actually the more or less current one, not outdated (U3 updated to 2.8.3)
But they use the static library, so no hw acceleration (nor will that outside console ever happen due to the driver requirement and non-osx availability though this ever depends on NVIDIA finally getting an OpenCL version done instead of cuda)
PhysX 2.8.4 is twice faster on Sw than 2.8.3.
Actually, that is not quite correct. The Skinned cloth in Unity is simulated in separate PhysX simulations, and is fully multi-threaded to make use of multi-core machines. As for using NVidia’s dlls to take advantage of HW acceleration, we don’t do that at the moment - the main reason is that we have tons of custom bug fixes in our PhysX builds which are not in yet NVidia’s dlls.
Thank’s Jonas for your answer… now I understand the situation.
@Jonas - Any plans (for 3.x) to add multi-thread support for other PhysX functions (including interactive cloth)? It would seem that these need it just as much (or even more) than skinned cloth.
Honestly, it sounds like a mess. It would be nice if all this would be documented as well. This component is threaded, this isn’t, the reasons are due to, you know, just proper docs.
No. PhysX does not really support threading internally. The reason we could make it work for skinned cloth is because those are only driven by the animation, and do not need to interact with the rest of the physical world, so we could make it a separate simulation, which can run on a separate thread.
@taumel: this is at least hinted at on the SkinnedCloth reference:
Yes but it would be nice to have this kind of information for each component generally.
@jonas - Any chance that the interactive cloth API might be expanded during 3.x to include access to the cloth’s vertex positions, notification of a collision, or perhaps the ability to grab/control a vertex while running?
Whole heartedly agreed. I have to say, while I’m not doing any cloth sim at the moment, understanding these “little technical isses” is far too subjective at the moment. I’m not even looking for the why (as in your response above) just the what. I find myself doing trial and error work, when I should be (at least in my humble opinion) able to look up the deeper technical information to see what was done. I’m not looking for code here, just design/implementation details. The physics engine is (and always has been) at the heart of many of these issues for me (Mono implementation details and restrictions service much of the remainder 
).
Cheers,
Galen