HardwareBuffer mode is not stable when I build this project with Unity 6000.60f1 and deploy it to Oculus Quest 2
As per the Issue title. HardwareBuffer mode is not stable when this project is built with Unity 6000.0.60f1 and deployed to Oculus Quest 2.
I have also verified the apk built with Unity 6000.60f1 on two other Android devices, and it works without any problems.
For the time being, I'm going to recommend using ByteBuffer mode instead of HardwareBuffer mode when building this project with Unity 6000.60f1.
HardwareBuffer mode has performance advantages, and if possible, I would like to address this so that this project will run stably when built with Unity 6000.60f1.
However, since I do not know the cause of the instability, I first need to summarize the errors that occurred and the changes from Unity 2022 to Unity 6000.60f1.
Alternatively, if I'm stuck and don't know the cause, I'll consider starting a discussion about it in the forum or submitting an issue report.
The cause of the error seems to be that the commandBuffer was null.
The part where the error occurred.
Here 's the code that's been written.
void
RenderAPI_Vulkan::UpdateUnityTexture(long unityPlatformTexID, long platformTexID) {
UnityVulkanRecordingState recordingState{};
if (!m_UnityVulkan->CommandRecordingState(&recordingState,
kUnityVulkanGraphicsQueueAccess_DontCare)) {
return;
}
VulkanHWBImage hwbImage = m_VulkanImageMap[std::make_pair(platformTexID,
std::this_thread::get_id())];
// WARNING: vkCmdCopyImage is causing null reference errors In a project using Unity 6 and Oculus Quest 2 (VR app).
// A few seconds after the web page starts to display, a null reference error suddenly occurs. The cause of the
// error seems to be that the commandBuffer was null. This problem occurs in both scenes with only one WebView and
// scenes with multiple instances of WebView.
#if 0
if (recordingState.commandBuffer == nullptr) {
DEVLOGE("[sharedtex-jni] [UpdateUnityTexture] commandBuffer is null !");
return;
}
#endif
VkImageCopy copyRegion{};
copyRegion.srcSubresource = {VK_IMAGE_ASPECT_COLOR_BIT, 0, 0, 1};
copyRegion.srcOffset = {0, 0, 0};
copyRegion.dstSubresource = {VK_IMAGE_ASPECT_COLOR_BIT, 0, 0, 1};
copyRegion.dstOffset = {0, 0, 0};
copyRegion.extent = {hwbImage.width, hwbImage.height, 1};
vkCmdCopyImage(
recordingState.commandBuffer,
(VkImage) hwbImage.unityVulkanImage.image,
VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL,
(VkImage) unityPlatformTexID,
VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL,
1,
©Region);
}
long
RenderAPI_Vulkan::GetPlatformNativeTexture(long unityTexID) {
VkImageSubresource subResource{VK_IMAGE_ASPECT_COLOR_BIT, 0, 0};
UnityVulkanImage dstUnityImage{};
if (!m_UnityVulkan->AccessTexture(
(void *) unityTexID,
&subResource,
VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL,
VK_PIPELINE_STAGE_TRANSFER_BIT,
VK_ACCESS_TRANSFER_READ_BIT,
kUnityVulkanResourceAccess_PipelineBarrier,
&dstUnityImage)) {
DEVLOGD("[sharedtex-jni] filed to access texture");
return 0;
}
DEVLOGD("[sharedtex-jni] success to access texture");
return (long) dstUnityImage.image;
}
}
This is a problem on the native plugin side, so move the issue.
https://github.com/TLabAltoh/TLabWebViewPlugin/issues/2