In Studio Play client tests, the first AssetService:CreateMeshPartAsync() call using newly generated static Content from CreateDataModelContentAsync consistently causes an approximately 20 ms main-thread stall, even for a mesh containing only two triangles.
Creating a MeshPart directly from the EditableMesh is much faster. Reusing the same static Content is also fast, but generating another static Content from identical geometry brings the first-use penalty back. Multiple first-use conversions can accumulate within a frame.
Reproduction in MeshCreationRepro.rbxlx (3.7 KB). After a 10-second startup delay, the script compares direct EditableMesh creation, first use of newly generated static Content, and reuse of that same Content. Results are displayed on-screen.
The reproduction uses two triangles, CollisionFidelity.Box, and RenderFidelity.Precise. Generated MeshParts remain unparented. It requires no uploaded assets, HTTP requests, or project-specific scripts.
Standalone results:
- Uninstrumented first-use calls: 19.568–21.440 ms.
- Uninstrumented reuse calls: 0.135–0.161 ms.
- A separate focused MicroProfiler capture contains all four first-use markers on RBX Main, lasting 20.450–21.379 ms.
- Maximum adjacent render intervals for those calls: 29.635–33.525 ms.
- No RenderStepped callbacks occurred during those calls.
The profiler markers wrap CreateMeshPartAsync itself. API elapsed time and adjacent frame intervals were recorded separately. Occasional unrelated long frames also occurred in direct controls; we are not attributing every frame spike to this API.
Earlier isolated benchmarks showed the same pattern across mesh sizes:
| Triangles | Direct EditableMesh | Fresh static Content | Reused static Content |
|---|---|---|---|
| 2 | 0.763 ms | 21.294 ms | 0.597 ms |
| 512 | 0.759 ms | 21.281 ms | 0.695 ms |
| 8,192 | 3.056 ms | 23.764 ms | 2.724 ms |
These are medians from eight direct/fresh trials and seven warm reuse trials. Geometry preparation was outside the timed calls.
Waiting up to one second after creating static Content, warming it through CreateEditableMeshAsync, and creating a direct MeshPart before freezing did not remove the penalty. Reusing the same Content remained fast after destroying its previous MeshPart.
Environment:
- Observed 20 September 2026, regression onset unknown.
- Studio 0.739.0.7390687.
- Windows 11 Pro, build 22631.
- Intel Core i7-10700K, 32 GB RAM.
- NVIDIA GeForce RTX 3070, driver 32.0.16.1088.
Testing limitations: Studio Play client only; standalone Roblox client and other devices have not been tested. Studio plugins were enabled and have not been independently ruled out. The engine-internal cause is unknown.
Related discussion:
Expected behavior
Converting a tiny, locally generated static mesh into a MeshPart should not introduce an approximately 20 ms fixed main-thread stall on first use. If preparation requires that time, the asynchronous operation should allow rendering to continue wherever possible.
A private message is associated with this bug report