You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it stands, meshswap has some some known bugs regarding stuff like block rotation (and performance, but that's a separate issue). I was curious and wanted to see where meshswap goes wrong in the algorithm. As it stands however, the algorithm for meshswap isn't really readable, nor is it documented.
Due to those issues, I decided to draft a new algorithm from scratch. I'll be linking a PDF that goes in detail (be warned though, it uses a fair amount of mathematical notation and phrasing), but here's some gifs that illustrate what it does. For cubic blocks, given a face, we first try to get the face across from that given face (in the opposite direction of course), then the faces that are adjacent to the given face. We can further confirm that faces are part of the same block by using the normals (we assume for our purposes that they're lines) and seeing how they intersect each other.
For non-cubic blocks, given a face, we find a face that intersects the given face. If such a face exists, we create a line where they intersect. We then create a new line that's parallel to the top of the OBJ (if the OBJ had a bounding box, the top face of that box would be the top of the OBJ). We can then use these lines to determine if the block is straight or rotated, and we can use the rotation of the former line to determine the block's actual rotation.
The advantages of this algorithm are:
A block can be determined with one face
Rotation is basically free (although some cubic blocks like doors might need some extra info as they're special when it comes to rotation)
It's been designed with geometry nodes in mind, which opens the door to a geometry nodes based meshswap.
There are some disadvantages though:
It's based on assumptions about the OBJ and how it was exported (though these assumptions are pretty sound)
The block's dimensions must be known ahead of time
As it stands, meshswap has some some known bugs regarding stuff like block rotation (and performance, but that's a separate issue). I was curious and wanted to see where meshswap goes wrong in the algorithm. As it stands however, the algorithm for meshswap isn't really readable, nor is it documented.
Due to those issues, I decided to draft a new algorithm from scratch. I'll be linking a PDF that goes in detail (be warned though, it uses a fair amount of mathematical notation and phrasing), but here's some gifs that illustrate what it does. For cubic blocks, given a face, we first try to get the face across from that given face (in the opposite direction of course), then the faces that are adjacent to the given face. We can further confirm that faces are part of the same block by using the normals (we assume for our purposes that they're lines) and seeing how they intersect each other.
For non-cubic blocks, given a face, we find a face that intersects the given face. If such a face exists, we create a line where they intersect. We then create a new line that's parallel to the top of the OBJ (if the OBJ had a bounding box, the top face of that box would be the top of the OBJ). We can then use these lines to determine if the block is straight or rotated, and we can use the rotation of the former line to determine the block's actual rotation.
The advantages of this algorithm are:
There are some disadvantages though:
PDF going in further depth
Source files
The text was updated successfully, but these errors were encountered: