1P by GN⁺ | ★ favorite | 댓글 1개

댓글과 토론

Hacker News 의견들
  • 브라우저에서 볼 수 있는 또 다른 예제: https://oimo.io/works/cloth/

    • 이런 천 상호작용을 게임에서는 언제쯤 볼 수 있을지 궁금함
  • Marian Pekár의 글을 읽고 Verlet 적분을 이해해서 직접 천 시뮬레이션을 만들 수 있었음: https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...

    • “Verlet은 프랑스 Verlet 지역에서 온 것만 Verlet이고, 아니면 그냥 스파클링 Euler”라는 농담이 훌륭함
  • 웹 개발, Gradle, Java 지식에서 어떻게 이런 걸 만드는 단계로 넘어가는지 궁금함
    CS 학부를 안 해서 프로그래밍 언어를 아무리 배워도 이런 건 절대 이해 못 하는 게 아닐까 싶을 때가 있음. OPENLY, LIBGDX, GODOT, Unity를 조금 만져보긴 했지만 천 시뮬레이션을 처음부터 만든다는 건 정말 막막함

    • 생각보다 훨씬 단순함. 이 스레드 다른 곳에 링크된 “찢어지는 천” 데모를 소프트웨어 엔지니어 경력을 시작하기도 전에 만들었음
      여기서는 기본적인 Verlet 적분을 쓰는데, 격자를 이루는 2D 벡터를 현재 위치와 이전 위치 기반으로 갱신하고, 바로 이웃한 점들과 일정 거리를 유지하도록 제한함. 그 점들 사이에 선을 그리면 천이 됨. 물리 시뮬레이션에 매료돼 찾아보다가 가장 구현하기 쉬운 것 중 하나라 처음 접했고, 결과 대비 노력이 아주 좋았음. 물론 그다음부터는 훨씬 복잡해짐
    • 물리 시뮬레이션을 배우고 싶어서 비슷하게 느낀 적이 있음. 시간이 지나며 물리 같은 지식 영역과 그것을 구현하는 프로그래밍 도구를 분리해서 봐야 한다는 걸 배웠음
      특히 게임 개발로 시작하면 강체, 천, 스프링, 유체 같은 주요 시뮬레이션마다 자연스럽고 관용적인 프로그래밍 방식이 있을 것처럼 느껴짐. 처음엔 유체 시뮬레이션도 격자를 만들고 시간 단계마다 갱신 규칙을 고르는 식으로 언어 안에 자연스럽게 표현될 줄 알았음. 하지만 실제로는 문제를 수학과 물리로 모델링한 뒤, 그걸 언어와 도구에 매핑하는 일이고, 그 도구가 항상 관용적으로 표현해 주지는 못함
      입자 위치와 스프링 기반 천 시뮬레이션처럼 쉽게 코드로 옮길 수 있는 알고리즘도 있지만, 더 나아가려 할 때는 오히려 그게 오해를 만들었음. 결국 물리와 수치해석을 더 파고든 뒤 문제를 코드로 옮겨야 했고, 결과 코드는 투박하고 매직 넘버가 많아질 수 있음
    • 웹 개발은 Java에만 국한되지 않고 대체로 컴포넌트 통합 문제가 지배적임. 구조는 많지만 내용은 적고, 계산은 라이브러리에 위임하며, 빌드 시점에는 통합 복잡도, 실행 시점에는 분산 시스템 규모가 문제가 됨
      반대로 시뮬레이션 작성은 계산량이 많아서 코드 대부분이 실제 내용임. 웹 개발이 이질적인 것들의 조합이라면, 시뮬레이션은 더 균질적임. 문제는 초당 프레임 수가 정하는 시간 예산 안에서 단일 프로세스 성능으로 제한됨
      그래서 하나의 실행 환경에 집중할 수 있음. 배포 문제를 해결해 주는 브라우저를 추천함. Ganja[1]는 아마 “구조가 아니라 내용”에 가까운 궁극의 시뮬레이션 프로젝트일 수 있음. 매우 특이하고 이해하기 어려워 유지보수는 멈췄지만, 작동은 함. 조금 더 구조화된 쪽으로는 D3가 있고, 작성자들이 힘 기반 그래프[2] 같은 최신 시각화/배치 알고리즘을 이미 만들어 두었음. 더 친근한 출발점은 Processing[3] 계열일 수 있는데, Java에서 시작해 Python과 JavaScript 등으로 포팅됨
      다만 천 시뮬레이션 하나는 게임 엔진에 비유하면 쥐 한 마리의 세포 하나 같은 수준임. 게임 엔진은 매우 크고, 거기서도 직접 시뮬레이션을 작성하기보다는 많은 내부 통합을 하게 됨
      1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
      2 - https://github.com/d3/d3-force/tree/main/src
      3 - https://processing.org/
    • 결국 전부 수학과 물리
      게임 개발을 콕 집어 묻지는 않았지만, 그래픽, 수학, 조명, 물리 같은 지식은 대체로 그 분야에 많이 퍼져 있음. 천 시뮬레이션 같은 틈새 주제만 따로 찾으려 하면 게임 개발 자료와 엮이지 않은 정보를 찾기 어려울 수 있음
      오늘 https://alextardif.com/LearningGraphics.html를 읽었는데, 여러 방향으로 길잡이가 될 수 있음. https://learnopengl.com/은 Vulkan, Metal, DX12 같은 더 새로운 API가 있는 지금도 꾸준히 좋은 평가를 받음. 다만 API는 해결할 문제의 5% 정도로 보면 됨. 솔직히 더 적을 수도 있지만 Vulkan은 듣던 것보다도 더 무거운 편임
      C/C++를 배우고 싶지 않다면 WebGL 커뮤니티가 크니, 관련 서브레딧이나 포럼에서 시작해도 좋음. 그래도 API와 플랫폼은 실제 물리 시뮬레이션이라는 인상적이고 새로운 부분을 감싸는 껍데기에 가깝다
      출처를 덧붙이면, 웹 개발/Gradle/Java 개발자이고, 몇 년 전 시도 이후 여가 시간에 다시 게임 엔진을 만들고 있음
    • 그렇게 어렵지는 않음. JavaScript에서는 각 점을 (x,y,z)로 표현하고 질량을 준 뒤, 매 프레임 중력을 적용하고 필요하면 약간의 잡음을 더하면 됨
      입자가 움직이려 할 때마다 삼각법으로 힘을 변을 통해 다른 점들로 전달하고, 폭주하지 않도록 감쇠를 조금 넣음. 질량은 이후 힘에 각 점이 얼마나 영향을 받는지를 결정함. 3D가 부담되면 2D로 먼저 하면 됨
  • Elden Ring의 놀라운 천 디자인을 분석한 Polygon 영상이 떠오름: https://youtu.be/wSSqx-Dh6ko

    • 영상에서 충분히 강조하지 않은 부분은 천이 기능적인 목적도 갖는다는 점임. 천은 적의 형태를 가려서 모델을 구분하기 어렵게 만듦
      FromSoft 게임의 가장 혁신적인 측면이라고도 할 수 있는 정밀한 피격 판정과 근접 전투가 핵심인 게임에서는, 자유롭게 흐르는 천 때문에 공격을 맞히려면 캐릭터를 얼마나 가까이 둬야 하는지, 맞지 않으려면 얼마나 떨어져야 하는지 판단하기 어려워짐. 여기에 예측하기 어려운 움직임과 공격 패턴이 더해지면 난이도가 더 올라가고 매 전투가 고유해짐
      현실에서도 천은 같은 성질을 가짐. 로브나 망토를 두른 적은 훨씬 더 위협적이고 상대하기 어려움
      게임플레이 반복 구조 때문에 개인적으로는 FromSoft 게임을 즐기지 않지만, 설계 면에서는 역사상 가장 잘 만든 비디오게임 중 일부라고 봄
  • 이런 천 애니메이션을 늘 좋아했음. 처음 본 건 아마 dissimulate의 Codepen 찢어지는 천 데모였는데, 그 코드를 9년 전에 썼다는 게 믿기지 않음
    [1] - https://codepen.io/dissimulate/pen/eZxEBO
    [2] - https://github.com/Dissimulate/Tearable-Cloth

    • 14년 전에 만든 내 버전도 있음: https://www.youtube.com/watch?v=G05M_Y6NQVM
      이런 기본 구성은 구현하기 아주 단순하고, 결과가 정말 멋지다는 데 동의함
    • 그거 내가 만든 것임. Codepen에 올린 원본 버전은 대략 13년 전이었음
      나도 믿기지 않지만, 첫 프로그래밍 직장을 얻기 전이었다는 걸 떠올리면 정말 오래전처럼 느껴짐
    • 2000년작 비디오게임 Hitman에도 천이 있었고, 2008년작 Mirror's Edge에는 찢어지는 천이 있었음. 아마 둘 다 최초는 아니었을 것임
  • 이런 천 시뮬레이터는 늘 어느 정도 불안정하게 느껴짐. Grid 천을 생성해 보면 튀고 무작위로 움직이기 시작함
    이게 IEEE 754 부동소수점 오차가 누적되기 때문인지 궁금함

    • 물리 시뮬레이션이나 게임 엔진 맥락에서 수치적분을 찾아보면 좋음. 출발점으로 https://en.wikipedia.org/wiki/Numerical_methods_for_ordinary...를 볼 수 있음
      이해하기로는 단순한 부동소수점 오차만이 아니라, 연속 함수를 단순한 이산 단계로 근사하는 성질 때문에 생김. 링크된 위키피디아 글에도 큰 단계에서는 부동소수점 정밀도가 문제가 되기 훨씬 전부터 오차가 누적된다는 그래프가 있음
      수치적분 기법마다 서로 다른 절충이 있음. Euler 방법, Verlet, Runge-Kutta 같은 것들이 있고, 어떤 방식은 전체 에너지가 누적되는 경향이 있으며 다른 방식은 에너지가 손실되는 경향이 있는데 둘 다 틀린 동작임. 더 복잡한 방식들은 조금 더 잘 동작하는 편이지만, 각 단계가 복잡해지는 이득이 더 단순하고 빠른 알고리즘을 더 많이 반복하는 것보다 나은지 따져야 하는 문제가 생김
    • 물리 시뮬레이션에서 에너지 보존은 명시적으로 코딩하지 않으면 기본으로 작동하지 않음. 예를 들어 주기적으로 직접 보정하는 식이 필요함
      반올림 오차뿐 아니라 시간의 양자화, 그리고 수학적 모델 자체에서 오는 다른 작은 오차들도 원인임
      오차가 감쇠 쪽이면 실제처럼 에너지가 소산되어 움직임이 결국 멈추는 효과가 나고, 가속 쪽이면 시뮬레이션이 폭주함
  • 이 사이트 작성자에게 잘 만들었다고 말하고 싶음. 외부 JavaScript 없이 그대로 실행되고, 모바일에서도 동작함
    요즘 텍스트 기반 웹사이트 대부분은 이렇게 말하기 어려움

  • 정말 인상적인 작업임. 단순하지만 계속 보게 만들고, Verlet 적분이 자연스럽고 그럴듯한 천 시뮬레이션을 만드는 데 얼마나 강력한지 잘 보여줌
    관심 있다면 Hitman 게임 엔진에서 나온 Jakobsen 논문도 추천함. 고전적인 자료임

  • 이런 것이 어떻게 작동하는지 어려운 질문을 실제로 던지는 모습을 보는 게 좋음. 모든 것이 수년 동안 쌓인 수많은 작은 단계에서 만들어진다는 느낌을 매번 받게 됨
    수학이 벽처럼 느껴지는 지점에 부딪히는지, 아니면 이해될 때까지 계속 두드리는지 궁금함

  • 몇 가지 매개변수와 제약만 설정해도 이렇게 현실적인 움직임이 나오는 점이 가장 흥미로움
    우리 주변 세계도 숨겨진 모델과 힘의 집합일 뿐이고, 우리의 일은 그것을 발견하고 시뮬레이션하는 것일지도 모른다는 생각이 듦. 아름다운 작업임