Remove mesh #950
Remove mesh #950
Conversation
| @@ -223,7 +223,10 @@ std::vector<Manifold> SplitByPlane(Manifold& m, vec3 normal, | |||
| } | |||
|
|
|||
| void CollectVertices(std::vector<vec3>& verts, const Manifold& manifold) { | |||
| Mesh mesh = manifold.GetMesh(); | |||
| verts.insert(verts.end(), mesh.vertPos.begin(), mesh.vertPos.end()); | |||
| const MeshGL64 mesh = manifold.GetMeshGL64(); | |||
There was a problem hiding this comment.
@pca006132 This was a surprising change I needed. It looks like our WASM vectors are 64-bit internally, yet we're only exposing MeshGL so far. Is that how it should be?
There was a problem hiding this comment.
No, this is weird, we should look into this.
There was a problem hiding this comment.
but if it is std::vector<vec3> it will be using double, we should use std::vector<glm::vec3>
There was a problem hiding this comment.
Yeah, that's what I was thinking too. It looks like all the vectors we define for the WASM bindings are doubles now (probably part of the big find-replace). Care to have a look?
There was a problem hiding this comment.
Will have a look this weekend.
There was a problem hiding this comment.
OK, I looked at this, vec3 is exactly the problem here. What I am not sure is that if we should switch to 32-bit floats. I don't think 32-bit float will buy us anything? Users don't directly pass these vectors to/from graphics applications AFAIK, and we are already using 32-bit floats for MeshGL.
There was a problem hiding this comment.
Oh okay, good. I had thought somehow mesh was becoming 64-bit, but you're right, it's just these hull and polygon vectors. I guess that's fine.
|
and we probably need to open another issue for MeshGL64 tests. |
I already switched a few more random tests over to |
Sounds good to me. I think any bugs we can have with only |
`Mesh` was removed in elalish#950
`Mesh` was removed in elalish#950
Fixes #932