Hi! I’m getting the following error:
-[MTLDebugDevice newBufferWithLength:options:]:699: failed assertion 'Buffer Validation Cannot create buffer of zero length.'
when running a visionOS project.
Here’s a screenshot:
I’m using Unity 6000.0.22f1 and PolySpatial 2.0.4.
There is also a warning:
Can't show file for stack frame : <DBGLLDBStackFrame: 0x3426ce8e0> - stackNumber:9 - name:PolySpatialRealityKit.MeshAsset.updateBaseBuffers(). The file path does not exist on the file system: /Users/bokken/build/output/unity/quantum/Packages/com.unity.polyspatial.visionos/Source~/PolySpatialRealityKit/PolySpatialRealityKit/MessageHandlers/PolySpatialImplMesh.swift
Please advise.
That’s to be expected; you don’t have the source for the native library that we include with PolySpatial.
In order for this code to be creating a zero-length buffer, it looks like you would either have to be submitting a mesh with blend shapes but zero vertices, or with blend shapes but no bone weights. That’s something we should be detecting and handling appropriately, so clearly there’s a bug on our side, and it would be great if you could submit a repro project as a bug report and let us know the incident number (IN-#####) so that we can track and investigate the issue.
A workaround would require the problematic mesh to have either A. no blend shapes, or B. at least one vertex (even if it doesn’t have any triangles) and at least one bone weight per vertex.
Thank you very much for the reply. Turns out that when I changed the App Mode to Metal Rendering with Compositor Services, it works.
I’m not sure what the consequences are of changing it from “RealityKit with PolySpatial” but it will have to do for now.
I hope that the bug will be fixed though.
Yeah, that uses a totally different path for rendering: it uses Unity’s own renderer (like all the other platforms), rather than synchronizing the scene graph to one represented in Apple’s RealityKit API (literally copying all the meshes, textures, materials, transforms, etc.). There’s a comparison of the different modes in the documentation here. Using Metal mode means you’ll get support for more Unity features, though there are a few things that you can’t do in Metal mode that you can in RealityKit: run multiple (bounded) apps at the same time, use gaze hover effects and interaction (versus, say, using the hands or head position), and dynamic foveation, off the top of my head. However, if you don’t need those features, then you’re likely better off with Metal mode.
Still, I will make a note to test the RealityKit blend shapes implementation with the edge cases I mentioned (empty meshes/no bone weights), and hopefully add a fix in the future.
Thank you for a thorough response. I’ll stick to Metal for now.
I have just one obstacle before I can finalize a port of my game for AVP, namely the support for XR Interaction Toolkit. I’d appreciate if you could take a look at the topic I created for this and maybe you could point me to a solution or you know someone who could do that: Near-Far and Ray Interactors don't work on XR Device Simulator and Apple Vision Pro
Thanks again!
Small update: I investigated this, reproduced it, and we’ll be including a fix in the next version.
Hello,
Just wondering if this was fixed. I am experiencing the same problem.
Thanks!
It should have been fixed in PolySpatial 2.1.2: “Fixed edge cases with blend shape support: support meshes with no vertices and meshes with no bone weights.”
If you’re still seeing it in more recent versions, please submit a bug report with a repro case (and let us know the incident number: IN-#####) so that we can investigate.
I have looked more into it and it seems a different issue. I don’t have the problem with Polyspatial 2.0.4. I will create a different thread for it.
