🧩Project SuperDex ① SuperDex Physics: Meta의 ‘접촉 우선’ 물리엔진

superdex

한 줄로 말하면

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)

📌 이 글은 Project SuperDex 시리즈의 ① SuperDex Physics 편입니다. 플랫폼은 여섯 개 모듈로 이뤄져 있는데(§1), 이번 글은 그중 백본인 물리엔진 하나에만 집중합니다. Robotics / Studio / Lab 등 나머지 모듈은 후속 편에서 따로 다룹니다.

그리고 이 글이 논문 리뷰가 아닌 이유: 리포지터리의 인용 안내가 아직 Citation details will be added here upon publication.입니다. 아직 논문이 없습니다. 그래서 이 글은 문서 정리입니다.

여기서 눈에 띄는 단어가 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이라는 점이 현재 스택의 가장 큰 구멍입니다.

한 가지 먼저 확인해 둘 것: 🔬 엔진 코어는 완전한 오픈소스입니다. 레포에 사전 빌드 바이너리(닫힌 라이브러리를 감싼 헤더 껍데기)가 하나도 없고, 뉴턴 솔버·Krylov 선형 솔버·접촉·island 분해까지 내부가 전부 열려 읽힙니다. 소스를 직접 clone해 확인했습니다.

이 시리즈에서 다룰 순서: 위 표가 곧 목차입니다.

① SuperDex Physics: 이번 글. 플랫폼의 백본인 물리엔진. 암시적 적분, compliant contact, SDF, actor 타입.
② SuperDex Robotics: 로봇 정의·합성, 컨트롤러/센서/액추에이터, URDF import. (예정)
③ SuperDex Studio: 씬·프리팹 저작 GUI. (예정)
④ SuperDex Lab: SuperDex Gym, Ray/RLlib, 배치 학습. (예정)
⑤ SuperDex Teleoperation / ⑥ SuperDex Learning: 아직 공개 전(Q4 2026 이후). 공개되면 다룹니다.

후속 편은 아직 쓰지 않았으므로 링크는 걸지 않습니다. 이번 글의 나머지 전부는 ① Physics 이야기입니다.

2. 로드맵: 지금 있는 것 ↔︎ 앞으로 올 것

위 표의 상태 뱃지를 한 단계 더 들어가 봅니다. 각 모듈 안에서 무엇이 이미 손에 잡히고 무엇이 아직 문장으로만 있는지입니다. 문서에서 근거를 찾을 수 있는 것만 정리합니다.

이미 공개된 것 (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

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

지금 손에 컵을 하나 쥐어 보세요. 그리고 손가락을 하나씩 떼어 보세요. 언제 컵이 미끄러지기 시작합니까?

여러분의 손가락은 컵 표면과 점에서 만나지 않습니다. 살이 눌리면서 손톱만 한 면적이 생기고, 그 면 위에서 압력은 가운데가 높고 가장자리로 갈수록 0으로 떨어집니다. 미끄러지기 시작하는 순간도 면 전체가 한꺼번에 미끄러지는 게 아닙니다. 가장자리부터 슬금슬금 미끄러지고 가운데는 아직 붙어 있습니다. 여러분이 “미끄러지려 한다”를 느끼고 손가락에 힘을 더 주는 것은, 바로 그 면 위에 퍼진 압력 분포의 변화를 읽었기 때문입니다.

이제 이걸 시뮬레이터에 순진하게 넣어 봅시다. 보통의 물리엔진은 두 물체가 닿으면 접촉점 하나(또는 몇 개)와 거기 걸리는 힘 벡터 하나를 만들어 줍니다. 합력은 맞습니다. 무게중심도 맞고 컵이 떨어지는지 아닌지도 대체로 맞습니다. 그런데 여러분이 방금 손끝으로 읽은 그 정보는 통째로 사라졌습니다. 압력 분포가 없으면 부분 미끄러짐도 없고, 촉각 센서가 무엇을 볼지도 계산할 수 없습니다. 손 조작 연구에서 제일 중요한 신호가 바로 그 지워진 부분입니다.

Overview가 밝히는 문제의식이 정확히 여기입니다. 기존 시뮬레이터가 범용 강체 동역학에 최적화된 반면, SuperDex Physics는 “multi-finger grasps, in-hand reorientation, and non-convex contact” 같은 까다로운 접촉을 안정적이고 고충실도로 푸는 것을 목표로 합니다. “contact-first”라는 말은 접촉을 나중에 얹는 게 아니라 접촉이 무엇인지부터 다시 정하고 그 위에 엔진을 세웠다는 선언입니다.

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

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

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

두 손이 조리대 위의 분홍색 천을 집어 들어 공중에서 반으로 접는다(홈페이지 Gallery, dexterous_multi_actor_manipulation 6초 발췌). 천이 손가락 사이에서 접히고 접힌 자국을 따라 주름이 잡히는 것, 그리고 놓인 부분이 중력으로 늘어지는 것이 그대로 보인다. 얇은 변형체를 두 손으로 다루는 장면이라는 것까지가 영상으로 확인되는 사실이고, 어떤 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)

이 절이 답하는 질문: 접촉이 잔뜩 있는 씬을 이 엔진은 왜 10–25 ms짜리 큰 스텝으로 돌려도 터지지 않는가.

먼저: 왜 시뮬레이터는 작은 스텝을 강요당하는가

용수철 하나를 생각합시다. 아주 뻣뻣한 용수철입니다. 1 mm만 눌러도 엄청난 힘으로 되밀칩니다.

순진한 방법(explicit/명시적 적분)은 이렇게 합니다. “지금 1 mm 눌려 있네? 그럼 힘이 이만큼이니, 이 힘으로 다음 순간 위치를 예측하자.” 문제는 그 “다음 순간”까지 가는 동안 용수철이 이미 원위치를 지나쳐 반대쪽으로 튀어나가 버린다는 것입니다. 그러면 반대 방향으로 더 큰 힘이 생기고, 다음 스텝엔 더 멀리 튕겨 나가고, 몇 스텝 만에 물체가 화면 밖으로 날아갑니다. 시뮬레이션이 “터진다(explode)”는 게 이겁니다.

막는 방법은 하나뿐입니다. 스텝을 잘게 쪼개는 것. 용수철이 원위치를 지나치기 전에 힘을 다시 계산하면 되니까요. 얼마나 잘게? 물체가 뻣뻣할수록 잘게. 그래서 explicit 계열 엔진은 뻣뻣한 접촉을 다루려면 500 Hz~2 kHz 같은 작은 스텝을 쓰고 싶어서가 아니라 안 그러면 터져서 씁니다. 이게 문서가 말하는 “stiffness-driven linear-stability restriction”입니다.

암시적(implicit) 적분은 질문을 뒤집습니다. “지금 힘으로 다음을 예측하자”가 아니라, “도착했을 때 그 자리에서 계산한 힘과 앞뒤가 맞는 위치는 어디인가?”를 묻습니다. 답을 이미 안다고 가정하고 자기모순이 없는 답을 찾는 것이죠. 그러면 용수철이 원위치를 지나치는 시나리오는 애초에 답으로 채택되지 않습니다. 스텝을 크게 잡아도 안 터지는 이유가 이것입니다.

공짜는 아닙니다. 대가가 둘입니다. ① 미지수가 방정식 양변에 다 들어가므로 매 스텝 비선형 방정식을 풀어야 합니다. 그게 다음 §5의 내용이고, 한 스텝이 훨씬 비싸집니다. ② backward Euler 같은 L-stable 방법은 안정성을 얻는 대가로 빠른 진동을 실제보다 더 빨리 죽입니다(수치적 감쇠). 튕김이 좀 심심해 보인다면 물성이 아니라 적분기 탓일 수 있습니다. (②는 수치해석의 일반적 성질이지 Docs가 명시한 서술은 아닙니다.)

Docs가 적은 것

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

일반화 좌표 q \in \mathcal{Q}, 속도 v = \dot q에 대해 라그랑지안. 여기서 “일반화”는 여러 종류의 자유도를 한 통에 담는다는 뜻입니다. 관절 각도, 강체의 위치와 자세, 변형체 메시의 노드 좌표는 물리적으로 전혀 다른 물건이지만, 솔버 입장에서는 전부 “미지수 벡터의 성분”이면 충분합니다. 그래서 그냥 “위치·속도”라 하지 않고 이렇게 부릅니다.

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

를 두고 오일러–라그랑주 방정식에 비보존력(소산) 을 더한 형태로 시스템을 기술합니다. 힘을 하나하나 나열하지 않고 운동 에너지 T와 퍼텐셜 에너지 U의 차이라는 스칼라 하나로 쓰는 이유는 실용적입니다. 새로운 힘을 추가하고 싶으면 U에 항 하나를 더하기만 하면 되고, 그 힘의 방향·야코비안은 미분으로 자동으로 따라 나옵니다. 힘의 종류마다 코드를 따로 쓰지 않아도 되는 것이죠. U에는 탄성·중력·접촉·제약·외력이 모두 들어갑니다. 회전·관절 포즈·로드 프레임처럼 \mathcal{Q}가 벡터공간이 아닌 경우에는 접공간에서 증분을 계산하고 타입별 업데이트로 다시 다양체로 사상합니다. 풀어 쓰면 회전은 그냥 더할 수 없다는 이야기입니다. 위치는 x + \Delta x가 여전히 위치지만, 회전 행렬 두 개를 성분끼리 더하면 회전 행렬이 아닌 것이 나옵니다. 그래서 솔버는 현재 자세 근처에서만 통하는 평평한 근사 공간(접공간)에서 작은 증분을 계산한 뒤, 그것을 회전에 맞는 방식으로 다시 곱해 얹습니다.

시간 적분은 암시적 multistep + Runge–Kutta 계열의 통합 패밀리이고 기본값은 backward Euler입니다. 문서 표현으로 “Explicit stages and fully coupled implicit Runge–Kutta methods are not supported”, 즉 대각 암시적(DIRK) 계열까지만 지원합니다. 여기서 “완전 결합(fully coupled) IRK”는 한 스텝 안의 여러 중간 단계를 하나의 거대한 연립방정식으로 동시에 푸는 방식이고, DIRK는 그것을 단계별로 하나씩 순서대로 푸는 방식입니다. 후자가 훨씬 싸고, 대신 정확도 차수를 조금 양보합니다. BDF2/BDF3도 지원하는데, 이쪽은 이전 스텝들의 결과를 재활용해 정확도를 올리는 방식(multistep)입니다. 공짜로 차수를 올리는 대신 과거 상태가 몇 개 쌓여 있어야 하므로, 시뮬레이션 시작 직후나 상태가 리셋된 뒤에는 과거가 없어 backward Euler로 시작했다가 차수를 올립니다.

여기서 incremental potential 개념이 등장합니다. 이름이 어렵지만 하는 일은 간단합니다. “방정식을 푸는 문제”를 “골짜기 바닥을 찾는 문제”로 바꾸는 것입니다.

방정식 r(q)=0을 푼다는 건 눈을 가리고 “값이 0이 되는 지점”을 더듬는 일이라, 지금 있는 곳이 답에 가까운지 멀어지는 중인지 알기 어렵습니다. 그런데 만약 r이 어떤 스칼라 함수 E의 기울기(r = \nabla E)라면, 문제는 “E가 가장 낮은 곳으로 내려가라”가 됩니다. 이건 훨씬 다루기 쉽습니다. 매 시도마다 “내가 아까보다 낮은 데 왔나?”를 물어보면 되고, 그 하나의 척도가 알고리즘을 늘 옳은 방향으로 붙잡아 줍니다. 각 스텝의 암시적 단계 잔차 r_i가 이런 퍼텐셜의 그래디언트일 때, 임의의 비선형 방정식 풀이가 아니라 최적화 문제로 바꿔 풀 수 있고 훨씬 강건해지는 이유입니다. 그런데 문서는 이게 항상 성립하지는 않는다고 솔직하게 적습니다. 모든 힘이 저런 “골짜기”를 만들어 주지는 않습니다. Newton–Euler 강체 관성은 정확한 incremental potential을 주지 않고, 접촉 마찰도 일부 항을 스테이지 시작 시점 값으로 고정(explicit 평가) 해야만 적분가능한 이산 모델이 됩니다.

이 단서를 그냥 넘기지 마세요. 골짜기 지도가 부분적으로만 존재한다는 뜻입니다. “아까보다 낮은 데 왔나?”라는 편리한 척도를 쓸 수 있는 구간이 있고, 그게 안 되는 구간에서는 다시 눈을 가리고 r=0을 더듬어야 합니다. 실제로 §5의 line search가 두 가지 방식(잔차 기반 / 퍼텐셜 기반)을 다 갖고 있는 이유가 바로 이것입니다.

실용적으로 중요한 문장은 이 대목입니다. 읽기 전에 A-stable이라는 말만 풀어 둡시다. “물리적으로 잦아드는 운동은 스텝을 아무리 크게 잡아도 시뮬레이션에서도 잦아든다”는 보장입니다. 실제로 감쇠되는 진동이 화면에서 점점 커지는 일은 없다는 뜻이지, 답이 정확하다는 보장은 아닙니다. 큰 스텝에서도 안 터진다는 것과 큰 스텝에서도 정확하다는 것은 완전히 다른 이야기입니다. L-stable은 여기에 더해 아주 빠른 진동을 특히 강하게 죽인다는 뜻이고, 그래서 앞서 말한 수치적 감쇠가 따라옵니다.

“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 계열 대비 스텝 수가 한 자릿수 배 적다는 뜻입니다.

다만 이 숫자만 보고 “20배 빠르다”고 읽으면 안 됩니다. 위에서 말한 대가가 여기서 청구됩니다. 한 스텝의 값이 훨씬 비쌉니다(뉴턴 반복 + 그 안의 선형계 풀이). 계산의 총량은 스텝당 비용 × 스텝 수이고, 이 곱이 실제로 유리한지는 씬마다 다릅니다. 그리고 그 곱을 판단할 벤치마크 수치가 문서에 하나도 없습니다. 큰 스텝은 그 자체로 자랑거리가 아니라, 스텝당 비용이 감당 가능할 때만 이득입니다.

그래서 사용자에게 무엇이 달라지는가: 씬을 튜닝할 때 “물체가 튀어 나가니 스텝을 줄이자”라는 반사적인 대응이 필요 없어집니다. 문서가 권하는 10–25 ms를 출발점으로 잡고, 스텝 크기는 안정성이 아니라 원하는 정확도·응답성 기준으로 고르면 됩니다. 대신 스텝 하나가 얼마나 걸리는지는 씬마다 직접 재봐야 합니다(문서에 벤치마크가 없습니다).

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

이 절이 답하는 질문: 큰 스텝을 쓰는 대신 매 스텝 무엇을 푸는가, 그리고 그것을 다 못 풀면 어떻게 하는가.

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

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

를 풀어야 합니다. 여기서 r_i가 잔차(residual) 입니다. “지금 후보로 들고 있는 다음 상태 q_i를 넣어 봤을 때, 운동방정식이 얼마나 안 맞는가”를 재는 벡터죠. 전부 0이면 그 후보가 답이고, 크면 아직 멀었다는 뜻입니다. §4에서 “도착지에서 앞뒤가 맞는 상태를 찾는다”고 한 그 찾기가, 구체적으로는 이 r_i를 0으로 만드는 q_i 찾기입니다. SuperDex Physics는 이를 line search를 동반한 quasi-Newton 법으로 근사적으로 풉니다.

용어부터 뜯어봅시다. 안개가 자욱한 산에서 골짜기 바닥으로 내려간다고 합시다.

뉴턴법은 이렇게 합니다. 발밑의 기울기뿐 아니라 지형의 휘어진 정도(곡률)까지 재서, “이 지형이 이대로 이어진다면 바닥은 저기다”라고 찍고 한 번에 그리로 점프합니다. 잘 맞으면 몇 걸음 만에 도착합니다. 문제는 그 곡률 지도를 만드는 값이 매우 비싸다는 것입니다. 이 지도가 야코비안 \partial r/\partial q, 즉 “미지수를 각 방향으로 조금씩 흔들면 잔차가 얼마나 변하는가”를 전부 모아 놓은 행렬입니다. 자유도가 n개면 원칙적으로 n \times n짜리이니, 만드는 값도 푸는 값도 커집니다. 자유도가 수천 개인 씬에서는 지도를 그리는 데 드는 시간이 걸음 값보다 큽니다.

quasi-Newton은 그래서 일부러 부정확한 지도를 씁니다. 값이 비싼 항, 특히 계산은 어려운데 방향 판단에는 별 도움이 안 되는 항을 그냥 버립니다. 걸음 하나하나는 뉴턴보다 못하지만, 지도 값이 싸므로 같은 시간에 훨씬 여러 걸음을 걷습니다.

그런데 부정확한 지도로 큰 점프를 하면 사고가 납니다. 찍은 지점이 바닥이 아니라 건너편 산비탈 중턱일 수 있거든요. 그러면 아까보다 더 높은 곳에 착지하고, 다음 걸음은 더 엉뚱해지고, 발산합니다. line search가 막는 사고가 정확히 이것입니다. 방향은 지도를 믿되 보폭은 믿지 않습니다. 일단 제안된 만큼 가보고, 아까보다 나아지지 않았으면 보폭을 반으로 줄여 다시 확인하고, 나아질 때까지 줄입니다. “방향은 근사, 보폭은 검증”이 이 조합의 정신입니다.

구조는 다음과 같습니다.

Island 분해: 한 스텝에서 서로 상호작용할 수 있는 액터들을 “island”로 묶어 분해합니다. 발상은 당연합니다: 탁자 이쪽 끝의 컵과 저쪽 끝의 접시는 서로 닿아 있지 않으므로, 둘을 같은 연립방정식에 넣을 이유가 없습니다. 접촉·제약으로 연결된 덩어리끼리만 묶어 따로 풀면 됩니다. 이득이 둘인데, 두 번째가 특히 중요합니다. ① 덩어리들을 워커 스레드에 나눠 줄 수 있고, ② 풀이 비용이 자유도 수에 초선형(super-linear)으로 늘기 때문에, 즉 크기가 2배면 값이 2배보다 더 비싸지므로, 큰 문제 하나를 작은 문제 여럿으로 쪼개는 것 자체가 이미 이득입니다. 손이 물체를 쥐는 순간 손과 물체가 한 island로 합쳐지고, 놓으면 다시 갈라집니다.
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…”

즉 기본 설정에서는 수렴하지 않아도 그냥 다음 스텝으로 넘어갑니다.

이걸 버그나 부실함으로 읽으면 곤란합니다. 의도적으로 맺은 계약입니다. VR 헤드셋을 쓰고 손을 움직이는 사람에게 프레임은 16 ms마다 반드시 나와야 합니다. 이때 솔버가 “아직 답이 충분히 정확하지 않으니 30 ms만 더 주세요”라고 하면 화면이 끊깁니다. 그 사이 물리가 조금 더 정확해졌다는 사실은 아무도 알아채지 못하고, 사람은 멀미를 합니다. 그래서 이 엔진은 “정확한 답을 늦게”가 아니라 “그럴듯한 답을 제때”를 택했습니다. 반복 예산이 떨어지면 지금까지 개선한 만큼만 들고 다음 스텝으로 갑니다. 대규모 RL 학습도 같은 계약이 유리합니다. 스텝 하나가 가끔 덜 정확한 것보다, 스텝 하나가 가끔 100배 오래 걸리는 쪽이 훨씬 안 좋습니다.

대가는 분명합니다. 반환된 스텝이 방정식을 만족한다는 보장이 없습니다. 에너지가 조금씩 새거나 제약이 미세하게 위반된 채로 시뮬레이션이 진행될 수 있고, 그 사실이 겉으로 드러나지 않습니다. 물체는 여전히 그럴듯하게 움직이니까요. 정확도가 필요한 사용자를 위해 문서는 state capture/restore로 미수렴 스텝을 재시도하는 커스텀 스테핑 경로를 안내합니다. sim2real을 신경 쓰는 사람이라면 이 기본값을 알고 있어야 합니다.

그래서 사용자에게 무엇이 달라지는가: 수렴 실패는 예외나 경고로 나타나지 않습니다. 화면에는 아무 일도 없고, 물체는 계속 그럴듯하게 움직입니다. 그래서 정확도가 중요한 용도라면 매 스텝 수렴 상태를 직접 물어보는 코드를 넣어야 하고, 뻣뻣한 변형체를 쓰면서 그 값이 나쁘면 반복 예산이나 스텝 크기를 조정하는 쪽으로 대응해야 합니다.

🔬 소스로 확인함(갱신): 문서가 말한 그대로이고, 생각보다 더 공격적입니다. 비선형 솔버의 기본 반복 예산이 한 자릿수로 매우 작고, 솔버 파라미터에 “미수렴 시 중단” 플래그는 아예 없습니다. 안전망은 휴리스틱한 폭발 제어뿐이고, 수렴 상태는 None < Converged < Stopped < Diverged 순으로 보고됩니다.

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

연산 장치: CPU 워커 풀, 그런데 GPU 경로가 꺼진 채 들어 있다

문서가 설명하는 병렬화는 전부 CPU입니다. island 분해로 독립적인 부분계를 만들고 워커 스레드 풀에 뿌리는 구조이고, 문서 62페이지 전체에 GPU·CUDA 언급이 한 번도 없습니다.

🔬 소스로 확인함(갱신): 공개된 빌드가 CPU 전용인 것은 맞습니다. 다만 원래 이 글은 레포에 소량 있는 CUDA를 렌더링 쪽으로 짐작했는데, 아니었습니다. 그것은 물리 솔버용 GPU 희소 선형대수 백엔드(PCG·GMRES·block-Jacobi 전처리기·BSR 희소행렬·희소 분해), 즉 암시적 적분기의 내부 루프입니다. 컴파일 스위치가 기본 0으로 꺼져 있고, 그것을 켤 수 있는 빌드 설정조차 제공되지 않아 이 릴리스에서는 동작 여부를 시험할 수 없습니다.

“GPU를 안 쓰는 엔진”과 “GPU 경로를 갖고 있으나 꺼둔 채 공개한 엔진”은 로드맵 해석에서 의미가 전혀 다릅니다. 지금의 CPU 노선은 영구적인 설계 선언이라기보다 1.0.0 공개 시점의 상태로 읽는 편이 맞아 보입니다.

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

이 절이 답하는 질문: 접촉을 어떻게 표현하길래 위의 두 가지(큰 스텝 · 뉴턴 풀이)가 애초에 가능해지는가.

이 엔진의 정체성이 걸린 부분입니다. 여기가 이 글의 심장이라 조금 천천히 갑니다.

압정과 손바닥: 왜 합력만으로는 부족한가

같은 힘 10 N으로 벽을 민다고 합시다. 한 번은 손바닥으로, 한 번은 압정 머리로. 합력은 똑같이 10 N입니다. 강체 시뮬레이터에게 이 둘은 완전히 같은 사건입니다. 그런데 벽에게는 전혀 같지 않습니다. 하나는 아무 일도 없고 하나는 구멍이 납니다.

차이는 힘의 총량이 아니라 그 힘이 면 위에 어떻게 퍼져 있는가입니다. 물리학에서 이 “단위 면적당 힘”을 traction(표면력)이라 부르고, 접촉면 위에서 그것이 위치마다 달라지는 것이 traction field, 즉 문서가 말하는 “spatial distributions of contact traction fields”입니다.

손으로 물건을 쥐는 문제에서는 이 분포가 곧 정보 그 자체입니다. §3의 컵을 다시 떠올려 보세요. 미끄러지기 직전에 가장자리부터 슬금슬금 미끄러지는 현상은 면 위의 위치마다 마찰 여유가 다르기 때문에 생깁니다. 접촉을 점 하나로 뭉개면 이 현상은 존재할 수가 없습니다. 촉각 센서도 마찬가지입니다. GelSight든 DIGIT이든, 그 센서가 출력하는 이미지는 표면 위에 분포한 변형이지 합력 벡터가 아닙니다.

그렇다고 합력만 내는 엔진 위에서 촉각 시뮬레이션이 불가능한 것은 아닙니다. TACTO나 Taxim처럼 PyBullet 같은 점접촉 강체 엔진 위에서 촉각 이미지를 만들어내는 시뮬레이터들이 실재합니다. 다만 그것들이 쓰는 것은 엔진이 계산한 접촉 물리가 아니라 접촉 기하입니다. 침투 깊이와 물체 메시를 받아 엔진 밖에 별도의 깊이 렌더링·광학 모델 레이어를 얹어 이미지를 합성하죠.

여기서 차이가 갈립니다. 그런 구성에서는 촉각 신호와 물체를 움직인 힘이 서로 다른 계산에서 나옵니다. 손끝이 눌려 생긴 압력 분포는 사후에 그려진 그림일 뿐, 물체의 운동에 되먹임되지 않습니다. 반면 traction field를 1급 출력으로 내는 엔진에서는 정책이 보는 신호와 물체를 실제로 민 힘이 같은 물건입니다. 분포가 곧 역학이고, 역학이 곧 관측입니다. “contact-first”가 마케팅이 아닌 이유가 여기 있습니다. 출력의 종류 자체가 다릅니다. (반례 언급과 이 대비는 Docs 밖의 제 판단입니다. Docs는 traction field가 “현실적인 촉각 센서 모델링을 가능케 한다”까지만 말합니다.)

그러면 어떻게 분포를 계산하는가: 세 부품

문제는 분포를 계산하는 게 쉽지 않다는 것입니다. 순진하게 하려면 두 물체의 표면이 정확히 어디서 어떻게 겹치는지 매 스텝 기하학적으로 알아내야 하는데, 이건 비싸고 까다롭고 물체가 변형하면 더 나빠집니다. SuperDex Physics는 세 부품의 조합으로 우회합니다.

부품 ① compliant contact: “닿았다/안 닿았다” 대신 “얼마나 눌렸다”. 강체 접촉을 정직하게 다루면 “절대 겹치면 안 된다”는 부등식 제약이 됩니다. 이건 스위치입니다. 닿기 직전엔 힘이 0, 닿는 순간 필요한 만큼의 힘이 갑자기 생깁니다. 이 불연속은 §4·§5에서 본 뉴턴 솔버가 가장 다루기 어려워하는 형태입니다(기울기가 정의되지 않는 절벽이니까요). compliant는 “고분고분한”이란 뜻이고, 여기서는 접촉면이 스프링처럼 조금 눌리는 것을 허용한다는 의미입니다. 실제 손끝 살이 눌리듯이요. 그러면 “겹침 깊이 → 힘”이 매끄러운 함수가 되고 절벽이 사라집니다. 문서가 이걸 “penalty regularization of an inequality constraint”(제약을 벌점으로 누그러뜨린 것)이자 동시에 “reduced model of local surface deformation”(국소 표면 변형의 축약 모델)이라고 양쪽으로 해석할 수 있다고 적은 이유입니다. 대가는 명확합니다. 물체가 실제로 조금 파고듭니다. 겉보기 아티팩트일 뿐 아니라, 얼마나 파고들지가 새로운 튜닝 파라미터가 됩니다.

부품 ② SDF: 겹침 깊이를 싸게 아는 법. 그럼 “얼마나 눌렸는지”는 어떻게 잽니까? signed distance field(부호 있는 거리장)는 공간의 모든 점에 대해 “이 물체 표면까지의 거리”를 미리 적어 둔 지도입니다. 부호가 붙어서, 바깥이면 양수·안이면 음수입니다. 등고선 지도에서 해발고도를 읽듯 위치만 넣으면 값이 나오죠. 그러면 침투 깊이는 그냥 음수 값의 크기이고, 미는 방향(법선)은 그 지도의 기울기입니다. 복잡한 기하 계산이 한 번의 지도 조회로 바뀝니다.

부품 ③ quadrature: 면을 유한한 점으로 대신하기. 마지막 문제. traction은 면 위에 연속으로 퍼진 양이고, 총 힘을 얻으려면 그걸 면 전체에 대해 적분해야 합니다. 컴퓨터는 연속 적분을 못 하므로, 면 위에 잘 고른 유한 개의 대표점을 뿌리고 각 점의 값에 담당 면적을 곱해 더합니다. 이 “적분을 대표점 합으로 근사하는 기법”의 이름이 quadrature(구적법)입니다. 어렵게 들리지만 하는 일은 표면에 압력 센서를 격자로 붙이고 전부 읽어 합치는 것입니다.

셋을 이으면 문장 하나가 됩니다. 한쪽 표면에 뿌린 quadrature 점들이 상대의 SDF를 조회해 각자 얼마나 눌렸는지 읽고, compliant 모델이 그 깊이를 traction으로 바꾸고, 그 값들의 집합이 곧 접촉면 위의 분포다. 점 접촉의 합력은 이 분포를 다 더하면 나오는 부산물일 뿐, 출발점이 아닙니다.

이제 Docs의 첫 문단을 읽으면 전부 해독됩니다.

“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.”

그래서 사용자에게 무엇이 달라지는가: 침투를 허용한다는 설계 결정은 사용자에게 파라미터로 돌아옵니다. 접촉 강성(penalty 계수)을 올리면 파고드는 양은 줄지만 계가 뻣뻣해져 솔버가 힘들어지고, 낮추면 솔버는 편해지지만 손가락이 물체에 눈에 띄게 잠깁니다. 여기에 SDF 격자 해상도(아래 표)와 마찰의 falloff velocity까지, “물리 파라미터가 아닌데 물리 결과를 바꾸는 손잡이”가 여러 개 생긴다는 것이 이 모델을 쓰는 값입니다.

바로 위 문단이 말하는 분포가 실제로 그려지는 장면(홈페이지 Gallery, contact_visualization 6초 발췌). 유연한 손끝이 배(pear)에 닿는 순간, 접촉면에서 수많은 가는 선이 부채꼴로 뻗어 나온다. 화살표 하나가 아니라 면 위에 흩뿌려진 다발이라는 점이 핵심이다. 손끝이 눌릴수록 다발이 짙고 넓어지고, 떨어지면 사라진다. 합력 벡터 하나만 내는 엔진이라면 이 그림은 애초에 그릴 것이 없다.

Collider / Colliding: 왜 역할을 비대칭으로 나눴나

방금 설명에 빈틈이 하나 있습니다. 양쪽 다 SDF를 갖고 양쪽 다 점을 뿌리면 되지 않을까요? 순진하게는 그게 맞고, 대칭적이라 아름답기까지 합니다. 문제는 값입니다.

SDF는 미리 계산해 둔 지도라서 싼 것입니다. 그런데 천이나 젤리처럼 매 스텝 모양이 변하는 물체는 지도를 매 스텝 다시 그려야 합니다. 지도 제작비가 조회비를 압도해 버립니다. 반면 점을 뿌려 조회하는 쪽은 물체가 변형하든 말든 값이 똑같습니다. 점이 따라 움직일 뿐이니까요.

그래서 역할을 나눕니다. 딱딱해서 지도가 안 변하는 쪽이 지도를 제공하고, 물렁해서 지도가 계속 변하는 쪽이 점을 뿌려 찔러본다. 이것이 아래 비대칭의 전부입니다.

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, 각각 threadedrodandnut_low·networkcable_low 6초 발췌). (좌) 빨간 손잡이 너트가 나사산이 새겨진 로드 위에서 회전하며 내려간다. 카메라가 붙어 있어 골이 파인 나사산과 너트 안쪽이 서로 물리는 것이 보인다. (우) 로봇 손이 파란 랜 케이블 커넥터를 랙마운트 스위치의 포트에 맞춰 밀어 넣는다. 나사산도 RJ45 포트도 볼록 분해로는 뭉개지기 딱 좋은 기하이고, 위에서 설명한 격자 SDF 접촉이 겨냥하는 것이 정확히 이런 씬이다.

마찰과 감쇠

여기서도 같은 이야기가 반복됩니다: 절벽을 없애는 것. 교과서의 Coulomb 마찰에는 절벽이 있습니다: 미끄러지지 않는 동안(정지마찰) 마찰력은 “미끄러지지 않게 하는 데 필요한 만큼 무엇이든” 취하는 미결정 값이고, 미끄러지기 시작하면 갑자기 \mu N으로 확정되면서 방향도 뒤집힙니다. 속도 0을 사이에 두고 부호가 점프하죠. 앞서 본 접촉의 불연속과 정확히 같은 문제입니다.

점성 정규화는 그 절벽을 비탈로 바꿉니다. “속도 0에서 완전히 붙어 있다” 대신 “아주 느리게 움직일 때는 마찰력이 속도에 비례한다”로 바꾸는 것, 말하자면 정지마찰을 아주 뻑뻑한 꿀로 근사하는 셈입니다. 겉보기엔 붙어 있지만 사실 아주 천천히 흐릅니다.

Coulomb 마찰을 정적 영역의 점성 정규화(viscous regularization) 로 모델링합니다. falloff velocity 파라미터가 그 “꿀 구간”의 폭을 정합니다. 이 속도보다 느리게 미끄러지는 동안은 마찰력을 속도에 비례해 키우고, 이 속도를 넘으면 통상의 미끄럼 마찰 \mu N으로 넘어간다는 경계값입니다. 대가: 완벽한 stiction이 아닙니다. 경사면에 가만히 둔 물체가 아주 느리게 흘러내릴 수 있고(미소 크리프), 이 값을 너무 작게 잡으면 다시 절벽에 가까워져 솔버가 힘들어집니다.
법선 점성 감쇠가 반발(restitution)을 지배합니다. 문서는 강체 점 충돌에 대해 속도 의존 반발계수(CoR) 가 나온다는 점을 명시하고, 감쇠계수를 CoR로부터 보정하는 닫힌 형태 공식(양방향)을 제공합니다.
접촉 쌍의 마찰·감쇠 계수는 두 액터 값의 기하평균. 다만 collider가 static이면 penalty 계수와 falloff 속도는 colliding 쪽 값을 씁니다.
법선 정렬 기각: SDF가 격자에 저장된 근사 지도라는 점의 대가가 여기서 드러납니다. 얇은 물체나 날카로운 모서리 근처에서는 지도가 가리키는 “바깥 방향”이 실제 표면의 방향과 꽤 어긋날 수 있고, 그대로 믿으면 물체가 옆으로 튀거나 안쪽으로 빨려드는 힘이 생깁니다. 그래서 두 방향이 크게 어긋난 접촉은 그 조회 결과를 믿지 않고 기각하거나 소산 응답을 감쇠시킵니다. “지도가 이상한 값을 주면 그 칸은 안 쓴다”는 안전장치입니다. 단, shell·rod는 colliding 쪽 법선 자체가 정의되지 않는 표현이라 비교할 대상이 없고, 따라서 이 로직이 구조상 꺼집니다. 결함이라기보다 당연한 귀결이지만, 결과적으로 얇은 물체에서는 이 안전장치가 없다는 사실은 알고 있어야 합니다.
파이프라인은 broad phase → narrow phase → force & Jacobian assembly 3단계입니다. broad phase는 “닿았을 리 없는 쌍을 싸게 걸러내는” 단계로, 각 물체를 축에 정렬된 상자(AABB) 하나로 감싸 상자끼리도 안 겹치면 그 쌍은 바로 버립니다. 살아남은 쌍만 narrow phase로 넘어가 앞서 본 실제 계산(quadrature 점 → 상대의 SDF 조회 → traction)을 하고, 마지막 단계에서 그 결과를 힘 벡터와 야코비안 행렬의 해당 자리에 채워 넣습니다. 이 마지막 산출물이 §5의 뉴턴 반복이 먹는 재료입니다.

flowchart LR
  A["broad phase<br/>AABB 겹침 검사"] --> B["narrow phase<br/>quadrature 점 → 상대 SDF 조회<br/>→ 침투 깊이·법선 → traction"]
  B --> C["force &amp; Jacobian assembly<br/>힘 벡터·야코비안에 기여분 누적"]
  C --> D["§5 뉴턴 반복의 입력"]

그래서, 미분가능한가? 두 개의 “differentiable”을 구분하자

이 단어가 헷갈리는 이유는, 물리 시뮬레이션에서 “미분가능하다”가 서로 다른 두 가지를 가리키기 때문입니다.

① 접촉력의 매끄러움 (Docs가 말하는 것). 위 인용문의 “smooth, differentiable contact forces suitable for implicit time integration and optimization-based solvers” 는 접촉력 f_c가 상태 q에 대해 C¹ 급이라는 뜻입니다. 왜 이게 필요한가? 암시적 적분은 매 스테이지마다 r(q)=0을 뉴턴 계열로 풉니다. 뉴턴은 \partial r/\partial q를 필요로 하고, 그 안에 접촉 항의 야코비안 \partial f_c/\partial q가 들어갑니다. 강체 비관통을 부등식 제약(LCP/원뿔 계획법)으로 처리하는 엔진에서는 이 항이 접촉 켜짐/꺼짐 경계에서 불연속이라 뉴턴이 진동합니다. compliant contact는 침투를 허용하고 SDF 위에서 힘을 매끄러운 함수로 정의해 그 불연속을 없앱니다. 즉 여기서의 미분가능성은 솔버가 수렴하기 위한 조건이지, 사용자가 그래디언트를 받아 쓰기 위한 기능이 아닙니다.

한 문장으로 못 박자면, ①은 솔버가 다음 발을 어디 디딜지 보려고 발밑을 더듬는 매끄러움입니다. 앞을 향한 것이고, 매 스텝 안에서 끝납니다.

② 시뮬레이션 전체에 대한 그래디언트 (differentiable simulation). 이쪽은 방향이 반대입니다. 끝난 결과에서 원인으로 거슬러 올라갑니다. “공이 목표보다 왼쪽에 떨어졌다. 20스텝 전 처음 던진 속도를 어느 쪽으로 얼마나 바꿨어야 했나?” 같은 물음이죠. 롤아웃 q_N = \Phi(q_0, v_0, \theta) 전체를 하나의 함수로 보고 손실 L(q_N)에 대해 \partial L/\partial q_0, \partial L/\partial \theta를 얻는 것, 스텝을 거슬러 올라가며 연쇄법칙을 적용하는 reverse-mode adjoint입니다. ①이 성립해야 ②가 잘 정의되지만, ①이 있다고 ②가 자동으로 제공되지는 않습니다. ②는 별도로 구현해서 API로 내놓아야 하는 물건입니다.

📄 문서 근거 (최초 판단): Docs가 말한 것은 명백히 ①입니다. 그리고 ②에 해당하는 API는 physics 문서 전 페이지(62개)를 받아 검색한 범위에서 언급이 전혀 없습니다. differentiable이라는 단어 자체가 Contact 페이지의 저 한 문장 외에는 나오지 않고, adjoint·autodiff·gradient of the simulation 류 표현도 없습니다. → “미분가능 시뮬레이터”로 분류하기엔 근거 부족.

🔬 소스 근거 (정정): 틀렸습니다. ②도 있습니다. 소스에는 완전한 reverse-mode adjoint 미분 시뮬레이터와 forward step Jacobian이 들어 있고, 공개된 휠에 superdex.physics.diffsim으로 노출돼 있습니다. 출력별 backward 함수와 Lie ↔︎ 쿼터니언/회전벡터 그래디언트 변환기까지 갖춰져 있습니다. 실제로 돌려 중앙 유한차분과 대조해 일치하는 것도 확인했습니다.

단, 조건이 붙습니다. 실질적으로 배정밀도(fp64) 전용이고 backward Euler 전용이며, API가 “Differentiability is only supported for rigid and articulated actors” 라고 명시합니다. 즉 이 엔진의 자랑인 soft·shell·rod는 미분 대상이 아닙니다. 그리고 우리가 확인한 것은 매끄러운 궤적이지 접촉을 통과하는 그래디언트가 아닙니다. 미분가능 시뮬레이션에서 정작 어려운 부분이 그쪽인데 말이죠.

문서 62페이지에 adjoint·autodiff가 0회 등장한다는 사실은 여전히 참입니다. 즉 이건 검색이 부실했던 게 아니라 엔진이 자기 1급 기능 하나를 문서에 안 적어둔 것입니다. 이 정도가 미문서화라면 다른 미문서화 기능도 있다고 가정하는 편이 맞습니다.

한 스텝 따라가기: §4·§5·§6이 맞물리는 곳

세 절을 따로 읽으면 각각은 이해되지만 서로 어떻게 물려 있는지가 잘 안 잡힙니다. 그래서 시뮬레이터가 t에서 t+\Delta t로 가는 한 스텝 동안 일어나는 일을 순서대로 따라가 봅니다.

다음 상태를 미지수로 놓습니다. 암시적 적분이므로 “지금 힘으로 다음을 예측”하는 게 아니라, 아직 모르는 다음 상태 q_i 자체가 풀어야 할 대상입니다(§4).
그 미지수가 만족해야 할 잔차 r_i(q_i;\,Y_i^0,\,\Delta t_i)=0을 세웁니다. 관성·탄성·중력·제약·접촉이 전부 이 하나의 식 안에 들어갑니다. 문서가 U에 접촉을 포함시킨다고 적은 대목이 여기서 효력을 발휘합니다(§4).
후보를 하나 들고 접촉을 계산합니다. 현재 후보 q_i 기준으로 broad phase가 후보 쌍을 걸러내고, colliding 쪽 quadrature 점들이 collider의 SDF를 조회해 침투 깊이와 법선을 읽고, compliant 모델이 그것을 traction 분포로 바꿉니다(§6).
그 접촉력이 다시 잔차에 들어갑니다. 여기가 핵심입니다. 접촉력은 아직 모르는 다음 상태에 의존하므로, 접촉이 적분의 바깥이 아니라 안쪽에 있습니다. 접촉을 먼저 풀고 적분하는 구조가 아닙니다.
그래서 반복이 필요합니다. quasi-Newton이 야코비안 근사로 방향을 정하고, line search가 보폭을 검증하며 잔차(또는 incremental potential)가 줄어드는 지점으로 이동합니다(§5).
반복할 때마다 3번이 다시 일어납니다. 후보가 바뀌었으니 침투 깊이도 접촉면도 달라집니다. SDF 조회와 quadrature 합산은 스텝당 한 번이 아니라 반복당 한 번입니다. 접촉이 이 엔진에서 값비싼 이유이고, 동시에 접촉력이 매끄러워야만 하는 이유입니다. 반복마다 튀는 값을 주면 뉴턴이 수렴하지 못합니다.
수렴하면 채택하고, 못 하면 정해진 반복 횟수에서 끊고 그대로 진행합니다(기본 동작). island 단위로 나뉜 문제들이 워커 스레드에서 이 과정을 각자 수행합니다(§5).

“접촉이 적분의 안쪽에 있다”, 이 문장 하나가 세 절의 요약입니다. 큰 스텝을 쓸 수 있는 것도(§4), 매 스텝 비선형 풀이를 해야 하는 것도(§5), 접촉력이 반드시 매끄러워야 하는 것도(§6) 전부 여기서 따라 나옵니다. 반대로 explicit 계열 엔진에서는 접촉이 적분의 바깥에서 한 번 계산되고 끝나므로, 세 가지 모두 성립하지 않습니다.

(이 순서는 Dynamics 문서의 암시적 스테이지 서술, Solvers 문서의 “매 스테이지마다 r_i=0을 quasi-Newton으로 푼다”·island 병렬·미수렴 시 진행 기본값, Contact 문서의 3단 파이프라인을 이어 붙인 것입니다. 각 조각은 문서에 있지만, 이렇게 한 줄로 꿴 서술 자체는 Docs에 없는 제 정리입니다.)

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

왜 종류를 나누는가: 한 가지로 다 하면 안 되나

“모든 물체를 아주 잘게 쪼개서 하나의 방식으로 풀면 되지 않나?” 자연스러운 물음이고, 답은 “되긴 되는데 값이 감당이 안 된다”입니다.

책상 같은 강체를 생각해 봅시다. 정직하게 하려면 이것도 원자 덩어리이니 잘게 쪼개 각 조각의 변형을 풀어야겠죠. 하지만 우리가 알고 싶은 건 책상이 어디에 어떤 자세로 있는가뿐이고, 그건 숫자 6개(위치 3 + 방향 3)면 끝납니다. 수만 개의 변형 자유도를 풀어 6개를 얻는 건 낭비입니다. 관절 로봇도 같습니다. 링크마다 6자유도를 주고 “이 둘은 항상 붙어 있어야 해”라는 제약을 잔뜩 거는 대신, 관절 각도만 변수로 삼으면(문서의 reduced coordinate) 제약이 애초에 위반될 수가 없습니다. 팔꿈치가 빠질 걱정을 안 해도 되는 것이죠.

반대로 천을 생각해 봅시다. 천은 변형하니 잘게 쪼개야 합니다. 그런데 볼륨 방식(사면체로 속을 채우는 방식)으로 천을 채우면 문제가 생깁니다. 천은 두께가 사실상 0입니다. 두께 방향까지 사면체로 채우려면 종잇장처럼 납작하게 찌그러진 요소를 만들어야 하고, 이런 요소는 수치적으로 아주 나쁩니다(계산이 불안정해지고, 안정성을 지키려고 스텝을 줄이면 §4에서 피하려던 문제로 되돌아갑니다). 게다가 천의 물리에서 정말 중요한 건 늘어남이 아니라 굽힘인데, 두께가 없으면 볼륨 요소로는 굽힘 강성을 표현할 방법 자체가 없습니다.

그래서 차원을 낮춰 표현합니다. 부피가 있는 변형체는 볼륨(Soft), 얇은 면은 면 그대로(Shell), 실·힘줄처럼 가는 것은 선으로(Rod). 각 표현이 자기 물리에 맞는 최소한의 자유도만 갖습니다. 이게 문서가 말하는 multi-physics의 실체입니다. 신기한 물질을 여럿 지원한다는 뜻이 아니라, 자유도 표현이 다른 것들을 하나의 솔버가 함께 푼다는 뜻입니다. (위 설명 중 “왜 나누는가”의 이유는 유한요소 해석의 일반 상식이고, Docs가 이 이유를 명시적으로 적어둔 것은 아닙니다.)

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.” 라고 명시돼 있습니다.

서로 다른 actor 타입이 한 씬에 섞이는 두 장면(홈페이지 Gallery, 각각 sponge_low·deformable_fingertips_rigid_geometry 6초·4.5초 발췌). (좌) 두 로봇 손이 개수대 위에서 파란 접시를 잡고 노란 스펀지로 문지른다. 스펀지가 접시 면에 눌려 모서리가 접시를 따라 꺾이는 것이 보인다. (우) 무른 손끝이 알루미늄 프로파일 모서리를 누르는데, 손끝이 내부의 점 다발로 그려져 있고 눌린 쪽 점들이 붉게, 덜 눌린 쪽이 푸르게 표시된다. 손끝 하나가 점 하나가 아니라 수백 개의 표본으로 이산화돼 있다는 사실이 눈으로 확인되는 컷이다.

얇은 면이 주인공인 두 장면(홈페이지 Gallery, 각각 fruitbag_low·cerealbox_low 6초 발췌). (좌) 손이 반투명한 녹색 비닐봉지의 손잡이를 들어 올리면 안에 담긴 오렌지·사과·바나나의 무게로 봉지가 과일 모양대로 늘어지고 손잡이 쪽에 주름이 모인다. 정지 프레임에서 도마로 잘못 읽었던 물체가 사실은 봉지였다. (우) 손이 시리얼 상자를 기울이자 벌어진 종이 덮개가 그 자세를 유지한 채 낟알들이 그릇으로 쏟아진다. 두께에 비해 넓은 얇은 면(봉지·종이 벽)과 알갱이 다수가 함께 나오는 씬이지만, 이것이 실제로 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. Newton / MuJoCo / Isaac 사이에서 어디에 서 있나

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

축	SuperDex Physics (문서 근거)	대비
연산 장치	📄 CPU 워커 스레드 풀 + island 병렬화(문서 62페이지에 GPU·CUDA 언급 0회). 🔬 단 소스에는 GPU 희소 선형 솔버 백엔드가 꺼진 채 들어 있음(§5 끝).	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. 문서에 공표된 성능 수치는 없음.	Isaac Lab·MuJoCo Playground는 훨씬 성숙.
에셋 포맷	자체 포맷(`.superdex_bot`, `.mochiscene`/`.mochiprefab`, `.mochi.h5`) + URDF import.	Newton/Isaac은 OpenUSD 중심. 생태계 상호운용성은 SuperDex가 불리.
미분가능성	🔬 있음(정정): reverse-mode adjoint + step Jacobian. 단 fp64 + backward Euler + 강체/관절체 한정. 📄 문서엔 언급 0회(§6 끝).	Newton/Warp은 미분가능 시뮬레이션 경로가 명시적으로 존재.
개방성	Apache-2.0 (일부 제3자 에셋은 비상업 한정).	—

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

물론 SuperDex Lab이 “Training with Large Batches”, “Benchmarking” 문서를 갖고 있고 홈페이지가 “batched simulation / vectorized training”을 내세우므로 대규모 학습도 지향은 합니다. 다만 문서에 성능 수치가 하나도 없어 그 지향이 어디까지 닿는지는 문서만으로 판단할 수 없습니다. 레포에 배치 환경 벤치마크와 MuJoCo 유래 환경이 함께 들어 있으니, 필요하면 각자 자기 하드웨어에서 재보는 수밖에 없습니다. Lab이 early preview인 것도 이 부분이 아직 덜 익었다는 신호로 읽힙니다. (Lab은 이 시리즈의 후속 편에서 따로 다룹니다.)

10. 손(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 이후로 미루는 게 정직합니다.

11. 요약: 실재하는 것과 약속된 것

이 글의 범위인 SuperDex Physics 기준입니다.

지금 실재하는 것

암시적 적분(backward Euler 기본, BDF2/3, 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 안정성 라벨이고, 해당 기능들은 소스에 실제 구현으로 존재합니다.
🔬 미분가능 시뮬레이션: reverse-mode adjoint + step Jacobian(superdex.physics.diffsim). 문서에 전혀 없지만 실재함. 제약: fp64 + backward Euler + 강체/관절체 한정.
🔬 엔진 코어 완전 오픈소스: 사전 빌드 바이너리 없이 솔버 내부까지 열려 있고, C++ 테스트 스위트까지 함께 옵니다.
문서화된 Python 예제 17개, 네트워크 연결식 디버거, state capture/restore, 암시적 PD pose controller.
(Physics의 소비자 계층인 Robotics SDK · Studio GUI · Lab도 이미 공개돼 있습니다. 이 시리즈의 후속 편에서 다룹니다.)

아직 약속인 것

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: 수치·조건 없음, 논문 없음. 이건 소스를 봐도 알 수 없습니다.
성능: 문서에 공표된 수치가 하나도 없습니다. 스텝당 비용이 비싼 대신 스텝 수가 적은 이 엔진이 총합에서 유리한지는 각자 재보는 수밖에 없습니다.
안정적 파지: 접촉 검출과 다관절 손 제어는 확인했지만, 닫힌 링키지 그리퍼로 물체를 안정적으로 쥐는 데는 이르지 못했습니다(Transmissions 경로가 필요해 보입니다).
접촉을 통과하는 그래디언트: adjoint는 매끄러운 궤적에서 확인했을 뿐, 미분가능 시뮬레이션에서 정작 중요한 접촉 그래디언트는 확인하지 못했습니다.
GPU 백엔드의 실제 동작: 코드는 있으나 켤 수 있는 빌드 설정이 제공되지 않습니다.

갱신으로 해소된 것

~~미분가능 시뮬레이션 근거 없음~~ → 반박됨. 있습니다.
~~엔진 코어가 소스로 완전 공개인지~~ → 완전 공개 확정.

라이선스: 쓰기 전에 반드시 확인할 것

first-party 소스는 Apache-2.0, 에셋·문서는 CC-BY-4.0입니다. 단 superdex_mesh_cli만 GNU GPL v3로 별도 배포되고(OCCT/CGAL 의존), pip install superdex를 하면 이 GPLv3 컴포넌트가 Apache-2.0 컴포넌트들과 함께 설치됩니다. 그리고 README가 명시적으로 경고합니다. “Certain third party dependencies and third party assets in this repo are licensed for non-commercial/academic uses only.” 실제로 일부 로봇 손 에셋은 벤더 자체 약관(예: “Wonik Robotics Asset License”)을 달고 있고, 벤치마크 에셋은 MuJoCo 유래라 또 다른 라이선스입니다. 상업적 사용을 생각한다면 컴포넌트별로 개별 확인이 필요합니다.

교훈 하나: 초기 릴리스 프로젝트를 공개 문서만으로 평가하면 체계적으로 과소평가하게 됩니다. SuperDex는 미분가능 시뮬레이터인데 문서 62페이지 어디에도 그 말이 없었습니다. 문서는 프로젝트의 상한도 하한도 아니고, 그냥 다른 물건입니다.

교훈 둘: 같은 실패가 그림에서도 일어났습니다. 갤러리 주변 텍스트로 캡션을 추정하고 이미지 파일을 열어보지 않아 9장 중 5장이 틀렸습니다. 텍스트로 된 근거를 1차 자료로 착각한 것이 두 실패의 공통 원인입니다. 이미지의 1차 자료는 이미지 그 자체입니다.

교훈 셋: 그 뒤 이미지를 전부 열어 캡션을 다시 썼는데도 한 장이 또 틀렸습니다. 비닐봉지를 도마로 읽었습니다. 갤러리 원본이 동영상인데 우리가 가진 것은 그중 한 프레임이었고, 하필 봉지가 납작하게 접힌 채 놓여 있던 순간이었기 때문입니다. 그래서 이 글의 갤러리 그림은 모두 핵심 순간을 담은 짧은 영상 발췌로 교체했습니다. 정지 프레임의 1차 자료는 그 프레임이 잘려 나온 영상입니다.

참고 링크

Project SuperDex · Roadmap · Get Started
SuperDex Physics Docs: Overview · Dynamics · Solvers · Contact · Actors · Examples
SuperDex Robotics · SuperDex Studio · SuperDex Lab
GitHub: facebookresearch/project_superdex
🔬 소스 확인 기록: 비공개(private) 실험 레포 curieuxjy/project_superdex, CODE-NOTES.md(문서 주장 ↔︎ 소스 파일:라인 매핑)와 EXPERIMENTS.md(설치·실행 기록). 외부 열람 불가입니다.
관련 글: 🧩Newton 물리엔진 · 🧩Newton Physics Video