14-09-2020, 01:25 PM
(This post was last modified: 14-09-2020, 01:25 PM by josemendez.)
Found the cause and fixed it, was indeed an omission in our job code.
Multiple jobs are scheduled when there are multiple actors in the scene, and they all write to different sections the same data arrays. For this reason,
the [NativeDisableContainerSafetyRestriction] attribute is used to mark the read/write arrays so that the job system knows we intend to write to the same array from different jobs.
I forgot to mark one of the arrays, so the job system rightly complains about concurrent writes to the same array -even if they're perfectly safe, as they do not write to the same indices-.
Not sure why Unity 2019 does not pick this up, but 2020 does. Replacing BurstShapeMatchingConstraintsBatch.cs with the attached one will fix the issue. You can find the file at Obi/Scripts/Common/Backends/Burst/Constraints/ShapeMatching/
Let me know if I can be of further help
.
Multiple jobs are scheduled when there are multiple actors in the scene, and they all write to different sections the same data arrays. For this reason,
the [NativeDisableContainerSafetyRestriction] attribute is used to mark the read/write arrays so that the job system knows we intend to write to the same array from different jobs.
I forgot to mark one of the arrays, so the job system rightly complains about concurrent writes to the same array -even if they're perfectly safe, as they do not write to the same indices-.
Not sure why Unity 2019 does not pick this up, but 2020 does. Replacing BurstShapeMatchingConstraintsBatch.cs with the attached one will fix the issue. You can find the file at Obi/Scripts/Common/Backends/Burst/Constraints/ShapeMatching/
Let me know if I can be of further help
.