glb/glTF I/O question

[starseeker]

I'm in the process of trying to extract a mesh from my software into .glb format to see if I can independently confirm a regression I'm seeing with Manifold 3.0 (not sure yet if it is my fault or a genuine problem - that's one of the questions to be answered) and I'm finding myself down a rabbit hole.

I had the bright idea to write a basic exporter using tinygltf to try and dump out exactly the input data that seems to be causing me trouble, and after a bunch of internal thrashing I'm finally (I think) able to write out a basic .glb file holding the mesh data. However, when I try to read it into Manifold via MeshIO it's not happy.

That may be due to any number of issues on my end, since I'm still figuring glTF out, but one thing I am definitely seeing in debugging is "Unsupported Component Type" errors from assimp. I know (I think) why it's complaining - BRL-CAD internally uses int and double arrays to store our triangle data, and in the spirit of changing as little as possible I tried to write out those buffers as-is using tinygltf's typedefs for INT and DOUBLE component types. Unfortunately, it seems neither of those are "standard" for the purpose, and Assimp gives me "GLTF: Unsupported Component Type 5124" and "GLTF: Unsupported Component Type 5130" respectively.

Looking at https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#accessor-data-types that seems to be fair - neither of those is called out in the standard. It's not a big deal for the indexing integers, since those can be converted without loss to a valid type, but I'm a lot more concerned about the vertex positions. Since the idea is to reproduce as accurately as possible the inputs that are (possibly) causing problems, stepping the double data down to float would seem to be quite problematic.

What is the recommend practice for preparing a .glb file in such a case? I can try forcing the data through a float conversion and see if I am still able to see the particular problem at hand, but even if that works in this particular instance I'm worried about encountering a future case where that won't cut it. Another option would be to try to write an equivalent tinygltf-based replacement for MeshIO on the Manifold side that would get assimp out of the picture. That solution would tautologically handle the same types tinygltf supports, but I'm not sure if it would be a good idea either... The .glb files produced that way would still be non-standard, if I'm interpreting this correctly. I wanted to get some second opinions on the best way to proceed before following the rabbit any further - is there a best practice I should be following?

[pca006132]

Ah, we actually faced this problem and we wrote a custom obj file IO for this dumping full double precision for vertex positions:

manifold/src/impl.cpp

Lines 604 to 688 in cba9e35

	#ifdef MANIFOLD_DEBUG
	std::ostream& operator<<(std::ostream& stream, const Manifold::Impl& impl) {
	stream << std::setprecision(17); // for double precision
	stream << "# ======= begin mesh ======" << std::endl;
	stream << "# tolerance = " << impl.tolerance_ << std::endl;
	stream << "# epsilon = " << impl.epsilon_ << std::endl;
	// TODO: Mesh relation, vertex normal and face normal
	for (const vec3& v : impl.vertPos_)
	stream << "v " << v.x << " " << v.y << " " << v.z << std::endl;
	std::vector<ivec3> triangles;
	triangles.reserve(impl.halfedge_.size() / 3);
	for (size_t i = 0; i < impl.halfedge_.size(); i += 3)
	triangles.emplace_back(impl.halfedge_[i].startVert + 1,
	impl.halfedge_[i + 1].startVert + 1,
	impl.halfedge_[i + 2].startVert + 1);
	sort(triangles.begin(), triangles.end());
	for (const auto& tri : triangles)
	stream << "f " << tri.x << " " << tri.y << " " << tri.z << std::endl;
	stream << "# ======== end mesh =======" << std::endl;
	return stream;
	}
	#endif
	#ifdef MANIFOLD_EXPORT
	Manifold Manifold::ImportMeshGL64(std::istream& stream) {
	MeshGL64 mesh;
	std::optional<double> epsilon;
	stream.precision(17);
	while (true) {
	char c = stream.get();
	if (stream.eof()) break;
	switch (c) {
	case '#': {
	char c = stream.get();
	if (c == ' ') {
	constexpr int SIZE = 10;
	std::array<char, SIZE> tmp;
	stream.get(tmp.data(), SIZE, '\n');
	if (strncmp(tmp.data(), "tolerance", SIZE) == 0) {
	// skip 3 letters
	for (int i : {0, 1, 2}) stream.get();
	stream >> mesh.tolerance;
	} else if (strncmp(tmp.data(), "epsilon =", SIZE) == 0) {
	double tmp;
	stream >> tmp;
	epsilon = {tmp};
	} else {
	// add it back because it is not what we want
	int end = 0;
	while (end < SIZE && tmp[end] != 0) end++;
	while (--end > -1) stream.putback(tmp[end]);
	}
	c = stream.get();
	}
	// just skip the remaining comment
	while (c != '\n' && !stream.eof()) {
	c = stream.get();
	}
	break;
	}
	case 'v':
	for (int i : {0, 1, 2}) {
	double x;
	stream >> x;
	mesh.vertProperties.push_back(x);
	}
	break;
	case 'f':
	for (int i : {0, 1, 2}) {
	uint64_t x;
	stream >> x;
	mesh.triVerts.push_back(x - 1);
	}
	break;
	case '\n':
	break;
	default:
	DEBUG_ASSERT(false, userErr, "unexpected character in MeshGL64 import");
	}
	}
	auto m = std::make_shared<Manifold::Impl>(mesh);
	if (epsilon) m->SetEpsilon(*epsilon);
	return Manifold(m);
	}
	#endif

I should probably make it public so users can use it when needed.

[elalish]

Yeah, I love glTF, but it wasn't really made for this purpose. It's not designed to be lossless, but rather to dump data into OpenGL buffers as directly as possible. GPUs are not big on double precision, so they stick with floats. I think for this case, @pca006132's solution is the way to go.

[starseeker]

Got it. I'll try the operation with a stepped-down vertex array to see if a valid glb will do the trick, since that'll be more compact as a test case if it does wind up being a valid issue. I'll also check our obj output to see if we're keeping full precision should that be necessary.

[starseeker]

@pca006132 I got a glb file set up with the test case against master, and it does seem to be very slow - way more so that I would have expected for such a relatively small input: master...starseeker:manifold:slowoffset

Maybe I need to add tolerance setting?

Is this worth making a pull request? I've not tried this test definition directly with v2.4.5 since it would be a bit of a job to back-port, but the BRL-CAD logic using this input succeeds in about 75 seconds, even non-parallel...

[pca006132]

Ah, the double one has ~9x more vertices, it is normal that it runs slower?

[starseeker]

Hmm. When I import both the glb and the obj into BRL-CAD, they both report 586 vertcies and 584/583 faces respectively. What counts are you seeing?

[starseeker]

So far all my BRL-CAD integrations of Manifold are still sequential - I want to look into enabling TBB, but other priorities have kept me busy.

[pca006132]

diff --git i/test/boolean_complex_test.cpp w/test/boolean_complex_test.cpp
index 9afe0db..b10560d 100644
--- i/test/boolean_complex_test.cpp
+++ w/test/boolean_complex_test.cpp
@@ -1028,6 +1028,7 @@ TEST(BooleanComplex, SlowOffsetFloat) {
   std::string file = __FILE__;
   std::string dir = file.substr(0, file.rfind('/'));
   MeshGL seeds = ImportMesh(dir + "/models/" + "Generic_Twin_7316.1.t0.glb");
+  printf("seeds.NumVert() = %d\n", seeds.NumVert());
   EXPECT_TRUE(seeds.NumTri() > 10);
   EXPECT_TRUE(seeds.NumVert() > 10);
   // Unique edges
@@ -1119,6 +1120,7 @@ TEST(BooleanComplex, SlowOffsetDouble) {
   std::string file = __FILE__;
   std::string dir = file.substr(0, file.rfind('/'));
   MeshGL seeds = ImportMesh(dir + "/models/" + "Generic_Twin_7316.1.t0.obj");
+  printf("seeds.NumVert() = %d\n", seeds.NumVert());
   EXPECT_TRUE(seeds.NumTri() > 10);
   EXPECT_TRUE(seeds.NumVert() > 10);
   // Unique edges

[starseeker]

OK, the ImportMesh function must be doing something different than what we're doing. I'll see if I can dig some more next week.