Problems upgrading project from SDK 1.3.4 to 2.2.0

RecFusion
1

Hello,

I am working with a project that previously used the SDK 1.3.4, the code is based on the RealSenseReconstruction, and we are working with a D435 camera. The example runs without any issue.

The only changes that I have noticed are related to the license handling and this particular part of the code:

1.3.4 Version:

		unsigned short* depthIn = (unsigned short*)depthFrame.get_data();
		unsigned short* depthOut = m_imgDepth->data();

		// Scale depth to 0.1 mm units
		for (int i = 0; i < m_imgDepth->width()*m_imgDepth->height(); ++i)
			depthOut[i] = (unsigned short)std::min((int)(m_depthScale*(float)depthIn[i]), 65535);

2.2.0 Version:

			unsigned short* depthIn = (unsigned short*)depthFrame.get_data();
			float* depthOut = m_imgDepth->data();

			for (int i = 0; i < m_imgDepth->width() * m_imgDepth->height(); ++i)
				depthOut[i] = (float)depthIn[i];

I don’t see any other relevant changes in the RealSenseReconstruction code of the two versions, however, the program exits when it reaches this line:

m_rec->addFrame(0, *m_imgDepth, *m_imgColor, &status, m_imgScene, 0, 0, &T);

The output log shows this:

2024-03-18 15:15:36.132	INFO 	Image recorder thread started
2024-03-18 15:15:36.459	ERROR	Couldn't write to OpenCL buffer (-4)
2024-03-18 15:15:36.459	ERROR	[SurfaceReconstruction] Couldn't update image mapping
2024-03-18 15:15:36.812	ERROR	[Core.Platform] ***** Encountered fatal exception: Access Violation, PID 25272 *****
 0# ImFusion::Platform::getLastWindowsErrorMessage in ImFusionCore
 1# ImFusion::Platform::getLastWindowsErrorMessage in ImFusionCore
 2# RtlDeleteAce in ntdll
 3# RtlRaiseException in ntdll
 4# KiUserExceptionDispatcher in ntdll
 5# cuGetExportTable in nvopencl64
 6# cuGetExportTable in nvopencl64
 7# clGetExportTable in nvopencl64
 8# clGetExportTable in nvopencl64
 9# cuGetExportTable in nvopencl64
10# clGetExportTable in nvopencl64
11# cuGetExportTable in nvopencl64
12# clGetExportTable in nvopencl64
13# clGetPlatformInfo in nvopencl64
14# clGetPlatformInfo in nvopencl64
15# clGetExtensionFunctionAddress in nvopencl64
16# clGetExtensionFunctionAddress in nvopencl64
17# clGetExtensionFunctionAddress in nvopencl64
18# clGetExtensionFunctionAddress in nvopencl64
19# clGetPlatformInfo in nvopencl64
20# ImFusion::ClImage::updateInternal in ImFusionLib
21# ImFusion::ClImage::update<float> in ImFusionLib
22# ImFusion::SurfaceReconstructionGPU::preprocess in ImFusionRGBD
23# ImFusion::SurfaceReconstructionGPU::addFrame in ImFusionRGBD
24# 0x00007FFF82FABB3C in RecFusionSDK
25# RecFusion::Reconstruction::addFrame in RecFusionSDK
26# RecFusionRealSenseUtility::processFrame at RecFusionRealSenseUtility.cpp:300
27# 0x00007FF7DDA23C77

What could be the problem?

2

This seems related to OpenCL and not to the usage of the SDK. Just to be sure, please double check that no libs and DLLs from the old SDK are used when building or running the code.
To resolve the OpenCL error, first check whether the Windows OpenCL compatibility pack is installed. If so, please uninstall it. If that doesn’t help, please install the latest driver for your GPU.

3

Just an update, it was a problem with the DLLs and I was eventually able to run the code.

But now I encountered another problem, it seems that on our previous code it was possible to apply the method fillHoles() to the generated mesh and afterwards work with the normal vectors associated to the mesh.
However, now after using fillHoles() the normal vectors become undefined (NaN), this is the case both in our code and in the sample provided by RecFusion.

Why is this happening?
Is there something than can be done to be able to apply fillHoles() and not lose the information of the normal vectors?

4

Unfortunately the fillHoles method does not compute normals. What you can do as a workaround is to call fillHoles, then extract the vertex, color and triangle information with the respective methods of the Mesh class and call Mesh::create with these. This will internally compute the normals.

5

Thanks, your advice works perfectly, but I obviously see an increase in the processing time.
I just want to confirm that this is the only way to obtain the normals, I would appreciate it if you have any other suggestion