Potential bug in convex_decomp_util/GetPolyOcta3DNew

[PetrHrncir]

Hi, I encountered a bug when using GetPolyOcta3DNew in convex_decomp_util. The function creates a polyhedron that goes directly through the obstacle, as seen in the image below:

When looking through the code, I noticed a difference in how the corners are computed between the old and new algorithms:

GetPolyOcta3D:

multi_agent_pkgs/convex_decomp_util/src/convex_decomp.cpp

Lines 220 to 232 in d677442

	corner.position =
	Vec3f(borders_2d_real[j].front()(0) * res_arg -
	increments_i(0) * res_arg / 2 +
	increments[adj_faces[idx](j)](0) * res_arg / 2 +
	res_arg / 2,
	borders_2d_real[j].front()(1) * res_arg -
	increments_i(1) * res_arg / 2 +
	increments[adj_faces[idx](j)](1) * res_arg / 2 +
	res_arg / 2,
	borders_2d_real[j].front()(2) * res_arg -
	increments_i(2) * res_arg / 2 +
	increments[adj_faces[idx](j)](2) * res_arg / 2 +
	res_arg / 2);

GetPolyOcta3DNew:

multi_agent_pkgs/convex_decomp_util/src/convex_decomp.cpp

Lines 828 to 840 in d677442

	corner.position =
	Vec3f(borders_2d_real[j].front()(0) * res_arg -
	increments_i(0) * res_arg / 2 +
	increments[adj_faces[idx](j)](0) * res_arg / 2 +
	res_arg / 2 + res_arg / 2,
	borders_2d_real[j].front()(1) * res_arg -
	increments_i(1) * res_arg / 2 +
	increments[adj_faces[idx](j)](1) * res_arg / 2 +
	res_arg / 2 + res_arg / 2,
	borders_2d_real[j].front()(2) * res_arg -
	increments_i(2) * res_arg / 2 +
	increments[adj_faces[idx](j)](2) * res_arg / 2 +
	res_arg / 2 + res_arg / 2);

There are res_arg/2 twice and if I remove the second res_arg/2 the problem is fix.

I wanted to ask if you can confirm this is indeed a bug and that removing the second res_arg/2 is the correct fix? Or is there a specific reason for that second offset in the new algorithm, meaning the visual bug is caused by something else?
The image suggests that the second res_arg/2 caused the problem.

Also I want to ask on this section:

multi_agent_pkgs/convex_decomp_util/src/convex_decomp.cpp

Lines 690 to 695 in d677442

	for (int j = 0; j < int(borders_i.size()); j++) {
	Vec3i cell_tmp = borders_i[j] + increments_i;
	if (cell_tmp(0) >= 1 && cell_tmp(1) >= 1 && cell_tmp(2) >= 1 &&
	cell_tmp(0) < dim_3D(0) && cell_tmp(1) < dim_3D(1) &&
	cell_tmp(2) < dim_3D(2)) {

Why does checking the voxel grid start from index 1, skipping index 0? Does skipping the 0 index serve a special purpose here?

Please let me know your thoughts on the fix. If the fix is correct, I can create a Pull Request. I haven't opened one yet because I wanted to be sure first.

Thank you for your answers. Your implementation has been really helpful for my work.

Best regards.