I have a Unity scene working while another one throw the following error immediately when it is loaded.
-[MTLTextureDescriptorInternal validateWithDevice:]:1357: failed assertion `Texture Descriptor Validation
MTLTextureDescriptor has height (12288) greater than the maximum allowed size of 8192.
I do not have the same issue before upgrading to polySpatial 0.5.0
Thank you.
I’m surprised that you’re seeing this only now, but could this be a cube map or 3D texture? Because we emulate support for those by interpreting them as 2D textures, we’re limited as to how big they can be: for cube maps, the size * 6 can’t be more than 8192, and for 3D textures, the height * depth can’t be more than 8192. Since 12288 / 6 = 2048, it sounds like you might need to resize a cube map to 1024.
(I should say that I believe the simulator has a lower max height than the device, if you’re testing on that)
I saw the exact same crash with some 3D textures on our project. I’m not entirely clear on why PolySpatial would send these to RealityKit at all?
3D textures are not supported (yet?) and you can’t sample the converted 2D texture in any meaningful way without providing a custom conversion for the Sample Texture 3D node (and pass additional data about dimensions of the texture). Are you working on that?
Thank you. I think it may be related to the skybox setting in our scene but we cannot pinpoint the exact issue yet. For now, a quick and dirty way to temporarily work around it is by creating a new scene and copy all our game objects to it.
We support both cube maps and 3D textures in a limited sense by reinterpreting their data as 2D textures (with each 2D “slice” stacked vertically), then having implementations of the Sample Cubemap/Sample Texture 3D nodes that do the math to sample them (sometimes multiple times, for filtering). This is subject to the dimension restrictions I mentioned, though.
We shouldn’t be sending cubemaps or 3D textures if they aren’t used, but (for example) the default reflection probe might be a cube map, and we do send that.
Ok, just did a small test with a 3D texture. And it almost works, but the sampling is broken because it samples a mipmapped 2D texture without setting the LOD level explicitly. It was the same issue I had when the Texture2D LOD node was not supported.
Could it be that if a texture has been set previously as a property it will be passed to RealityKit, even if it isn’t used by the currently bound shader? We are not using 3D textures for visionOS, but rather our own converted 2D sliced textures, but the original 3D Texture is saved in the Tex Envs of the materials, even if the shader for visionOS does not use them.
I’ll post an incident/bug with the sampling issue…
Thanks; is it possible you’re not using the LOD Mip Sampling Mode setting? It’s in the Graph Inspector under Node Settings when you have the Sample Texture 3D node selected (which I realize is confusing, when all the other node settings are on the nodes themselves). Anyway, that’s what we use to determine whether or not to use the LOD texture sampling variant.
It shouldn’t be, unless it’s set as a material property on a frame update. I could certainly imagine a case where the material had a default texture for a frame or two before the script changed it. The only textures we send, though (apart from lighting-related ones like light maps and reflection probes), are either obtained from Material.GetTexture or the defaults associated with the texture property (Texture2D.white, Texture2D.black, etc.)
Yes, the 3D texture does not have mipmapping (so it shouldn’t be needed 
) But just testing now, setting this produces flipped coordinates, because you are still inverting the uv.y even when using the RealityKit Image nodes, so that’s actually worse…
There is an additional issue with color bleeding along edges of the 3D texture. It looks like it’s clamping to TextureSize.xyz instead of TextureSize.xyz-1.
The lines + edge bleeding issue are both reported here: IN-60606 - visionOS - ShaderGraph - Sample Texture 3D incorrect on device
