2.6 KiB
quad-spring — 스프링 물리 기반 지속 업데이트 프리미티브 (아이디어 메모)
상태: research 착수 전 — 사용자 노트를 그대로 옮겨 적은 아이디어 메모. 설계 논의는 아직 없었고, 사용자가 "모든게 완성된 후, 별도 모듈로 분화"라고 직접 못박은 아주 나중 항목.
아이디어
특정 Spring 설정을 받아 이전 상태와 비교해 스프링 물리 연산을 수행해주는 중간 핸들러(intermediate handler). StoreBind와 비슷한 구조로 별도 핸들러 하나를 만들 수 있을 것으로 보인다는 원문 메모(원문: "스토어바인드도 비슷하게 핸들러 하나 생성 가능할 수 있음").
기각된 직접 Tween 접근(과거 특수 bind key 모델, archive/tween-special-bind-key-reversed.md)과는
성격이 다르다 — 이건 Tween만으로 간결히 해결되지 않는 인터랙티브
디자인 상황(사용자 입력에 실시간으로 반응하는 감쇠/타겟 추적)을 위한
지속 업데이트되는 primitive를 염두에 둔 것. 확정된 Tween<T> 모델
(base/tween-plan.md)과는 별도 트랙으로 취급.
참고 구현
qwreey/spring.lua — 사용자 본인의 기존 구현. 사용 가능 여부(라이선스/의존성/quad 아키텍처와의 정합성) 확인이 필요하다고 원문에 명시.
구현 방향 후보 (미정)
두 갈래가 거론됐고 아직 어느 쪽도 확정되지 않았다:
- 엔진 중립 후킹:
quad-base가onStep류 프레임 단위 처리 후킹 인터페이스를 제공하고, 그 위에 스프링 primitive를 얹는 방식. 원문에서 사용자가 "기본 생각으론 후킹이 맞다 보긴 하는데"로 약하게 기운 방향이지만 확정은 아님. - 엔진별 개별 구현:
quad-roblox-spring처럼 엔진마다 각자 맞게 개발하는 방식.
또는 별도 방향으로 — Source<number>를 확장해 damping/target 등 스프링
파라미터를 가진, 자기 자신에 계속 emit하는 프리미티브를 primitive
레벨에 두는 안도 언급됨. 이 형태면 다른 :Compute 체인과 자연스럽게
엮일 수 있다는 게 사용자 관찰.
결정 시점: quad 코어가 충분히 개발되어 이런 pluggable 요소가 더 필요해지는 시점에 판단 — 지금은 방향을 좁히지 않고 후보만 기록.
우선순위
최하 — "모든게 완성된 후, 별도 모듈로 분화"라고 사용자가 직접 명시. M0 설계 게이트와 무관.