iOS: failed Metal assertion + nothing rendered in nested Babylon view (race condition with contentScaleFactor?)

[jonklein]

For questions, please use the forum.

Describe the bug Under certain circumstances, with Babylon EngineView deeply nested in other views, I receive a sporadic failed Metal assertion and nothing renders:

-[MTLDebugRenderCommandEncoder setScissorRect:]:3635: failed assertion `Set Scissor Rect Validation
(rect.x(0) + rect.width(1125))(1125) must be <= render pass width(1080)
(rect.y(0) + rect.height(1020))(1020) must be <= render pass height(980)

To Reproduce Steps to reproduce the behavior:

1. Download and run the attached sample project 1) in release mode 2) on a device (tested with iPhone Mini 13)
2. Run 1) in release mode 2) on a device (tested with iPhone Mini 13) 3) with Metal assertions enabled
3. Inspect the logs for a failed "Set Scissor Rect Validation" error and observe that no model is rendered.
4. The issue is sporadic - if it does not occur, please repeat steps 2-3

Expected behavior Expected behavior is that the sample project reliably renders a 3D scene with no failed validation messages in the logs.

Other

• Platform: iOS

There appears to me a race condition of some sort regarding the value of contentScaleFactor in the MTKView. While tracing through to find the error, I added logging of the scale at + [BabylonNativeInterop updateView:] and see the contentScaleFactor is different on a failed run vs a successful run.

(Please note that the following logs indicate Babylon core v5.0.0-rc.4, but I have verified the issue is still occurring in the latest release)

On a successful run:

2022-04-01 12:28:02.881326-0400 guilds[86109:5309271] Metal API Validation Enabled
2022-04-01 12:28:02.885891-0400 guilds[86109:5309271] Scale = 2.880000
2022-04-01 12:28:30.640900-0400 guilds[86118:5309631] [javascript] BJS - [12:28:30]: Babylon Native (v5.0.0-rc.4) launched

On an unsuccessful run:

2022-04-01 12:28:30.629316-0400 guilds[86118:5309572] Metal API Validation Enabled
2022-04-01 12:28:30.634059-0400 guilds[86118:5309572] Scale = 3.000000
2022-04-01 12:28:30.640900-0400 guilds[86118:5309631] [javascript] BJS - [12:28:30]: Babylon Native (v5.0.0-rc.4) launched
-[MTLDebugRenderCommandEncoder setScissorRect:]:3635: failed assertion `Set Scissor Rect Validation
(rect.x(0) + rect.width(1125))(1125) must be <= render pass width(1080)
(rect.y(0) + rect.height(2436))(2436) must be <= render pass height(2340)

I am not able to determine what is causing a change in the window’s contentScaleFactor or why, but it appears that the value is changed and the dimensions are no longer correct in the Babylon renderer when it occurs.

If I introduce a 1000 ms delay in creating/rendering the Babylon native view, the content scale is always 2.88 and the problem disappears, thus suggesting a race condition with whatever mechanism causes the content scale factor change (which is likely external to Babylon).

I don't know that the contentScaleFactor change itself is a Babylon issue, but at the very least it seems that there should be some way of handling of this scenario. babylon-issue-sample.zip

[nmongiya]

I am running React Native 0.65 Project in Apple M1 Chip and trying to deploy in iPad Mini, I am getting the below error.

-[MTLDebugRenderCommandEncoder validateCommonDrawErrors:instanceCount:baseInstance:maxVertexID:]:5200: failed assertion `Draw Errors Validation
missing vertexDescriptor buffer binding at index 1.
'
dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/usr/lib/libMTLCapture.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib
-[MTLDebugRenderCommandEncoder validateCommonDrawErrors:instanceCount:baseInstance:maxVertexID:]:5200: failed assertion `Draw Errors Validation
missing vertexDescriptor buffer binding at index 1.

[osamamukhtar30]

Same error for me. Happening on iPhone 13 mini as well. However, couldn't solve it by adding a delay. Is any other fix available for it? @jonklein

[SergioRZMasson]

This bug was filed a long time ago, since them there were many changes to BRN that might have fixed it. We are closing it for now but it can be re-opened if someone is able to repro it again.