🧩Project SuperDex — Meta의 ‘접촉 우선’ 물리엔진 스택 정리

superdex
Meta
physics-engine
simulation
dexterity
contact
tactile
soft-body
differentiable-simulation
rl
storage
Meta Reality Labs Research가 공개한 dexterous manipulation 시뮬레이션 플랫폼. SuperDex Physics의 설계(암시적 적분·compliant contact·SDF)를 문서 근거로 정리하고, 이어서 소스코드를 직접 clone해 예제 26개 실행·벤치마크 측정으로 검증한다 — 문서에 없던 adjoint 미분가능 시뮬레이션 발견을 포함해 문서 기반 판단 일부를 정정한다.
Published

August 26, 2026

이 글은 논문 리뷰가 아니라 웹 문서 기반 정리입니다. 출처는 projectsuperdex.com, SuperDex Physics Docs, facebookresearch/project_superdex 세 곳이며, 문서에 적혀 있는 내용만 옮깁니다. 문서에 없는 것은 “확인 안 됨”으로 표시했습니다.

조회 시점: 2026-08-26. 이 프로젝트는 리포지터리 CHANGELOG 기준 2026-08-24 initial release로, 아주 초기 단계입니다. 내용이 빠르게 바뀔 수 있습니다.

Important📌 갱신 노트 (2026-08-26, 최초 발행 직후)

이 글을 처음 쓴 뒤, 소스코드를 직접 clone해서 읽고 예제 26개를 전부 실행하고 벤치마크까지 측정했습니다(upstream 기준 커밋 a393382e, SuperDex 1.0.0). 그 결과 문서만 보고 내린 판단 중 일부가 반박됐고, “확인 안 됨”으로 남겨둔 항목 여럿에 답이 나왔습니다. 아래 항목을 정정·보강했습니다.

항목 이전 판단 (문서 근거) 정정 (소스·실행 근거)
미분가능성 “autodiff/adjoint API 근거 없음” ❌ 반박됨 — 완전한 reverse-mode adjoint가 소스에 있고 휠에 노출돼 있음. 유한차분 대조 통과(§6 끝, §10.1)
엔진 코어 개방성 “바이너리 배포일 가능성 확인 안 됨” ✅ 완전 오픈소스 확정 — 레포 전체에 바이너리 블롭 0개(§10.2)
GPU “GPU 안 씀” ✅ 결론 유지, ❌ 근거 정정 — GPU 희소 선형 솔버 스택이 소스에 있으나 MOCHI_USE_CUDA 0으로 꺼둔 채 출하(§10.3)
성능 수치 “문서에 없음 → 판단 불가” 문서에 없는 건 여전히 사실. 우리가 직접 측정(§10.4)
Experimental 등급 “실재 여부 불명” 스텁 아님 — 26/26 예제 실행 성공, cloth/rod 실제로 동작(§10.5)
미수렴 시 진행 문서 서술만 소스에서 maxIter = 4 기본값·abort 플래그 부재 확인, 런타임에서도 재현(§5)
그림 캡션 갤러리 주변 텍스트로 추정 ❌ 5건 오류 — 이미지를 직접 열어 전수 재작성, 그림 배치도 변경(아래 참조)

표기 규칙: 이 글에서 📄 문서 근거는 공개 문서에서 읽은 것, 🔬 소스·실행 근거는 우리가 소스를 읽거나 직접 돌려서 확인한 것입니다. 소스 인용은 파일:라인 앵커를 붙였고, 경로의 M/은 superdex_physics/libraries/mochi/의 줄임입니다.

또 하나, 소스와는 별개의 오류가 있었습니다. 그림 캡션 5건이 실제 이미지와 달랐습니다. 최초 작성 때 갤러리 페이지의 주변 텍스트만 보고 캡션을 추정했고, 이미지를 실제로 열어보지 않았기 때문입니다. 예를 들어 “볼트에 너트를 끼우는” 장면이라고 쓴 그림에는 볼트도 너트도 없었고(조립 보드와 빨간 노브였습니다), “천 가방”이라고 쓴 그림은 주방의 반투명 도마였습니다. 9장을 전부 다시 열어 보이는 것만 쓰도록 캡션을 재작성했고, 해당 절의 논지를 더 이상 뒷받침하지 못하는 그림은 위치를 옮겼습니다. 이미지에서 확인되지 않는 actor 타입 단정(rod/shell/soft)은 모두 뺐습니다.

실험 기록은 비공개(private) 실험 레포 curieuxjy/project_superdex에 CODE-NOTES.md / EXPERIMENTS.md로 남겼습니다 — 링크는 걸어두지만 외부에서는 열람할 수 없습니다.


프로젝트 홈의 히어로 이미지 — 다관절 로봇 손이 손끝으로 평면에 닿는 라인아트. 홈페이지는 이 이미지 옆에 “A unified platform for dexterous manipulation research”라는 문구를 답니다(projectsuperdex.com).

한 줄로 말하면

SuperDex는 손으로 하는 조작(dexterous manipulation) 연구를 위해 Meta가 만든 오픈소스 시뮬레이션 플랫폼이고, 그 중심에는 “접촉을 먼저 생각해서” 새로 짠 물리엔진 SuperDex Physics가 있다.

홈페이지의 표현을 그대로 옮기면:

“SuperDex is an open-source simulation platform from Meta for robotic dexterous manipulation, built around a custom physics engine for complex, contact-first interactions.” — projectsuperdex.com

여기서 눈에 띄는 단어가 contact-first입니다. 대부분의 로봇 시뮬레이터는 “강체 다물체 동역학 엔진”을 먼저 만들고 접촉을 그 위에 얹습니다. SuperDex Physics 문서는 반대 방향을 주장합니다 — 접촉(그것도 분포된 접촉)을 1급 시민으로 두고, 강체·연체·막·로드를 하나의 솔버로 함께 푼다는 것입니다.

1. Project SuperDex의 구성 — 무엇이 모듈인가

프로젝트는 여섯 개의 “building block”으로 나뉩니다. 로드맵 페이지에 각 모듈의 상태 뱃지가 붙어 있고, 이게 이 글에서 가장 중요한 정보입니다.

# 모듈 설명 (로드맵 원문 요약) 상태
01 SuperDex Physics tactile manipulation 전용으로 만든 contact-first 물리엔진. 플랫폼의 시뮬레이션 백본. Released
02 SuperDex Robotics 로봇 정의·합성, 컨트롤러/센서/액추에이터, 이들을 시뮬 설정으로 묶는 프레임워크를 제공하는 로보틱스 SDK. Released
03 SuperDex Studio 로봇·메시·태스크 프리팹·씬을 만들고 편집·검증하는 데스크톱 GUI 저작 도구. Released
04 SuperDex Lab RL·MPC·system-ID의 바탕이 되는 MDP와 dynamics-constrained optimization을 추상화한 시뮬레이션 하네스. Early Preview
05 SuperDex Teleoperation 시뮬/실물 teleoperation과 데이터셋 수집을 지원하는 데이터 획득 앱. Upcoming
06 SuperDex Learning dexterous manipulation 정책 개발용 데이터셋·학습 레시피·평가 스위트 모음. Upcoming

출처: Roadmap. 로드맵 헤드라인은 “Phased releases to deliver an end-to-end solution.”, 부연은 “SuperDex Physics, Robotics, Studio, and Lab are available today, with more to come in the coming months.” 입니다.

Physics가 코어인 이유는 구조상 자명합니다. Robotics는 “로봇을 SuperDex Physics 엔진 위에서 정의·합성·시뮬레이션”하는 계층이고(Robotics Overview), Lab의 SuperDex Gym은 “a Gymnasium-compatible reinforcement-learning framework built on the SuperDex Physics engine”(Lab Overview)이며, Studio는 그 엔진이 먹을 수 있는 에셋을 만드는 도구입니다. 나머지 셋은 전부 Physics의 소비자입니다.

홈페이지는 이걸 세 동사로도 정리합니다: Simulate(SuperDex Physics) → Teleoperate(VR teleoperation, 합성 데이터) → Train(batched simulation, Gymnasium API, Ray/RLlib). 이 중 Teleoperate에 해당하는 모듈이 아직 Upcoming이라는 점이 현재 스택의 가장 큰 구멍입니다.

2. 리포지터리에는 실제로 무엇이 있나

facebookresearch/project_superdex를 GitHub API로 직접 확인한 결과입니다(2026-08-26 조회).

  • 생성일 2026-08-20, CHANGELOG ## [2026-08-24] - Initial release. — 공개된 지 며칠 안 됐습니다.
  • 주 언어 C++ (약 19MB), Python (약 2.8MB), C# (약 1.5MB, Studio 쪽으로 추정), CMake, 소량의 CUDA.
  • 라이선스: first-party 소스는 Apache-2.0, 에셋·문서는 CC-BY-4.0. 단 superdex_mesh_cli는 OCCT/CGAL 사용 때문에 GPLv3로 별도 배포. 또한 README가 명시적으로 경고합니다 — “Certain third party dependencies and third party assets in this repo are licensed for non-commercial/academic uses only.” 상업적 사용을 생각한다면 이 부분을 반드시 개별 확인해야 합니다.
  • 톱레벨 디렉터리: superdex_physics, superdex_physics_fp64, superdex_robotics, superdex_robotics_fp64, superdex_lab, superdex_studio, superdex_python, superdex_meta, superdex_mesh_cli, superdex_physics_debugger, assets, tools.
  • 설치: uv pip install superdex로 pypi 사전 빌드 휠이 제공됩니다. 단 현재 Python 3.12 전용이며, README는 “More flexible abi3 wheels will be available in a future release”라고 적고 있습니다.
  • 소스 빌드: CMake ≥ 3.25 + Ninja + Clang 17 이상(Windows는 ClangCL). GCC·MSVC는 “not officially supported or covered by CI”.
  • 정밀도: 단정밀도가 기본이고, --extra double 빌드 + SUPERDEX_PRECISION=double 환경변수로 배정밀도 실행이 가능합니다. _fp64 디렉터리가 따로 있는 이유가 이것입니다.
  • 인용: Citation details will be added here upon publication. — 아직 논문이 없습니다. 그래서 이 글이 논문 리뷰가 아닌 문서 정리인 것입니다.

📄 문서 근거로 확인 못 했던 것: superdex_physics/ 아래에는 include/superdex_physics.h, libraries/mochi, examples, test가 있습니다. 엔진 코어 소스가 libraries/mochi에 실제로 다 들어 있는지(=완전 오픈소스인지), 아니면 일부가 바이너리로 배포되는지는 디렉터리 목록만으로 단정할 수 없었습니다. 참고로 엔진 내부 코드네임은 “mochi”로 보입니다 — 씬 파일 확장자가 .mochiscene/.mochiprefab, 에셋이 .mochi.h5, CMake 옵션이 MOCHI_USE_DOUBLE_PRECISION입니다.

🔬 소스로 확인함(갱신): 완전 오픈소스가 맞습니다. 레포 전체에서 *.so/*.a/*.dll/*.lib/*.dylib/*.o를 찾으면 0개입니다 — 닫힌 라이브러리를 감싼 헤더 껍데기가 아닙니다. 자세한 수치는 §10.2.

3. SuperDex Physics — 왜 새로 만들었나

Overview가 밝히는 문제의식은 명확합니다. 기존 시뮬레이터가 범용 강체 동역학에 최적화된 반면, SuperDex Physics는 “multi-finger grasps, in-hand reorientation, and non-convex contact” 같은 까다로운 접촉을 안정적이고 고충실도로 푸는 것을 목표로 합니다.

문서가 나열한 핵심 역량 7가지(원문 요약):

  1. Multi-physics simulation — 강체·연체(soft)·로드/힘줄(rods & tendons)·셸/천(shells & cloth)을 하나의 통합 솔버로.
  2. Arbitrary rigid & soft articulations — 한 모델 안에서 강체 링크와 변형체 요소를 함께 갖는 관절체.
  3. Non-convex collision — 볼록화 없이, 변형하는 물체까지 포함해 임의 형상에 대한 접촉력 분포를 계산.
  4. Spatially dense contact forces — 합력 하나가 아니라 접촉면 위의 3D 힘 분포를 계산. 문서는 이것이 “현실적인 촉각 센서 모델링”과 “RL 정책을 위한 더 풍부한 관측 신호”를 가능케 한다고 말합니다.
  5. Inverse Kinematics — forward dynamics와 같은 비선형 최적화 코어 위에 올린 constraint-aware IK.
  6. Numerical stability — explicit/semi-implicit 방식의 타임스텝 안정성 제약이 없음.
  7. Proven dexterity — “User studies demonstrate near real-world manipulation performance in VR scenarios.”

🔎 7번은 주의해서 읽어야 합니다. user study가 있었다는 주장은 있지만, 문서에 참가자 수·과제·지표·수치가 전혀 없습니다. 논문도 아직 없으므로 현재로선 검증 불가능한 주장입니다. 이 글에서 가장 조심스럽게 다뤄야 할 문장입니다.


주방 조리대 위에 놓인 분홍색 무늬 천(접힌 자국이 격자로 남아 있다)과 그 양옆의 사람 손 두 개. 얇은 변형체를 손으로 다루는 장면이다. 홈페이지 Gallery. — 캡션은 이미지에서 보이는 것만 적었다. 어떤 actor 타입으로 구현했는지는 갤러리 원 캡션으로 확인되지 않는다.

갤러리 캡션에 따르면 이 영상들은 Meta Quest 3 헤드셋을 쓴 사람이 virtual teleoperation으로 조작한 것이며, “simulated in real time”이라고 명시돼 있습니다. 다만 리포지터리 README는 같은 영상들에 대해 “recorded in real-time using SuperDex Teleop (available in Q4 2026)”라고 적고 있습니다 — 즉 이 데모를 만든 teleop 도구는 아직 공개되지 않았습니다.

4. 설계 핵심 ① — 암시적 적분 (Dynamics)

Dynamics 문서는 상당히 학술적입니다. 요지는 이렇습니다.

일반화 좌표 q \in \mathcal{Q}, 속도 v = \dot q에 대해 라그랑지안

L(q, v, t) = T(q, v, t) - U(q, t)

를 두고 오일러–라그랑주 방정식에 비보존력(소산) 을 더한 형태로 시스템을 기술합니다. U에는 탄성·중력·접촉·제약·외력이 모두 들어갑니다. 회전·관절 포즈·로드 프레임처럼 \mathcal{Q}가 벡터공간이 아닌 경우에는 접공간에서 증분을 계산하고 타입별 업데이트로 다시 다양체로 사상합니다.

시간 적분은 암시적 multistep + Runge–Kutta 계열의 통합 패밀리이고 기본값은 backward Euler입니다. 문서 표현으로 “Explicit stages and fully coupled implicit Runge–Kutta methods are not supported” — 즉 대각 암시적(DIRK) 계열까지만 지원합니다. BDF2/BDF3도 지원하며, 상태가 충분히 쌓이기 전까지 backward Euler로 시작해 차수를 올립니다.

여기서 incremental potential 개념이 등장합니다. 각 스텝의 암시적 단계 잔차 r_i가 어떤 스칼라 퍼텐셜의 그래디언트일 때, 임의의 비선형 방정식 풀이가 아니라 최적화 문제로 바꿔 풀 수 있고 훨씬 강건해집니다. 문서는 이게 항상 성립하지는 않는다고 솔직하게 적습니다 — 예를 들어 Newton–Euler 강체 관성은 정확한 incremental potential을 주지 않고, 접촉 마찰도 일부 항을 스테이지 시작 시점 값으로 고정(explicit 평가) 해야만 적분가능한 이산 모델이 됩니다.

실용적으로 중요한 문장은 이 대목입니다:

“For A-stable integration methods, including L-stable methods, the time-step size is not limited by the stiffness-driven linear-stability restrictions of explicit or semi-implicit methods. Consequently, SuperDex Physics can use substantially larger stable time steps than physics engines based on explicit or semi-implicit integration.”

그리고 구체적 권장 범위까지 줍니다:

“Time steps of 10–25 ms (40–100 physics steps per simulated second) run robustly in most scenes, including complex contact-rich and deformable simulations. This is a practical starting range, not a guarantee.”

이건 꽤 강한 주장입니다. 접촉이 많은 조작 씬을 초당 40–100 스텝으로 돌린다는 건, 통상 500Hz~2kHz를 쓰는 explicit/semi-implicit 계열 대비 스텝 수가 한 자릿수 배 적다는 뜻입니다. 물론 한 스텝의 비용은 훨씬 비쌉니다(뉴턴 반복 + 선형 풀이). 스텝당 비용 × 스텝 수의 총합이 실제로 유리한지에 대한 벤치마크 수치는 문서에 없습니다.

5. 설계 핵심 ② — 솔버 (Solvers)

Solvers 문서. 매 암시적 스테이지마다 비선형 방정식계

r_i(q_i;\, Y_i^0,\, \Delta t_i) = 0

를 풀어야 하고, SuperDex Physics는 이를 line search를 동반한 quasi-Newton 법으로 근사적으로 풉니다. 구조는 다음과 같습니다.

  • Island 분해 — 한 스텝에서 서로 상호작용할 수 있는 액터들을 “island”로 묶어 분해합니다. 목적은 두 가지: 멀티스레드 병렬성 활용, 그리고 DoF 수에 초선형(super-linear)으로 스케일하는 풀이 비용을 제한.
  • Jacobian 근사 — 비대칭 항 제거, PSD(positive semidefinite) 투영 등의 옵션을 제공합니다. 이유가 실용적입니다: 대칭·PSD로 만들면 더 효율적인 선형 솔버를 쓸 수 있고, 비선형 반복의 강건성도 올라갑니다. 정확한 Jacobian 중 계산은 비싼데 수렴에 별 도움이 안 되는 항은 그냥 버립니다.
  • 선형 솔버 — 직접법(LDLT/LU)과 반복법(Krylov)을 모두 지원. 기본 정책은 Auto: 작은 계는 LDLT, 큰 계는 CG. CG는 SPD를 가정하므로 위의 PSD 근사와 짝을 이룹니다. MINRES(대칭 부정부호), GMRES(일반 비대칭)도 지원. 전처리기(preconditioner)도 액터별 힌트로 자동 선택됩니다.
  • Line search — 잔차만 평가하는 방식과 incremental potential을 쓰는 방식이 모두 있습니다. 문서는 큰 변형체의 탄성 에너지처럼 잔차가 퍼텐셜에서 정확히 유도되는 경우 퍼텐셜 기반 line search가 유리하다고 안내합니다.

가장 정직하고 중요한 대목은 수렴 실패 처리입니다:

“In many high-fidelity simulators used for scientific and engineering applications, the simulation will either reduce its time step size or terminate with an error if the maximum number of iterations is reached without meeting a convergence criterion. However, this is impractical for applications in real-time interactive simulation of robot teleoperation or large-scale control policy training, where speed and robustness must be prioritized over absolute accuracy. The default behavior of SuperDex Physics is to continue to the next time integration step (or stage) after reaching the maximum iteration count, which is the common pragmatic solution in the computer graphics literature…”

즉 기본 설정에서는 수렴하지 않아도 그냥 다음 스텝으로 넘어갑니다. 그래픽스 관행이며, 실시간 teleop과 대규모 RL 학습을 노린 의도적 선택입니다. 정확도가 필요한 사용자를 위해 state capture/restore로 미수렴 스텝을 재시도하는 커스텀 스테핑 경로를 안내하고 있습니다. — sim2real을 신경 쓰는 사람이라면 이 기본값을 알고 있어야 합니다.

🔬 소스·실행으로 확인함(갱신) — 문서가 말한 그대로이고, 생각보다 더 공격적입니다.

  • ConvergenceStatus는 심각도 순으로 정렬됩니다: None < Converged < Stopped < Diverged (M/mochi_core/include/mochi_core/solvers/nonlinear_solver_params.h:27-49). Stopped는 “수렴 허용오차를 만족하지 못한 채 정지 기준 중 하나를 충족”(:38-42)이라는 뜻입니다.
  • 기본 반복 예산이 int maxIter = 4; 입니다(nonlinear_solver_params.h:342-343). 최대 반복 도달 시 M/mochi_core/src/solvers/newton_solver.cpp:212가 Stopped(stopReasonStr = "Maximum iterations")를 세팅하고, :155에서 액터별로 isActorConverged ? Converged : Stopped가 결정됩니다.
  • NonLinearSolverParams에 “미수렴 시 중단” 플래그는 아예 없습니다. 안전망은 휴리스틱한 폭발 제어(:391 explosionControl = true, absDivTol = 1e9, relDivTol = 1e4)뿐입니다.
  • 실행에서도 그대로 나타납니다. 예제 17개 중 example_tshirt_on_plane, example_slit_annular_ring, example_mass_on_rod_spring, example_articulations_soft_skinned_double_pendulum 4건이 STOPPED 상태로 돌면서도 물리적으로 타당한 운동을 계속했습니다(티셔츠는 0.875 m 드레이프).

결론: 뻣뻣한 변형체에서 Stopped는 오류 경로가 아니라 정상 동작 영역입니다. “스텝이 반환됐다 ≠ 스텝이 수렴했다”이므로, 정확도가 중요하면 get_convergence_status()를 반드시 확인해야 합니다.

6. 설계 핵심 ③ — 접촉 모델 (Contact)

이 엔진의 정체성이 걸린 부분입니다. Contact 문서 첫 문단이 전부를 요약합니다.

“SuperDex Physics uses a compliant contact model, which can be interpreted as either a penalty regularization of an inequality constraint or as a reduced model of local surface deformation. This approach provides smooth, differentiable contact forces suitable for implicit time integration and optimization-based solvers, and provides spatial distributions of contact traction fields acting on the surfaces of bodies, rather than just point-contact force resultants. Compliant contact allows for some interpenetration of colliding bodies, which is evaluated using signed distance fields (SDFs) and generalizations thereof.”


연한 빛을 내는 유연한 손끝을 가진 로봇 손이 조리대 위의 배(pear)에 접근·접촉하는 근접 컷. 홈페이지 Gallery. — ⚠️ 이 이미지에 traction field 시각화가 그려져 있는 것은 아니다. 위 본문이 말하는 “합력이 아닌 분포”가 겨냥하는 상황(곡면 물체 × 유연한 손끝)을 보여주는 정지 컷일 뿐이다.

Collider / Colliding — 비대칭 역할 분리

모든 접촉 쌍에는 두 역할이 있습니다.

  • Collider — 침투 깊이와 법선을 주는 SDF를 제공하는 쪽.
  • Colliding — 표면을 quadrature 샘플점으로 이산화해서, 상대의 SDF를 조회해 traction을 계산하는 쪽.

이 분리가 실용적으로 영리합니다. 변형체(colliding)를 강체 장애물(collider)에 누를 때, 변형하는 형상 위에서 비싼 SDF를 평가할 필요가 없습니다. 한 액터가 두 역할을 동시에 할 수도 있고, 그러면 두 방향 패스의 결과를 합칩니다. 단방향 한 패스만으로도 양쪽에 균형 잡힌 힘이 걸립니다.

Collider 표현 종류

설정 표현 문서의 단서
Auto 액터·형상 의존 지원 형상엔 해석적 필드, 강체 메시·soft엔 Sdf, shell·rod엔 PointCloud
Sphere / Box / Plane 해석적 SDF 정확하고 저렴
Mesh 삼각 메시 거리 질의 비볼록 지원하나 experimental, 상대적으로 느림, 강체·관절 링크 한정
Sdf 사전 계산 격자 SDF 복잡 형상 지원, trilinear 보간 근사, 해상도–메모리 트레이드오프
PointCloud 물질점 주위 구형 SDF point-cloud 액터끼리만 상호작용

여기서 “non-convex collision”의 실체가 드러납니다. 볼록 분해 없이 비볼록을 다루는 주력 수단은 격자 SDF의 trilinear 보간입니다. 정확한 삼각 메시 질의는 있지만 experimental이고 느립니다. 즉 비볼록 지원은 “정확한 기하 질의”라기보다 해상도로 정확도를 사는 볼륨 필드 근사입니다. 볼록 분해(MuJoCo/PhysX 관행)의 아티팩트는 피하지만, 대신 SDF 격자 해상도가 새로운 튜닝 손잡이가 됩니다(GridSdfParams: resolutionMode, resolutionDelta, minGridResolution, boundaryPaddingDist).

정밀 조립 장면 두 컷. (좌) 로봇 팔 + 다지 핸드가 파란 조립 보드 위에 있고, 보드에는 빨간 노브, 흰색 커넥터/단자대, 원통형 페그 몇 개가 놓여 있다. (우) 알루미늄 프로파일 랙에 파란 랙마운트 네트워크 스위치가 물려 있고, 하단에 로봇 손가락이 보인다. 홈페이지 Gallery. — 둘 다 정지 프레임이라 어떤 동작이 진행 중인지는 단정할 수 없다. 다만 노브·커넥터·랙 레일처럼 볼록 분해로 뭉개지기 쉬운 기하가 등장한다는 점에서, 위에서 설명한 비볼록 SDF 접촉이 겨냥하는 부류의 씬이다.

마찰과 감쇠

  • Coulomb 마찰을 정적 영역의 점성 정규화(viscous regularization) 로 모델링합니다. falloff velocity 파라미터가 “정적 마찰로 취급하는 최대 미끄러짐 속도”를 정합니다. — 즉 완벽한 stiction은 아니고, 미소 크리프를 허용하는 매끄러운 근사입니다(암시적 솔버 친화적인 선택).
  • 법선 점성 감쇠가 반발(restitution)을 지배합니다. 문서는 강체 점 충돌에 대해 속도 의존 반발계수(CoR) 가 나온다는 점을 명시하고, 감쇠계수를 CoR로부터 보정하는 닫힌 형태 공식(양방향)을 제공합니다.
  • 접촉 쌍의 마찰·감쇠 계수는 두 액터 값의 기하평균. 다만 collider가 static이면 penalty 계수와 falloff 속도는 colliding 쪽 값을 씁니다.
  • 법선 정렬 기각 — SDF 기반 compliant contact에서 법선 관계가 근사일 뿐이라, 정렬이 크게 어긋난 접촉은 아예 기각하거나 소산 응답을 감쇠시킵니다. shell·rod는 colliding 법선이 없어 이 기각 로직이 꺼집니다.
  • 파이프라인은 broad phase(AABB) → narrow phase(quadrature 샘플 vs SDF) → force & Jacobian assembly 3단계.

그래서, 미분가능한가? — ⚠️ 이 절은 정정됐습니다

먼저 처음에 쓴 판단을 그대로 남깁니다.

📄 문서 근거 (최초 판단): 문서가 쓴 “differentiable”은 접촉력이 접촉 상태에 대해 매끄럽다(C¹ 급) 는 뜻이고, 그 목적은 “suitable for implicit time integration and optimization-based solvers” 입니다. 즉 뉴턴 솔버가 Jacobian을 쓸 수 있게 하기 위한 매끄러움입니다. 시뮬레이션 전체에 대한 그래디언트를 학습에 흘려보내는 differentiable simulation(autodiff/adjoint) API는, physics 문서 전 페이지(62개)를 받아 검색한 범위에서 언급이 없습니다. differentiable이라는 단어 자체가 Contact 페이지의 저 한 문장 외에는 나오지 않고, adjoint·autodiff·gradient of the simulation 류 표현도 없습니다. → “미분가능 시뮬레이터”로 분류하기엔 근거 부족.

🔬 소스·실행 근거 (정정): 틀렸습니다. SuperDex Physics는 미분가능 시뮬레이터입니다. 소스에는 완전한 reverse-mode adjoint 미분 시뮬레이터와 forward step Jacobian이 들어 있고, 출하 휠에 superdex.physics.diffsim으로 노출돼 있습니다. 그리고 우리는 읽기만 한 게 아니라 돌려서 확인했습니다 — backward Euler 20스텝을 통과하는 adjoint 그래디언트가 중앙 유한차분과 최대 절대오차 4.5e-11로 일치했습니다. 근거와 주의사항은 §10.1에 모았습니다.

여기서 중요한 건 “제가 틀렸다”가 아니라 왜 문서만으로는 알 수 없었는가입니다.

문서 62페이지에 adjoint·autodiff가 0회 등장한다는 사실 자체는 여전히 참입니다. 즉 제 검색이 부실했던 게 아니라, 엔진이 자기 핵심 기능 하나를 문서에 아예 안 적어둔 것입니다. 미분가능 시뮬레이션은 “있으면 좋은 부가 기능”이 아니라 그 엔진을 고를지 말지를 가르는 1급 셀링 포인트인데, 공개 문서 어디에도 없어서 소스를 clone해 헤더를 열어보기 전에는 존재를 알 방법이 없었습니다.

교훈은 두 방향입니다. ① 독자 입장 — 초기 릴리스 프로젝트를 문서만으로 평가하면 과소평가한다. 문서는 프로젝트의 하한선이지 실체가 아닙니다. ② 프로젝트 입장 — 이건 SuperDex 쪽의 문서 결함입니다. 이 정도 기능이 미문서화라면, 다른 미문서화 기능도 있다고 가정하는 게 맞습니다(실제로 §10에서 몇 개 더 나옵니다).

7. Actor 타입 — 성숙도까지 표에 적혀 있다

Actors Overview는 드물게 정직한 표를 줍니다.

Actor 설명 상태
Rigid 비변형 강체. dynamic은 6-DoF, static은 환경 기하. Stable
Soft 사면체 메시로 이산화한 변형 탄성 볼륨. Stable
Articulated 조인트로 연결된 강체 링크 다물체. 스킨 표면이나 결합 soft 액터를 선택적으로 가짐. Stable
Shell 삼각 메시로 이산화한 변형 탄성 표면. Experimental
Rod 폴리라인으로 이산화한 변형 탄성 곡선. Experimental

관절체는 단순한 “제약으로 이은 강체 모음”이 아니라 축소 좌표(reduced coordinate) 로 최소 표현됩니다. Soft 재료 모델은 Linear Elastic / StVK / ARAP / Neo-Hookean / Stable Neo-Hookean(+ active 변형)이 문서화돼 있습니다.

즉 홈페이지가 자랑하는 “shells & cloth”, “rods & tendons”는 실제로는 experimental 등급입니다. 이것이 “지금 무엇이 실재하는가”를 보는 이 글의 관점에서 중요한 구분입니다. Transmissions와 Inverse Kinematics도 문서에 “part of the experimental API. Its API may change in future releases.” 라고 명시돼 있습니다.

(좌) 싱크대 앞의 로봇 손 두 개, 개수대 가장자리에 노란 스펀지, 오른쪽 아래에 파란 접시. (우) 어두운 색 로봇 손가락 세 개가 연한 색의 무른 손끝으로 파란 알루미늄 프로파일의 모서리를 누르고 있다. 홈페이지 Gallery. — (우)에서 강체 링크와 뚜렷이 구분되는 무른 손끝 재질이 눈으로 확인된다. (좌)의 스펀지가 이 프레임에서 눌려 변형돼 있지는 않다.

얇은 변형 표면이 등장하는 두 컷. (좌) 주방 조리대 위의 반투명한 녹색 도마와 오렌지·사과·바나나, 오른쪽에 싱크대, 냉장고 앞에 손 두 개. (우) 사람 손이 윗부분 덮개가 벌어진 시리얼 상자를 기울여 흰 그릇 위로 붓는 장면. 홈페이지 Gallery. — 둘 다 두께에 비해 넓은 얇은 면(도마, 종이 상자 벽)이 주인공이고, 특히 (우)의 벌어진 상자 덮개는 굽힘 강성이 큰 얇은 면의 변형으로 보인다. 다만 이것이 실제로 Shell actor로 구현됐는지는 갤러리 원 캡션으로 확인되지 않아 단정하지 않는다.

특히 무른 손끝 예시(위 첫 번째 그림의 (우))는 이 엔진의 노림수를 잘 보여줍니다 — 촉각 센서의 유연한 표면 자체를 soft articulation으로 모델링하고, 그 위의 접촉을 traction field로 계산하면, 시뮬레이션에서 촉각 이미지 비슷한 것을 만들 수 있는 길이 열립니다. (다만 문서에 촉각 센서 시뮬레이션의 구체적 API나 검증 결과는 없습니다 — 어디까지나 “가능하게 한다”는 서술입니다.)

8. 실제 코드는 어떤 모양인가

Python API의 감을 주는 Inspecting Scenes 예제입니다(문서 원문).

import superdex.physics as physics

def main() -> None:
    physics.initialize(num_worker_threads=-1)
    try:
        scene = physics.create_scene("My Scene")
        # Add actors and constraints to the scene.
        if not physics.debugger.attach():
            return
        while physics.debugger.is_attached():
            scene.step(1.0 / 60.0)
    finally:
        physics.shutdown()

if __name__ == "__main__":
    main()

읽히는 것들:

  • Context → Scene → Actor 구조. Context는 프로세스 단위 진입점으로 워커 스레드 풀과 shape를 소유하고, Scene은 독립 시뮬레이션 컨테이너입니다(서로 다른 Scene의 액터는 상호작용하지 않음).
  • num_worker_threads=-1 — CPU 워커 풀 기반. -1은 가용 논리 프로세서에 맞춤, 0은 단일 스레드. set_is_single_threaded(), get_num_threads() 등이 있고, 스레드 바인딩·해제 규칙이 문서에 꽤 상세합니다(생성과 파괴는 같은 스레드에서).
  • scene.step(dt) — dt를 호출자가 직접 넘깁니다. 가변 타임스텝이 1급입니다.
  • physics.debugger.attach() — 디버거는 네트워크로 붙는 별도 애플리케이션입니다. 다른 프로세스, 심지어 다른 컴퓨터에서 도는 시뮬레이션에도 붙을 수 있습니다. 대부분의 Python 예제가 이걸 자동으로 띄웁니다.

예제는 Examples에 카테고리별로 17개가 문서화돼 있습니다 — Basic(rigid bodies, soft duck, state capture), Contact & Constraints, Articulations(double pendulum 변형 4종 + pose controller + IK), Shell(t-shirt, slit annular ring), Tendons & Rods, Advanced(damping sweep, cross-thread capture/restore). 실행은 uv run --no-project examples/example_rigid_bodies.py.

부수적으로 눈여겨볼 기능 두 가지:

  • State Capture — 씬의 스텝 간 상태를 체크포인트해서 되감기·한 체크포인트에서 여러 롤아웃 분기·다른 호환 씬으로 상태 이전이 가능합니다. MPC/planning과 RL 롤아웃 모두에 직접 쓰이는 기능입니다.
  • Pose Controller — 관절체용 암시적 PD 컨트롤러. 추종 목표를 soft spring-damper 제약으로 표현해 동역학과 함께 푼다고 명시합니다. 고게인에서 explicit force controller가 터지는 문제를 피하기 위한 설계입니다. 로봇 정책의 액션이 보통 관절 목표 위치라는 점을 생각하면 실용적으로 중요한 부분입니다.

9. 로드맵 — 지금 있는 것 ↔︎ 앞으로 올 것

문서에서 근거를 찾을 수 있는 것만 정리합니다.

이미 공개된 것 (2026-08-24 initial release)

  • SuperDex Physics (rigid/soft/articulated = stable, shell/rod = experimental), C++ & Python API, Linux x86-64 / Windows x86-64 / macOS arm64.
  • SuperDex Robotics — 선언적 로봇 정의(문서 왈 “closer to URDF than to MJCF or USD”), 로봇 합성(팔 + 그리퍼), 관절공간 PD와 OSC 컨트롤러, URDF import. 문서는 “The same controller code drives a simulated or a real robot”라고 주장합니다.
  • SuperDex Studio — GUI 저작 도구. (단 Studio 문서 페이지에 “Some of the shown features will be part of future SuperDex Studio releases.” 라는 각주가 붙어 있습니다.)
  • SuperDex Lab (early preview) — SuperDex Gym(Gymnasium 호환), Ray/RLlib 통합, 벤치마킹, 대용량 배치 학습, 렌더링. 문서 왈 “currently in early preview and will receive substantial improvements.”
  • Physics Debugger, mesh CLI 등 도구류.

예정 (문서에 근거가 있는 것만)

항목 시점 근거
SuperDex Teleop — Unreal Engine 5 기반 virtual teleop 초기 컴포넌트. Quest 3 온디바이스 네이티브 실행(원격 PC·스트리밍 없음), 핸드 트래킹 + 컨트롤러 + 혼합 모드, 순수 C++. Q4 2026 리포지터리 README
SuperDex Learning — 데이터셋·학습 레시피·평가 스위트 Upcoming (시점 미명시) 로드맵
Robotics: tendon actuation, soft robot linkages & skins, 로봇 씬·태스크 기술 프레임워크 + domain randomization “upcoming releases” Robotics Overview
abi3 wheel(Python 3.12 외 지원) future release README
C++ 예제 공개 “will be shared in the future” README
논문/인용 정보 “upon publication” README

10. 🔬 소스코드를 clone해서 확인한 것 (갱신 절)

여기부터 §10 전체는 문서가 아니라 소스와 실행 결과가 근거입니다. upstream 기준 커밋 a393382e(SuperDex 1.0.0), 설치는 uv pip install superdex(PyPI 사전 빌드 휠, cp312, 9초). 실행 머신은 Ubuntu 24.04 / i9-14900K(32 논리코어) / 30 GB RAM / RTX 5090. 경로의 M/은 superdex_physics/libraries/mochi/입니다.

10.1 미분가능 시뮬레이션 — 있습니다 (문서에 없을 뿐)

mochi::diffsim은 완전한 reverse-mode adjoint 미분 시뮬레이터이고, 여기에 forward step Jacobian까지 딸려 있습니다.

무엇 어디
공개 diffsim API M/mochi_physics/private/diffsim/include/mochi_physics/diffsim/mochi_diffsim.h:27 MakeSceneDifferentiable, :43 PrepareBackPropagate, :45 BackPropagate, :47 GetStepJacobian
adjoint ECS 컴포넌트 M/mochi_physics/src/mochi_differentiable.h:25-29 (namespace mochi::diffsim, BackPropagationSolverParams), :38 TagDifferentiableScene, :41 TagBackPropagationPrepared
구현 M/mochi_physics/src/mochi_differentiable.cpp, mochi_differentiable_contact.cpp
Python 바인딩 M/mochi_physics/pybind/src/generated/mochi_physics_pybind_mochi_diffsim.generated.cpp:110 make_scene_differentiable, :168 prepare_back_propagate, :182 back_propagate
C++ 테스트 M/mochi_physics/private/diffsim/test/ — mochi_step_jacobian_test.cpp, mochi_differentiable_contact_test.cpp, mochi_autodiff.{h,cpp}

출하 휠에서는 superdex.physics.diffsim으로 28개 공개 심볼이 노출됩니다 — 출력별 backward 함수(get_root_transform_backward, get_articulated_pose_backward, get_contact_force_world_backward …)와 Lie ↔︎ 쿼터니언/회전벡터 그래디언트 변환기가 포함됩니다.

직접 검증: backward Euler 20스텝을 통과하는 adjoint 그래디언트를 중앙 유한차분과 대조했습니다.

adjoint dL/dv0      = [0.0, 0.33333333, 0.0]
finite differences  = [0.0, 0.33333333, 0.0]
max abs error       = 4.5e-11      -> PASS

정직한 단서 조항 — API 문서 문자열과 우리 실험에서 나온 것들입니다.

  • 실질적으로 fp64 전용(SUPERDEX_PRECISION=double)이고 BACKWARD_EULER 전용입니다.
  • API가 명시합니다 — “Differentiability is only supported for rigid and articulated actors.” 즉 soft·shell·rod는 미분 대상이 아닙니다.
  • 우리가 검증한 건 매끄러운 자유낙하 궤적입니다. 접촉을 통과하는 그래디언트는 검증하지 않았습니다 — 그게 어렵고 흥미로운 경우인데 말이죠.
  • make_scene_differentiable()은 내부적으로 experimental.apply_improved_convergence_settings()를 조용히 호출해 사용자가 고른 씬·액터 설정을 덮어씁니다(경고 로그는 남김). 따라서 미분 가능 실행은 일반 실행과 스텝 단위로 동일하지 않습니다.

⚠️ dt 의존 그래디언트 함정 (upstream에 보고할 만한 버그)

미분 시뮬레이션을 쓸 생각이라면 이건 알고 시작해야 합니다. 첫 실행에서 그래디언트가 정확히 0.6배 틀렸고, 0.6 × (1/60) = 0.01이 실마리였습니다.

set_velocity_backward는 dL/dv = dt · dL/d(dx)를 계산하는데, 이때 쓰는 dt가 복원된 상태(restored state)에 기록된 타임스텝입니다. 그런데 첫 step() 이전에 capture_state()를 하면 거기 기록된 값은 여러분의 dt가 아니라 기본값 get_last_time_step() == 0.01입니다. dt를 쓸어보면 명백합니다.

dt adjoint dL/dvy 기대값 N·dt
0.005 0.100 0.050
0.010 0.100 0.100
1/60 0.100 0.167
0.050 0.100 0.500

adjoint가 dt와 무관하게 N × 0.01로 고정됩니다. 회피책: 초기 상태를 capture하기 전에 워밍업 step(dt)를 한 번 돌리세요. 그러면 오차가 4.5e-11로 떨어집니다. 연쇄법칙 자체는 우리가 시험한 모든 N(1, 2, 3, 5, 10, 20, 40)에서 정확했으므로 솔버 버그가 아니라 문서·API 설계의 함정입니다. 다만 조용히 틀린 값을 주기 때문에 위험합니다.

10.2 엔진 코어는 완전 오픈소스 — 확정

  • 트리 전체에 사전 빌드 바이너리 0개. *.so, *.a, *.dll, *.lib, *.dylib, *.o를 레포 전체에서 찾으면 아무것도 나오지 않습니다.
  • 모듈별 헤더/구현 파일 수(third_party 제외):
모듈 헤더 구현(.cpp/.cc/.cu) 크기
mochi_core 413 332 11 MB
mochi_physics 107 155 8.5 MB
mochi_renderer 24 26 5.3 MB
mochi_debugger 20 31 504 KB
mochi_mesh 13 20 448 KB
superdex_mesh_cli 9 13 292 KB
  • 솔버 내부가 전부 열려 있고 읽힙니다: newton_solver.cpp, Krylov 스택(minres.h, augmented_pcg.h, amg/amg_prec.h), 접촉(mochi_contact.cpp), island, ECS, 그리고 위의 diffsim adjoint.
  • upstream C++ 테스트 스위트도 함께 옵니다(mochi_core/test, mochi_physics/test, private/diffsim/test) — mochi_scene_convergence_test.cpp, newton_solver_test.cpp 같은 파일이 솔버 의미론을 해석하는 데 실제로 도움이 됐습니다.

결론: libraries/mochi는 엔진의 완전한 Apache-2.0 소스 릴리스입니다. 단, 우리는 소스 빌드를 하지 않았으므로 “빌드 가능하다”는 구조적 판단이지 시험된 사실이 아닙니다(이 머신은 g++ 13.3.0에 clang이 아예 없고, upstream은 Clang ≥ 17을 요구합니다).

10.3 GPU — 결론은 그대로, 근거는 정정

맞은 절반: 출하 상태에서 GPU는 전혀 쓰이지 않습니다. 설치된 배포판의 모든 .so(libmochi_physics.so, libmochi_renderer.so, libsuperdex_robotics.so, mochi_physics.so, fp64 변종)에 ldd를 걸면 libcuda/libcublas/libcusparse 링크가 하나도 없습니다. 전 세션 동안 nvidia-smi는 데스크톱 용도(Xorg/gnome-shell) 외 사용을 보이지 않았습니다.

틀린 절반 — 여기가 중요합니다. 원래 글은 레포의 소량 CUDA를 Studio 렌더링 쪽으로 짐작했는데, 아니었습니다. .cu 파일 8개는 전부 물리 솔버용 희소 선형대수입니다.

M/mochi_core/src/linear_algebra/cuda/cuda_pcg.cu
M/mochi_core/src/linear_algebra/cuda/cuda_gmres_kernels.cu
M/mochi_core/src/linear_algebra/cuda/cuda_bsr_matrix.cu
M/mochi_core/src/linear_algebra/cuda/cuda_block_jacobi_prec.cu
M/mochi_core/src/linear_algebra/cuda/cuda_sparse_factorization.cu
M/mochi_core/src/linear_algebra/cuda/cuda_transpose.cu
M/mochi_core/src/linear_algebra/cuda/cuda_api.cu
M/mochi_core/test/cuda_test_kernels.cu

즉 GPU Krylov 솔버 스택(PCG, GMRES, block-Jacobi 전처리기, BSR 희소행렬, 희소 분해)입니다 — 렌더러가 아니라 암시적 적분기의 내부 루프입니다.

그리고 이건 없는 게 아니라 잠들어 있는(dormant) 것입니다.

  • M/mochi_core/include/mochi_core/mochi_config.h:175-176 — #ifndef MOCHI_USE_CUDA / #define MOCHI_USE_CUDA 0.
  • third_party 밖의 어떤 CMakeLists.txt·.cmake도 CUDA를 언급하지 않습니다. mochi_core/CMakeLists.txt에는 Eigen·HDF5·Tracy·Accelerate용 opt-in 블록이 있지만 CUDA용은 없습니다 — 즉 켤 수 있는 빌드 설정 자체가 제공되지 않습니다.
  • M/mochi_core/include/mochi_core/linear_algebra/base_tools.h:531-533이 의도를 그대로 적어놨습니다: “CUDA matrices require building with CUDA. To enable CUDA, add the CUDA dependencies to your build configuration and define MOCHI_USE_CUDA=1”.
  • mochi_config.h:183은 NVIDIA cuDSS 직접 희소 솔버(MOCHI_USE_CUDSS)도 참조합니다 — 마찬가지로 꺼져 있습니다.

정확한 서술: SuperDex 1.0.0은 출하 상태에서 CPU 전용이고 달리 빌드할 지원 경로도 없지만, 코드베이스는 배선되지 않은 GPU 솔버 백엔드를 품고 있습니다. “GPU를 안 쓰는 엔진”과 “GPU 경로를 갖고 있으나 꺼둔 채 출하한 엔진”은 로드맵 해석에서 의미가 전혀 다릅니다. 다만 그게 실제로 동작하는지는 이 릴리스에서 시험 불가능합니다(우리 머신엔 nvcc도 없습니다).

10.4 성능 — 문서엔 없고, 우리가 쟀습니다

⚠️ 이 절의 수치는 SuperDex가 발표한 값이 아닙니다. 문서에 성능 수치가 전혀 없다는 원래 서술은 여전히 사실이고, 아래는 우리가 이 머신에서 직접 측정한 값입니다. 다른 하드웨어에서는 당연히 달라집니다.

레포에는 배치 환경 벤치마크(superdex_lab/apps/envs/benchmark.py)와 MuJoCo 유래 환경(assets/benchmarks/{ant,cart_pole,half_cheetah})이 실제로 들어 있습니다. 워커당 16환경으로 돌린 sim FPS(전 환경 합산 물리 스텝/초)입니다.

env 1 worker (16 envs) 4 (64) 8 (128) 16 (256) 1→16 스케일링
cart_pole 10 465 37 518 26 829 49 315 4.7×
ant 3 829 14 440 17 872 20 711 5.4×
half_cheetah 3 044 11 215 14 769 18 344 6.0×

control FPS는 sim FPS ÷ (sim_freq/control_freq)로, 16워커에서 cart_pole 24 658, ant/half_cheetah 3 669–4 142입니다. 256환경에서 메모리 0.8–1.2 GB, 초기화는 모든 구성에서 1.6초 미만이었습니다. 스케일링은 뚜렷하게 sub-linear(워커 16배에 6배)이고 cart_pole은 비단조입니다(8워커가 4워커보다 낮게 재현됨) — 32스레드 CPU에 16개 프로세스 워커가 각자 내부 워커 풀까지 돌리니 예상되는 결과입니다.

씬 단위 비용은 편차가 훨씬 큽니다(300스텝, dt = 1/60, 단일 스레드).

씬 ms/step 실시간 대비
example_rigid_bodies (강체 2개) 0.018 885×
example_articulations_skinned_double_pendulum 0.104 161×
example_soft_duck 9.59 1.74×
example_tshirt_on_plane (셸 3593노드, 10 779 DoF) 47.2 0.35×

천이 세 자릿수 배 비쌉니다. 다만 CPU 워커 스레드가 여기서 잘 먹습니다 — 티셔츠 씬을 num_worker_threads=-1로 돌리면 47.2 → 14.1 ms/step (3.3× 이득, 실시간 1.18×). GPU는 전혀 관여하지 않습니다.

해석: “CPU라서 배치 학습이 안 된다”는 아닙니다. 강체 RL 환경에서는 수만 sim FPS가 나옵니다. 다만 GPU 시뮬레이터가 내세우는 수십만~수백만 FPS 급과는 자릿수가 다르고, 이 엔진의 강점은 애초에 그쪽이 아닙니다.

10.5 “Experimental”은 스텁이 아니다 — 26/26 실행 성공

문서의 Experimental 라벨은 API 안정성에 대한 것이지 코드가 없다는 뜻이 아니었습니다. mochi_physics/src 전체에서 “not implemented” 문자열은 mochi_discretization_components.h:270의 좁은 한 건(특정 경계 이산화 타입의 MakeBoundaryElement)뿐입니다.

기능 소스 줄 수 실행 확인
shells / cloth mochi_shell.cpp(+mochi_shell_init.cpp) 436 ✅ example_tshirt_on_plane — 3593노드 SHELL, 10 779 DoF, 0.875 m 드레이프
rods mochi_rod.cpp(+mochi_rod_pose.cpp) 1810 ✅ example_mass_on_rod_spring(2.42 m 운동), example_slit_annular_ring
transmissions / tendons mochi_transmission.cpp 377 ✅ example_tendon_comparison(rod tendon, spatial tendon, linear transmission)
IK mochi_ik.cpp 264 ✅ example_ik, robotics_example_ik_pose_control

upstream 예제 26개를 전부 실행했고 26/26 성공, 0 실패입니다.

🪤 재현하려는 분께 — 가장 중요한 함정. 모든 upstream 예제는 시뮬레이션 루프를 GUI 디버거에 걸어둡니다.

if physics.debugger.attach():
    while physics.debugger.is_attached():
        scene.step(TIME_STEP)

headless 머신에서는 attach()가 실패하므로 예제가 물리를 0스텝 돌리고도 exit 0을 냅니다. 그냥 돌려서 “성공”이 뜨는 것은 아무것도 증명하지 않습니다. 우리는 upstream 파일을 고치는 대신 두 개의 하네스를 따로 썼습니다 — 예제의 create_*_simulation()을 직접 불러 스스로 스텝하는 것, 그리고 physics.debugger를 몽키패치해 attach()가 True를, is_attached()가 정확히 N번 True를 반환하게 해서 예제 자신의 main()을 돌리는 것(컨트롤러·IK 목표처럼 main() 안에서 의미 있는 일을 하는 robotics 예제용).

부수적으로: physics.initialize()를 무엇보다 먼저 불러야 합니다(debugger.is_attached()조차 그 전엔 RuntimeError). 그리고 에셋 루트가 두 개입니다 — physics 예제는 superdex_physics/assets, robotics 예제와 Lab 벤치마크는 톱레벨 assets를 SUPERDEX_ASSETS_PATH로 줘야 합니다(미문서화, 누구나 처음에 걸립니다). 벤치마크 앱은 tqdm을 쓰는데 의존성으로 선언돼 있지 않습니다.

10.6 우리가 실패한 것 — 안정적인 파지

정직하게 적습니다. 손이든 그리퍼든 물체를 안정적으로 쥐는 데는 실패했습니다.

  • 접촉 검출 자체는 확실히 동작하고 풍부합니다 — 접촉 순간 블록에 접촉점 2764개에 걸쳐 1677 N이 보고됐습니다.
  • Allegro 핸드는 잘 로드되고 제어됩니다(22 DoF, 26 링크 액터, 그중 4개가 *_digit2_sensor_base 촉각 링크). 관절 포즈 제어로 구동되며 솔버는 CONVERGED, 0.39 ms/step(42× 실시간).
  • Robotiq 2F-85는 닫힌 4절 링키지입니다. 너클 DoF 하나만 구동하면 턱이 거의 안 움직이고(0.101 → 0.101 m), 모든 너클/핑거 DoF에 부호를 맞춘 협조 패턴을 주면 닫히긴 합니다(1.0 rad에서 0.101 → 0.024 m).
  • 그런데 블록이 집히지 않고 튕겨 나갑니다. 닫는 동안 중력을 꺼도 마찬가지입니다.

우리 해석은 링키지 그리퍼의 mimic/coupled 조인트를 raw per-DoF 포즈 목표가 아니라 Transmissions(문서상 Experimental) 경로로 배선해야 한다는 것인데, 거기까지 확인하지는 못했습니다. 따라서 “SuperDex로 파지가 된다”는 우리가 검증하지 못했습니다. 접촉 물리 일반은 검증됐습니다 — example_rigid_bodies에서 y=0.2에 놓인 구가 떨어져 테이블 위 y=0.0728에 정지하고 큐브는 0.0777에 정지하며, 정적 액터는 정확히 제자리를 지키고 둘 다 CONVERGED를 보고합니다.

“구현돼 있다”와 “제대로 쓰기 쉽다”는 다른 얘기라는 것이 §10.5와 §10.6을 합친 결론입니다.

10.7 하지 못한 것 · 추가로 알게 된 것

하지 못한 것 — C++ 트리 소스 빌드(Clang ≥ 17 필요, 이 머신은 g++ 13.3.0), superdex_studio GUI, 물리 디버거 GUI, C++ gtest 스위트(소스 빌드 필요), VR teleoperation(upstream이 미래 작업으로 명시), superdex_mesh_cli 검증(GPLv3, OCCT/CGAL 필요), 그리고 안정적 파지(§10.6).

라이선스 보강 — 루트 LICENSE는 Apache-2.0이고 first-party 패키지마다 자체 Apache-2.0 LICENSE를 갖고 있습니다. 반면 superdex_mesh_cli/LICENSE는 GNU GPL v3입니다(thirdparty_licenses/cgal/LICENSE.GPL). 실무적 함의: pip install superdex를 하면 GPLv3 컴포넌트인 superdex-mesh-cli가 Apache-2.0 컴포넌트들과 함께 여러분 환경에 설치됩니다. 벤더 제한 에셋도 확인됐습니다 — assets/bots/hands/allegro_v5/LICENSE는 “Wonik Robotics Asset License”이고, dg5f_long/dg5f_short도 자체 약관을 답니다. assets/benchmarks/는 MuJoCo 유래 모델이라 별도 라이선스(LICENSE + LICENSE-MIT + NOTICE)입니다.

API 마찰 몇 가지(전부 실제로 시간을 잡아먹은 것들) — 접촉·에너지 조회는 opt-in이라 register_query(QueryType.TOTAL_CONTACT_FORCE / CONTACT_POINTS / ELASTIC_ENERGY)를 먼저 불러야 하는데, 기본 오류 메시지(“results should be available after the next simulation step”)가 그걸 알려주지 않습니다. 암시적 형상 생성 함수(plane/sphere)로 만든 액터는 static만 가능하고 dynamic 액터엔 surface mesh가 필요합니다. SHELL 액터는 get_node_positions_local()이 없어 get_displacements()를 써야 합니다. PoseControllerParams.joint_tracking 길이는 numDofs가 아니라 1(브로드캐스트) 또는 numLinks입니다.

11. Newton / MuJoCo / Isaac 사이에서 어디에 서 있나

⚠️ 여기부터는 SuperDex 문서가 경쟁 엔진을 직접 비교하지 않는다는 점을 먼저 밝힙니다. 문서에 있는 표현은 “physics engines based on explicit or semi-implicit integration” 같은 부류에 대한 일반 언급뿐이고, MuJoCo·Isaac·Newton을 이름으로 거명한 비교는 없습니다. 아래는 각 엔진의 공개 문서에서 알려진 특성과 대조한 것이지, 우열 판정이 아닙니다.

축 SuperDex Physics (문서 근거) 대비
연산 장치 📄 CPU 워커 스레드 풀 + island 병렬화(문서 62페이지에 GPU·CUDA 언급 0회). 🔬 출하 .so에 CUDA 링크 0개로 확인. 단 소스에는 GPU 희소 Krylov 솔버가 있고 MOCHI_USE_CUDA 0으로 꺼져 있음(§10.3). Newton은 NVIDIA Warp 기반 GPU 우선, Isaac Lab/Isaac Gym도 GPU 대규모 병렬이 존재 이유.
적분 A/L-stable 암시적(backward Euler 기본, BDF2/3, DIRK). 10–25ms 타임스텝 권장. MuJoCo는 semi-implicit/implicit-in-velocity 계열로 통상 훨씬 작은 스텝.
접촉 Compliant(penalty) + SDF + 표면 quadrature → traction field. 합력이 아닌 분포. MuJoCo는 soft constraint 기반 point contact, PhysX/Isaac은 볼록 분해 + 접촉점 집합. “합력 대신 분포”가 SuperDex의 가장 뚜렷한 차별점.
비볼록 볼록 분해 없이 격자 SDF 근사(정확 메시 질의는 experimental). MuJoCo/PhysX는 볼록 분해가 관행.
멀티피직스 강체·soft·shell·rod를 하나의 솔버로(단 shell/rod는 experimental). Newton은 여러 솔버를 모듈로 꽂는 방식(MuJoCo-Warp, Disney Kamino, 커스텀). 철학이 정반대에 가깝다.
RL 인터페이스 SuperDex Gym(Gymnasium) + Ray/RLlib, early preview. 🔬 256환경에서 cart_pole 49 315 / ant 20 711 sim FPS(우리 측정, §10.4). Isaac Lab·MuJoCo Playground는 훨씬 성숙.
에셋 포맷 자체 포맷(.superdex_bot, .mochiscene/.mochiprefab, .mochi.h5) + URDF import. Newton/Isaac은 OpenUSD 중심. 생태계 상호운용성은 SuperDex가 불리.
미분가능성 🔬 있음(정정) — reverse-mode adjoint + step Jacobian(mochi::diffsim), 유한차분 대조 오차 4.5e-11. 단 fp64 + backward Euler + 강체/관절체 한정. 📄 문서엔 언급 0회(§10.1). Newton/Warp은 미분가능 시뮬레이션 경로가 명시적으로 존재.
개방성 Apache-2.0 (일부 제3자 에셋은 비상업 한정). —

정리하면 SuperDex Physics는 “GPU로 수천 환경을 돌려 스루풋을 뽑는” 축이 아니라, “한 씬의 접촉을 크고 안정적인 스텝으로 정확하게 푸는” 축에 서 있습니다. 실시간 VR teleoperation이 주 데모라는 점, island 기반 CPU 병렬이라는 점, 미수렴 시 그냥 진행하는 기본값(maxIter = 4) — 세 가지 모두 같은 방향을 가리킵니다. 🔬 다만 소스에 잠들어 있는 GPU Krylov 백엔드(§10.3)와 실제로 존재하는 adjoint 미분 경로(§10.1)를 보면, 이 축 선택이 영구적인 설계 선언이라기보다 1.0.0 시점의 출하 상태로 읽는 편이 맞아 보입니다. Newton 정리 글과 Newton 영상 모음에서 본 “GPU 위 대규모 병렬 + 모듈형 솔버” 노선과는 경쟁이라기보다 다른 축입니다.

물론 SuperDex Lab이 “Training with Large Batches”, “Benchmarking” 문서를 갖고 있고 홈페이지가 “batched simulation / vectorized training”을 내세우므로 대규모 학습도 지향은 합니다. 문서에 수치가 없어 판단 불가라고 썼었는데, 🔬 이제 우리 측정치가 있습니다(§10.4): 32스레드 CPU 한 대에서 256환경 cart_pole 약 5만 sim FPS, ant 약 2만. 쓸모없는 수준은 전혀 아니지만 GPU 시뮬레이터가 내세우는 수치와는 자릿수가 다르고, 워커 16배에 6배라는 sub-linear 스케일링이 CPU 노선의 한계를 그대로 보여줍니다. Lab이 early preview인 것도 이 부분이 아직 덜 익었다는 신호로 읽힙니다.

12. 손(dexterous manipulation) 도메인에서 이게 갖는 의미 — 제 관점

여기부터는 문서가 아니라 제 해석입니다.

손 조작 연구에서 시뮬레이터가 늘 막히는 지점은 “손가락 끝에서 무슨 일이 일어나는지” 였습니다. 기존 엔진들은 접촉을 몇 개의 점 접촉과 그 합력으로 환원합니다. 강체 물체를 잡아 옮기는 데는 충분하지만, 촉각 센서를 다는 순간 이 추상화가 무너집니다 — GelSight든 DIGIT이든 자기식 센서든, 이들이 재는 것은 표면 위에 분포한 변형/응력장이지 합력 벡터가 아닙니다. 그래서 촉각 정책을 시뮬레이션에서 학습하려는 시도들은 대개 별도의 FEM 시뮬레이터를 붙이거나, 렌더링 트릭으로 촉각 이미지를 근사하거나, 아예 실물로 데이터를 모아야 했습니다.

SuperDex Physics가 traction field를 1급 출력으로 두고, 유연한 지문 자체를 soft articulation으로 모델링하겠다고 나선 것은 이 간극을 정면으로 겨냥한 설계입니다. “촉각 센서를 위한 별도 파이프라인”이 아니라 “물리 엔진의 접촉 해가 애초에 분포다”라는 접근은, 맞다면 촉각 sim2real의 구조 자체를 바꿉니다. 여기에 비볼록 SDF 접촉(볼록 분해로 뭉개지던 나사산·퍼즐 큐브 같은 기하)과 큰 안정 타임스텝이 더해지면, 지금까지 “시뮬로는 안 된다”고 여겨지던 in-hand 과제들의 문턱이 내려갈 여지가 있습니다.

다만 지금 시점에서 이건 전부 “여지”입니다. 촉각 센서 모델링의 실제 API도, sim2real 검증도, “user studies”의 수치도 문서에 없습니다. 데이터를 모을 teleop 모듈은 Q4 2026이고, 정책·데이터셋을 담당할 Learning 모듈은 시점조차 없습니다. 논문도 없습니다. 즉 엔진(가장 어려운 부분)은 나왔지만, 그것을 dexterous manipulation 연구 성과로 바꾸는 나머지 절반은 아직 로드맵 위에 있습니다. 지금 이 스택의 가치는 “쓰면 손 조작 연구가 된다”가 아니라, “접촉을 분포로 푸는 실제 동작하는 오픈소스 엔진이 Apache-2.0으로 처음 나왔다”에 있다고 봅니다. 그것만으로도 충분히 큰 사건이고, 판단은 Q4 2026 이후로 미루는 게 정직합니다.

13. 요약 — 실재하는 것과 약속된 것

지금 실재하는 것

  • Apache-2.0 오픈소스, pypi 휠(Python 3.12), Linux/Windows/macOS, C++ & Python API.
  • 암시적 적분(backward Euler 기본, 10–25ms 스텝 권장) + line search 붙은 quasi-Newton + island 기반 CPU 멀티스레딩.
  • Compliant contact: SDF + 표면 quadrature → 분포된 traction field, 점성 정규화 Coulomb 마찰.
  • Rigid / Soft / Articulated 액터는 stable, Shell / Rod / IK / Transmissions는 experimental — 🔬 단 experimental은 API 안정성 라벨이지 스텁이 아님(26/26 예제 실행 성공, §10.5).
  • 🔬 미분가능 시뮬레이션 — reverse-mode adjoint + step Jacobian(superdex.physics.diffsim), 유한차분 대조 4.5e-11. 문서에 전혀 없지만 실재함. 제약: fp64 + backward Euler + 강체/관절체 한정(§10.1).
  • 🔬 엔진 코어 완전 오픈소스 — 레포에 바이너리 블롭 0개, C++ 테스트 스위트까지 포함(§10.2).
  • Robotics SDK(URDF import, OSC·PD 컨트롤러, 로봇 합성), Studio GUI, Lab(Gymnasium + RLlib, early preview).
  • 문서화된 Python 예제 17개, 네트워크 연결식 디버거, state capture/restore.

아직 약속인 것

  • SuperDex Teleop (Q4 2026, UE5 + Quest 3 온디바이스) — 홈페이지 갤러리 영상을 만든 바로 그 도구.
  • SuperDex Learning (데이터셋·레시피·평가), tendon actuation, soft linkage/skin, domain randomization, abi3 휠, C++ 예제, 논문.

아직 검증 불가로 남는 것

  • “near real-world manipulation performance” user study — 수치·조건 없음, 논문 없음. 이건 소스를 봐도 알 수 없습니다.
  • 안정적 파지 — 🔬 우리도 못 했습니다(§10.6). 접촉 검출은 확실히 동작하지만(2764 접촉점 / 1677 N), 링키지 그리퍼로 물체를 쥐는 데는 실패했습니다.
  • 접촉을 통과하는 그래디언트 — adjoint는 매끄러운 궤적에서 검증했지만, 미분가능 시뮬레이션에서 정작 중요한 접촉 그래디언트는 검증하지 못했습니다.
  • GPU 백엔드의 실제 동작 — 코드는 있으나 켤 수 있는 빌드 설정이 제공되지 않아 이 릴리스에서는 시험 불가(§10.3).
  • 소스 빌드 — Clang ≥ 17 필요. 우리는 PyPI 휠만 검증했습니다.

갱신으로 해소된 것(원래 여기 있던 항목들)

  • 성능/스루풋 벤치마크 → 문서엔 여전히 없지만 🔬 우리가 측정(§10.4).
  • 미분가능 시뮬레이션 근거 없음 → 🔬 반박됨. 있습니다(§10.1).
  • 엔진 코어가 소스로 완전 공개인지 → 🔬 완전 공개 확정(§10.2).

이 갱신에서 얻은 교훈 하나: 초기 릴리스 프로젝트를 공개 문서만으로 평가하면 체계적으로 과소평가하게 됩니다. SuperDex는 미분가능 시뮬레이터인데 문서 62페이지 어디에도 그 말이 없었습니다. 반대로 문서가 자랑한 것 중 우리가 못 재현한 것(파지)도 있습니다. 문서는 프로젝트의 상한도 하한도 아니고, 그냥 다른 물건입니다. 소스를 clone하는 30분이 문서 62페이지보다 많은 것을 말해줬습니다.

교훈 둘: 같은 실패가 그림에서도 똑같이 일어났습니다. 갤러리 페이지의 주변 텍스트를 보고 캡션을 추정했고, 정작 이미지 파일을 열어보지 않아 9장 중 5장의 캡션이 틀렸습니다. 텍스트로 된 근거(문서·캡션 주변 문구)를 1차 자료로 착각한 것이 두 실패의 공통 원인입니다. 이미지의 1차 자료는 이미지 그 자체입니다. 앞으로 자동 수집한 그림은 본문에 넣기 전에 반드시 하나씩 열어서 확인하고, 그 안에서 눈으로 보이는 것만 캡션에 씁니다.

참고 링크