Hi,
I have found a major discrepancy between build vs editor when using the Buoyancy2D Effector.
This is how deep the branch is in the editor:
This is how deep it is in a build (iPad Pro 2018):
Here is the branch’s settings:
Here is the buoyancy settings:
Is there any known issue as to why the physics would be different in a build compared to the editor? Will this happen per device?
If this is not a bug, how do you get a consistent buoyancy between different devices?
Thanks!
I have to write a reply to put another image in (I am at my max of 5)
I put the same buoyancy and branch in a new project and this is where it sits. I checked my physics2D settings and they are the exact same between projects.
The only difference I can tell is that my real project, of course, loads into the game MUCH slower than this new project. Would this somehow affect the physics calculations?
Nothing that I know of would change it. It’s the same cross-platform code, nothing specific for any platform. Only difference can be small float differences but that shouldn’t make much difference here. The only thing that could potentially change it is physics running at different rates so I presume this is standard fixed-update physics at the same rate. I’d say make sure the actual polygons produced are identical maybe; at least the count of them.
It definitely is the same object as I copied the meta data file to the new project. I will just chalk this up to slow editor start.
I will just adjust the numbers and built until it looks right, thanks for verifying it!
That’s not what I meant. I mean is it producing the same polygons on both builds. The auto-mass and rotational inertia should be identical too which is a nice way to check along with the obvious shape count. All these are properties you can debug.log
My bad! Yes, it is the same. 
So same mass, inertia, shape-count etc. That is curiously odd. Do you get the same level in the editor if this is dropped from different heights because you should; it seems you were hinting at this maybe being the case because of the different start-up times; not sure.
I presume you’re not performing manual simulation because if it’s fixed it can’t make any difference.
Another thing to try would be a box or circle to check if they are the same.
Would be nice to get to the bottom of it.
I am not doing anything special or changed anything from the default settings.
I added a box collider and it worked!
I spent about 45min removing everything from the scene expect the branch and building. Somehow, it started working where the built/editor was the same when I added everything back to where I started.
The whole situation has been very weird. I am sorry I cannot find the source. I will post back if it happens again and try to get a reproducible build.
Thanks for your time.
Most important thing is you’re moving forward again!
Good luck.
I think I have a reproducible project!
This is what I am using:
I just uploaded the simple project here (deleted the library folder). I don’t know if it will be reproducible on your end that is why I didn’t just bug report.
(Or should I just bug report?).
How to reproduce:
This is how it should look below the water line.
Thanks!
7481933–920240–Water Glitch copy.zip (3.15 MB)
@MelvMay Just curious if you had a chance to peek at the project?
Thanks :)!
Sorry I’ve not. I’ve had a little time off and I’m pretty busy right now.
No problem! Just wanted to make sure it didn’t get lost in the ether 
I decided just to report the bug since you are busy. Don’t worry about looking into it!
So I took at look at your bug report but the report itself simply shows that there’s a difference between threaded and multithreaded but also, in the project, “use consistency sorting” is off so it’s not guaranteed to be the same. The thing is, the specified test object has a density of 2, the same as the buoyancy fluid so it’s neutral density.
Your original post above mentioned that it was different between build/player.
Could you try it with consistency sorting on and let me know if that becomes consistent for you?
Whilst this is the way to go to keep things consistent between threaded/non-threaded, it’s not clear if this is the source of your issue. I am surprised it causes this kind of difference because consistency sorted just keeps contact order processing the same which shouldn’t affect this because the floating dynamic bodies are not in direct contact with each other.
Worked like a charm!
I thought it had something to do with the sprite shape collider. As you saw, keeping the triangle area GameObject parent enabled causes the issue to happen but it goes away when disabled.
Final Verdict:
Should I keep consistency sorting enabled (even though from the docs it says increases performance cost) or is this a bug that is going to be fixed?
Or is the issue the sprite shape collider somehow effecting it?
Thanks!
No, renderers have nothing to do with physics so whilst a SpriteShape might modify a Collider shape, it doesn’t own it nor is there anything special under the hood going on; it changes the Collider in no different a way than an external user would; it uses the same public API you use, as does anything else in Unity that modifies a Collider or uses physics. Physics itself is the only thing that has special access as it’s in an isolated module.
It’s not likely to be that much and more likely you’ll not see any difference at all. I will say though that this was not even going to be an option when I wrote the multithreaded solver (it was to be a mandatory step) but last minute I decided to add it. I thought that for users who have a LOT of contacts, it might give a small bit of performance back. Honestly, I wouldn’t worry about it. In the end, it means a copy of the contacts into a single array then a sort. This might have an impact if your contacts were in the 10s of thousands or on a very low end device but at the same time, solving that many contacts on a low-end device would be prohibitive too. In the end, the profiler will show you but I suspect you’ll not see any difference and it’ll be a worry over nothing.
FYI: When on, the profiler entry “Physics2D.SynchronizeFixturesCombineSortJob” is used to capture time spent doing this portion so you can see how much time you loose. This is all under the profiler entry “gPhysics2D_SynchronizeFixturesMove” which is the total time taken (even if consistency sorting is off) so look at the difference of this if you do care about it.
In summary, I am continuing to look at this case though. I find it very odd indeed that it affects it this way. You won’t see this if you use an imbalance of density i.e. it sinks or floats. In this very specific case it’s a neutral density so the net forces are zero when its just submerged below the surface and/or when the drag stops it. It could be a sign that something subtle in the MT solver has a minor problem but it’s not the easiest to investigate. Nevertheless, that’s what I’m doing so you’ll see the results in the case you reported.
I just realized that the multithreaded is experimental. I don’t know why I have it ticked. I might just untick it? I don’t know if that would make a big difference or not.
Awesome, thanks!
We’ll be removing that “Experimental” label soon; it’s not on by default though. It is safe to use it but potentially you won’t get an advantage until you scale up what the physics is doing.
I wanted to provide you with an update on this case. It’s been super difficult narrowing down what’s going on here and so I’ve been looking at it on and off. Today I found the culprit which was really obscure and actually not easy to explain so I won’t go into any detail.
I will say however that yes, this is a subtle physics bug due to how multithreading can miss multiple contact pairs so they end up, in this case, being processed multiple times (hence the over buoyancy) and that using consistency sorting bypasses this issue completely.
The second is that I have fixed the issue and will be pushing the fix today and should you wish you’ll be able to track the fix landing, it’s here.
Thanks for the report.
