Closed abedef closed 5 years ago
You can assume that all faces are quads and that it's a closed mesh - no holes.
The fold shouldn't affect your implementation since it doesn't change the connectivity of your mesh.
I used to have a problem with something like this, albeit not as bad. The way I fixed it was to make a quick cube.obj, and then see what was going on. I printed out all the vertices, edges, calculated vertices, etc, then compared it to my paper calculations to see what was wrong.
I made something like this and it was my debugging tool to help me find what I messed up on:
g cube
v 0.0 0.0 0.0
v 0.0 1.0 0.0
v 1.0 1.0 0.0
v 1.0 0.0 0.0
v 0.0 0.0 1.0
v 0.0 1.0 1.0
v 1.0 1.0 1.0
v 1.0 0.0 1.0
f 1 2 3 4
f 8 7 6 5
f 2 6 7 3
f 5 1 4 8
f 5 6 2 1
f 4 3 7 8
which maps onto
5----6
/ /|
/ / |
1----2 7
| | /
| |/
0----3
with the 4 in the corner we can't see. Point 0 is (0, 0, 0) and point 6 is (1, 1, 1).
Stepping through a simple cube was a lot easier than fighting a massive object.
Thanks @WChrisK, I'll give that a try. In my implementation I read the mesh into a custom data structure which describes faces and their neighbours, along with other points of interest. From visual inspection so far, it seems that it maps the input to the data structure appropriately, but maybe I can pinpoint some bugs with your suggestion.
I just finished implementing my function with the pure quad mesh assumption. It works well for the most part but fails around the areas with the awkward face connections (mainly around the seams splitting the model in two down the middle). Any thoughts on how to work around this? Which assumptions can we make? Can we assume that all its quads are connected? For example, there looks to be a fold underneath where the head figure begins (visible when viewing the mesh from within).