
맵툴에서 가장 오래 잡고 있었던 문제는 Snap이었다.
처음에는 그냥 오브젝트끼리 가까워지면 딱 붙게 하면 될 줄 알았다. 하지만 실제로 구현해보니, 단순히 position을 맞추는 것과 사용자가 기대하는 배치감 사이에는 꽤 큰 차이가 있었다.
처음 시도한 방식은 대체로 이런 흐름이었다.
- 마우스 아래 표면을 찾는다
- preview mesh를 그 표면 위에 올린다
- 주변 오브젝트와 가까워지면 face / edge / vertex 기준으로 위치를 보정한다
문제는 이웃 오브젝트를 잡는 기준이 실제 메쉬 면이 아니라 AABB bounds에 가까웠다는 점이었다.

겉으로는 face snap처럼 보이지만, 실제로는 회전된 메쉬를 감싸는 박스를 기준으로 계산하고 있었고, 그러다 보니 면끼리 딱 붙는 게 아니라 어딘가 어긋난 상태가 자꾸 나왔다.
특히 회전된 큐브나 경사 메쉬 위에서 이 문제가 더 심하게 드러났다.
실제 메쉬는 기울어져 있는데, snap 계산은 축 정렬된 bounds를 보고 있으니 당연히 기대한 위치에 붙지 않았다. 처음에는 이걸 MeshCollider 문제라고 생각했지만, 실제 원인은 collision보다는 snap 기준 자체가 mesh face가 아니라 bounds였다는 점에 더 가까웠다.
이 문제를 해결하기 위해 MeshCollider를 적극적으로 쓰기 시작했다.
그리고 단순히 collider를 바꾸는 것만으로는 부족해서, 현재 마우스가 어떤 triangle face를 가리키고 있는지 잡고, 같은 plane 위의 coplanar triangle들을 묶어서 하나의 face처럼 다루는 구조까지 들어가게 됐다.
이 과정에서 등장한 것이 Face Anchor다.
Face Anchor는 단순히 가까운 오브젝트에 붙이는 것이 아니라,
- 현재 hovered face를 찾고
- 그 face의 normal과 plane을 기준으로
- preview mesh를 그 면 위에 올린 뒤
- 필요하면 그 면 안에서 edge 방향 정렬을 추가로 보정
하는 방식이다.
이 방식으로 바꾸고 나서 가장 큰 변화는, 왜 지금 이 위치에 붙는지를 디버그로 눈으로 볼 수 있게 되었다는 점이었다.

붉은색으로 hovered face를 표시하고, Primary Axis, Secondary Axis, Surface Normal, Hit Point를 같이 그려보니, 단순히 느낌으로 붙는다 안 붙는다를 보는 게 아니라 실제로 어느 면을 기준으로 계산 중인지 파악할 수 있었다.
물론 아직 완벽하진 않다.
예를 들어 벽처럼 메쉬를 차곡차곡 쌓을 때는 Face만으로는 부족하고, 면 위에서 edge를 더 강하게 맞추는 stricter한 정렬이 필요할 때가 있다. 또 support surface와 neighbor face를 어떤 우선순위로 볼 것인가도 여전히 조정 포인트다.
맵툴에서 말하는 Snap은 단순히 좌표를 끊는 기능이 아니라, 결국 사용자가 기대하는 접촉 관계를 얼마나 잘 이해하느냐의 문제라는 점이다. 그리고 그걸 제대로 하려면 AABB만으로는 부족했고, 결국 face를 직접 다루는 단계까지 오게 됐다.
다음 글에서는 이 툴이 커지면서 왜 MapToolWindow.cs 하나로는 더 이상 감당이 안 됐는지, 그리고 실제로 어떤 기준으로 파일을 나누고 정리했는지 적어보려고 한다.
'Unity - '한 우산 아래'' 카테고리의 다른 글
| Unity에서 이동 방향을 바라보는 플레이어 회전 만들기 (0) | 2026.04.12 |
|---|---|
| 맵툴 제작기 3 - 2000줄 넘은 Unity Editor Tool 코드 정리하기 (0) | 2026.04.08 |
| 맵툴 제작기 1 - Unity Editor에서 쿼터뷰 퍼즐 게임용 Map Tool 만들기 (0) | 2026.04.08 |
| [한 우산 아래] 캐릭터를 가리는 벽 처리 - Layer 분리와 Material 기반 Occlusion Fade 구현 (0) | 2026.04.01 |
| C#의 foreach와 var를 C++과 비교해보기 (0) | 2026.04.01 |