Search Issue Tracker
Won't Fix
Votes
0
Found in
2019.3.0b1
2019.3.2f1
2020.1
2020.2
Issue ID
1224151
Regression
No
Editor crashes on Mesh::RecalculateSubmeshBoundsInternal when changing Submesh count
How to reproduce:
1. Open the user's attached "SubmeshBug.zip" project
2. Load the "SampleScene"
3. Select the "Mesh" GameObject in the Hierarchy window
4. Right-click on the "Bug" component in the Inspector window to open the context menu
5. Select "CRASH"
--Observe the crash
Reproducible with: 2019.3.0b1, 2019.3.4f1, 2020.1.0a26, 2020.2.0a2
Could not test with 2019.3.0a12 and earlier versions due to multiple compilation errors (e.g. "The type or namespace name 'SubMeshDescriptor' does not exist in the namespace 'UnityEngine.Rendering'")
Note: the crash is caused by line 43 in the "bug.cs" script
First lines of the stack trace:
0x00007FF6E8E92D62 (Unity) Mesh::RecalculateSubmeshBoundsInternal
0x00007FF6E8E9256A (Unity) Mesh::RecalculateBounds
0x00007FF6E8E98A89 (Unity) Mesh::SetSubMeshCount
0x00007FF6E973637E (Unity) Mesh_Set_Custom_PropSubMeshCount
0x000001D25D5A5649 (Mono JIT Code) (wrapper managed-to-native) UnityEngine.Mesh:set_subMeshCount (UnityEngine.Mesh,int)
<...>
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note (2020.2.X):
This is user error:
var m = GetComponent<MeshFilter>().sharedMesh;
if (m == null)
m = new Mesh();
Essentially this reuses old mesh structure and then "rebuilds" it step by step with new low-level api (SetVertexBufferParams, SetVertexBufferData, etc).
In doing so it has mesh in a weird intermediate state where some of the data does not (yet) make sense.
To fix this you need to tell unity that you are effectively creating mesh from scratch. The easiest would be to just always create new Mesh, but it is also possible to do
m.subMeshCount = 0;
before filling mesh anew (e.g. in the beginning of ApplyToMesh)