I have system when i am emitting and jointing circles so they are forming wobbly stream, but the limit on android is maximum 300 circles, after that the frame rate drops significantly. With use multi-treading on options i could emit more circles to have same frame rate but the physics behave completely different. The wobbliness completely stops and the stream is super stable (and not affected by gravity like in no multi-treading scene) which is bad in this scenario. Is it possible to fix this , so the result will be more consistent between multi-threaded and no multi-threaded versions?
Thanks a lot.
PS: I can even post sample scene but i dont know where
Is this with useConsistencySorting set to true? Do you get different results inside the editor or only on Android?
I’ll be honest though, I’d need to see a video comparison because it’s not clear what “wobbliness completely stops” means in real terms.
i tryed with use ConsistencySorting on and off but its not different. There is different behaviour between non multithreaded and multithreaded version. The joints are very strong or something…
1 Like
Is there any chance I could get this test project? It may be the default parameters for the island solver cost threshold. This limits how many items can be contained within a single island but I could find out exactly what the difference is.
Projects like these are gold while this is in the experimental state!
In the meantime, I would check the profiler to see how many islands are produced in MT and non-MT. From looking at it you’d mostly have 1 large island in non-MT but potentialyl lots in multithreaded.
A little explanation though might help. In theory, there are only two things that can change the behaviour in the MT solver:
- Not sorting contacts
- Limiting how large contact islands can be
Both of these can be controlled using those settings. To allow for more parallel processing, limiting island sizes is good because each island can be solved separately. Even a single island can perform solving across threads so it’s still possible to effectively remove the limit from those settings. Sorting can potentially take time and restores the determinism of the non-multithreaded code (although even that is not deterministic in all cases).
I can send it to you but can you give me some address, because i dont want to post it here. The difference is mostly in diferent behaviour of joints, with multithreading they are super stiff, but the gameplay would not work anymore in that case
A good way would be to send it attached to a bug report from the editor and send me the case number. That way we can both track it and any work can be done and reported against the case.
I just submitted it it is Case 1041509
Thaks a lot for helping
1 Like
Just to say that I can duplicate the issue here and will investigate shortly.
1 Like
Just a heads-up to say that I managed to narrow this down to a much simpler test with fewer joints which makes things much easier to isolate, especially as it’s multi-threaded too.
It’s most certainly an issue when calculating position constraints during iteration. I’ve yet to isolate which part yet though but closing in. I’ll keep you updated.
1 Like
Found the issue and have fixed it. Now the joints behave correctly.
I’ll issue the fix against your case and organise patches to 2018.2 & 2018.1
3 Likes
Thank you for providing a really useful reproduction case, certainly helped finding the issue which was annoyingly subtle.
2 Likes
Hi Melv i tryed new version (2018.2.5f1) where this bug is fixed, but when i build and run it on my android phone (samsung galaxy s6 edge) it will crash after unity logo screen, version without checked multitreading works fine
Hmm, that is very odd indeed given the changes. This doesn’t crash in the editor, only on the player? Does this happen with your original submitted test case? Only on Android?
In the editor everythink works without problem, when i run it on android it crash, you can try it with the original submitted test case, it is crushing also there on android. I didnot tryed different platforms so for now only android is bad
Should i make new bug report?
No need, I’ve scheduled to look at this in the morning using the old bug report however if you’d like another bug report to track this then go ahead and let me know the issue.
I can wait till tomorrow, if you will have same behaviour, please let me know. Thanks a lot
Hi Melv, did you experienced the crashing on android after multithreading was turned on?
