Setiap istilah dalam master plan GREYMOUTH — apa benda dia, analogi paling senang, dan peranan dia dalam projek kita. Baca sekali, plan tu terus masuk akal.
← Balik ke Master PlanSebelum masuk istilah satu-satu, ini keseluruhan cerita GREYMOUTH dalam satu ayat: kita ajar satu "otak" kecil cara mengawal otot badan patung supaya dia boleh berdiri, berjalan dan bertahan bila ditolak — belajar dalam simulator laju di GX10, lepas tu otak tu dipindahkan masuk browser.
Semua term kat bawah ni cuma nama-nama untuk setiap kotak dalam rantaian di atas.
Bahagian "otak" — macam mana patung tu belajar bergerak.
Cara melatih AI dengan cuba-jaya + ganjaran. AI buat aksi rawak, kalau hasilnya bagus dia dapat "markah" (reward), kalau teruk markah dipotong. Ulang berjuta-juta kali — lama-lama dia jumpa sendiri strategi yang dapat markah paling tinggi. Tiada siapa tulis peraturan "macam mana nak berdiri"; dia temui sendiri.
Macam ajar budak main basikal. Ko tak boleh terangkan dengan ayat macam mana nak balance — dia kena jatuh 200 kali, dan setiap kali yang dia tak jatuh, badan dia "ingat" apa yang berjaya. RL = jatuh 10 juta kali dalam simulator, tapi sebab simulator laju, 10 juta kali tu ambil beberapa hari je.
Kita guna RL untuk ajar patung berdiri, berjalan, dan recover bila ditolak. Reward = "kekal berdiri + gerakan mirip mocap manusia".
Hasil akhir RL — satu neural network yang dah pandai. Input: keadaan badan sekarang (posisi sendi, kelajuan, arah graviti). Output: arahan untuk setiap otot/sendi. Saiznya kecil je — beberapa ratus KB.
Refleks otak kecil (cerebellum) manusia. Bila ko tersadung, ko tak *fikir* "aku patut hulur kaki kanan 30cm ke depan" — refleks tu jawab sendiri dalam milisaat. Policy = refleks tu, dalam bentuk fail.
Policy inilah SATU-SATUNYA benda yang berpindah dari GX10 masuk browser. Semua tools latihan yang berat tinggal kat GX10; browser cuma bawa otak kecil ni.
Struktur matematik yang jadi bahan binaan policy: lapisan-lapisan nombor (weights) yang menukar input jadi output. MLP = jenis paling ringkas, 2–4 lapisan. Bukan ChatGPT-class — beribu kali lebih kecil.
Kalau ChatGPT tu otak manusia penuh, MLP kita ni saraf lutut je — kecil, pantas, satu kerja sahaja. Sebab tu dia boleh lari 30 kali sesaat dalam phone tanpa masalah.
Sasaran kita: MLP ~256×256 neuron, inference bawah 2ms. Kecil = lightweight = boleh run kat web, itu syarat projek ni.
Dua fasa hidup satu model. Training = proses belajar (berat, perlu GPU power, ambil hari/minggu). Inference = guna model yang dah siap belajar (ringan, milisaat sahaja).
Training = 4 tahun belajar memandu + lesen. Inference = memandu ke kedai. Yang pertama sekali seumur hidup dan mahal; yang kedua harian dan senang.
Training di GX10 (sekali-sekala). Inference dalam browser pengguna (30 kali sesaat). Pemisahan ni yang buat "Euphoria dalam browser" possible — kerja berat tak pernah sampai ke pengguna.
Bahasa antara badan dan otak. Observation = senarai nombor yang describe keadaan badan sekarang (~100 nombor: sudut sendi, kelajuan, orientasi). Action = senarai nombor arahan keluar (~20 nombor: satu target untuk setiap sendi).
Obs = deria (mata tertutup pun ko tahu posisi tangan sendiri — itu proprioception). Action = isyarat saraf ke otot.
GOTCHA terbesar projek: obs dikira dalam Python masa training, tapi kena dikira SEMULA dalam JavaScript masa runtime — dan mesti match tepat-tepat. Silap urutan nombor pun policy jadi bodoh. Sebab tu plan ada "parity test" di Phase 3.
Tiga generasi teknik "RL + tiru gerakan manusia". DeepMimic (2018): tiru SATU clip mocap dengan tepat. AMP (2021): tiru GAYA dari koleksi clip, lebih fleksibel. MaskedMimic (2024, NVIDIA): SATU model untuk semua — boleh diarah dengan keyframe, teks, atau target separa ("kepala ke sini, tangan ke situ"), dia isi selebihnya sendiri.
DeepMimic = pelakon hafal satu koreografi. AMP = penari yang dah serap gaya sesuatu genre. MaskedMimic = pelakon pro yang director boleh bagi arahan separuh je ("jatuh ke kiri, lindung muka") dan dia improvise selebihnya dengan natural.
Kita start dengan gaya DeepMimic (track 1 clip — paling senang debug), naik ke MaskedMimic di Phase 5. MaskedMimic tu yang bagi kuasa "AI director" untuk gameplay LANGGAR nanti.
Rakaman gerakan manusia sebenar (aktor pakai sut bersensor) yang disimpan sebagai data animasi. Ini "buku teks" yang policy belajar daripadanya — tanpa mocap, RL akan jumpa cara bergerak yang *berkesan* tapi *hodoh* (merangkak pelik, terkedek-kedek).
Video demonstrasi jurulatih. RL kata "kekal berdiri, aku tak kisah macam mana" — mocap tambah "…dan buat dengan GAYA macam ni".
Sumber kita: Mixamo (library Adobe, dah biasa guna untuk cospace — selamat untuk komersial, tapi verify terma dulu) dan AMASS (dataset akademik gergasi 40+ jam — TAPI non-komersial, prototype sahaja). Ini licensing trap yang research jumpa.
Proses pindahkan gerakan dari satu rangka ke rangka lain yang berbeza saiz/proporsi. Mocap dirakam atas badan aktor; patung kita ada tulang berbeza — retarget "translate"-kan gerakan tu.
Baju yang sama design tapi kena ubah ikut saiz badan orang lain — jahitan tempat lain, rupa akhir sama.
Clip Mixamo → skeleton kanonik GREYMOUTH. Research kata retarget quality yang teruk = punca #1 training tak jadi — kalau gerakan zombie keluar, check sini dulu.
Reward = formula markah RL (contoh: +markah ikut pose mocap, -markah kalau jatuh). Domain randomization = sengaja UBAH-UBAH ciri dunia setiap kali latihan — geseran lantai, kekuatan otot, berat badan dirawakkan — supaya policy tak "hafal" satu dunia spesifik, tapi jadi robust dalam apa-apa dunia.
Latih pemain bola atas padang basah, kering, berlumpur dan berpasir. Pemain tu takkan hebat *satu* padang sahaja — dia hebat SEMUA padang, termasuk padang yang dia tak pernah jumpa.
DR ialah senjata utama kita lawan risiko #1 (domain gap, lihat bawah). "Padang yang dia tak pernah jumpa" tu = physics engine dalam browser.
Bahagian "badan" — macam mana patung tu wujud dan bergerak dalam dunia fizik.
Software yang mengira hukum fizik: graviti, pelanggaran, geseran, momentum. Bagi dia senarai objek, dia kira di mana semuanya berada 1/60 saat kemudian. "Simulator" = benda sama, istilah dunia robotik.
Hakim fizik. Setiap frame semua objek "cadangkan" pergerakan, hakim pastikan takde yang tembus lantai atau langgar hukum Newton.
Kita guna DUA: satu untuk training di GX10 (Isaac Lab / MuJoCo) dan satu dalam browser (Rapier.js / MuJoCo-WASM). Fakta yang dua-dua ni TAK SAMA perangai = punca risiko terbesar projek.
Ragdoll = badan watak dimodel sebagai tulang-tulang fizik bersambung sendi. Passive = takde tenaga langsung, jatuh longlai (watak mati game lama). Active = setiap sendi ada "otot" yang boleh melawan — badan boleh mengimbang, melangkah, bangun. Active ragdoll = ragdoll + otak + otot.
Passive = patung kain dicampak. Active = orang sebenar kena tolak — terhuyung, tangan terkeluar refleks, kaki melangkah, recover. Yang kedua tu yang buat Euphoria (GTA IV/V) legendary.
Ini definisi projek. Phase 1 siapkan passive (badan + sendi), Phase 2+ tambah otak (policy) dan otot (PD motors).
Bilangan "arah bebas" satu sendi boleh gerak. Lutut = 1 DOF (lipat je satu paksi). Bahu = 3 DOF (angkat, kehadapan, pusing). Jumlah DOF seluruh badan = saiz masalah kawalan.
Pintu = 1 DOF (buka-tutup). Joystick = 2 DOF. Kepala ko = 3 DOF (angguk, geleng, senget).
Skeleton kanonik kita ~19–23 DOF. Setiap DOF = satu nombor dalam action vector = satu "otot" policy kena kawal.
Formula kawalan klasik yang jadi "otot" kita. Ko bagi dia SATU target ("lutut, pergi ke sudut 45°"), dia kira sendiri daya nak sampai — tarik kuat kalau jauh (P), brek bila hampir sampai (D). Stiffness = kekuatan tarikan, damping = kekuatan brek.
Spring + shock absorber kereta, atau tangan ko ambil cawan: laju masa jauh, perlahan automatik bila nak sampai — tak overshoot, tak menggeletar.
KRITIKAL: policy kita TAK output daya mentah — dia output target PD ("semua sendi, pergi ke pose ni"), dan PD controller yang terjemah jadi daya. Research sahkan ini buat policy jauh lebih tahan bila tukar engine — sebab PD tu macam suspension yang serap perbezaan kecil antara dunia.
Implementasi PD controller di dalam physics engine — "motor" yang dipasang pada sendi, boleh diberi target position/velocity dan dia hasilkan daya sendiri setiap step.
Power steering. Ko pusing stereng (bagi target), motor yang buat kerja berat.
GOTCHA dari research: Rapier.js punya motor cuma ada pada sendi 1-DOF (macam lutut). Sendi 3-DOF (bahu/pinggul) takde motor — kena bina dari 3 sendi 1-DOF bertindih, atau kira daya sendiri secara manual. Ini Spike B dalam Phase 0.
Tiga lapisan watak 3D. Skeleton = rangka tulang tak nampak. Skinned mesh = kulit/badan 3D yang "terlekat" pada tulang — tulang gerak, kulit ikut. Rig = keseluruhan sistem tulang+kulit+kawalan.
Patung wayang kulit moden: rangka dalam (skeleton), kulit luaran (mesh), dan tali-tali pengawal (rig). Kita dah master benda ni dari kerja avatar cospace.
Phase 1 = "rig builder": auto-tukar avatar Mixamo jadi badan fizik (setiap tulang jadi kapsul + sendi + berat). Fail JSON rig tu jadi kontrak antara dunia training dan dunia browser.
Hz = berapa kali sesaat. Timestep = saiz "detik" simulasi (60Hz = fizik dikira setiap 1/60 saat). Substep = pecahkan satu timestep kepada beberapa kiraan kecil untuk lebih stabil (tapi lebih mahal).
Frame rate untuk fizik. Substep = macam tengok pergerakan slow-mo untuk pastikan tak terlepas apa-apa — lagi teliti, lagi penat.
Design kita: fizik 60Hz, policy 30Hz (otak fikir sekali untuk setiap 2 langkah fizik — manusia pun refleks lebih perlahan dari otot). Nombor ni MESTI sama antara training dan browser, kalau tak policy keliru.
Semua ni duduk kat GX10 sahaja — pengguna akhir tak akan sentuh satu pun.
Mesin AI kita — NVIDIA GB10 (Grace-Blackwell), CPU ARM 20-core + GPU Blackwell dalam satu chip, 128GB memory. Kelas "DGX Spark". Dah jadi rumah OPENCOMM/Rokiah; sekarang dapat kerja kedua: gym untuk patung GREYMOUTH.
Tempat semua training jalan. GOTCHA dari research: sebab dia ARM + chip baru (sm_121), Isaac Lab mesti install dari branch yang support Spark — kalau tak, error nvrtc masa mula training. Dah ada fix documented.
Simulator fizik NVIDIA yang direka khas untuk RL. Keistimewaan: jalankan ribuan salinan dunia serentak di atas GPU — 4,096 patung belajar berdiri pada masa yang sama, dan data tak pernah keluar dari GPU (ini yang buat dia 100–1000× lebih laju dari cara lama). Isaac Gym = versi lama (legacy), Isaac Lab = pengganti rasmi.
Gym dengan 4,096 treadmill dan seorang jurulatih yang boleh perhatikan SEMUA sekaligus. Pengalaman 1 hari kat sini = pengalaman 10 tahun sorang-sorang.
Enjin training utama di GX10 (verified jalan kat GB10). Sebab dia je yang buat training humanoid tractable atas SATU mesin — tanpa GPU-parallel sim, kita kena sewa cluster.
Simulator fizik paling dihormati dalam dunia robotik (asal DeepMind/Google, sekarang open-source). Lebih tepat dan "jujur" dari Isaac untuk sendi & sentuhan — research kata dinamik MuJoCo lebih dekat dengan realiti — tapi jalan atas CPU, jadi lebih perlahan.
Isaac = gym gergasi laju. MuJoCo = makmal biomekanik yang teliti. Latih kat gym, sahkan kat makmal.
Peranan kedua yang PENTING: MuJoCo ada versi WASM (boleh jalan dalam browser!). Kalau kita train dalam MuJoCo dan deploy MuJoCo-WASM, masalah domain gap TERUS HILANG — sebab dunia training dan dunia browser jadi enjin yang sama. Trade-off (saiz download vs kelajuan) diukur di Spike C.
Framework open-source NVIDIA untuk melatih watak fizik — rumah rasmi MaskedMimic. Dah siap ada: pipeline training, sokongan berbilang simulator (Isaac Lab, MuJoCo, Newton), retargeting, dan sistem reward. Aktif diselenggara (author paper sendiri commit minggu lepas).
Beli rangka kereta lumba siap dari pengeluar, bukan kimpal sendiri dari besi buruk. Kita tumpu pada pemandu (policy kita) dan trek (skeleton kita), bukan bina enjin dari kosong.
Base code training kita — verdict paling penting dari research. Lesen Apache-2.0 = bebas guna komersial. AWAS: yang bebas tu KOD; DATA contoh dia (SMPL/AMASS) tetap non-komersial.
SMPL = model badan manusia standard akademik (satu formula yang boleh jana sebarang bentuk badan manusia). AMASS = dataset gergasi 40+ jam mocap, semua dalam format SMPL. Duo ni standard penyelidikan — tapi dua-dua berlesen non-komersial (Max Planck Institute).
Textbook perpustakaan universiti: boleh belajar percuma, tapi tak boleh fotostat dan jual.
Guna untuk prototype/belajar SAHAJA. Apa-apa yang nak dijual (LANGGAR) mesti dilatih atas data bersih (Mixamo/mocap sendiri). Plan kita asingkan dua trek ni dari awal supaya tak tercampur.
TensorBoard = dashboard graf untuk memantau training (reward naik ke? dah converge ke?). Checkpoint = "save game" model — snapshot otak pada satu titik masa, boleh sambung balik kalau training terganggu.
Wajib dari hari pertama sebab training di GX10 ambil berhari-hari — kalau power trip tanpa checkpoint, mula balik dari kosong.
Semua ni jalan dalam browser pengguna — kena ringan, laju, dan jalan kat phone.
Library JavaScript paling popular untuk grafik 3D dalam browser (atas WebGL/WebGPU). Kerja dia SATU: lukis. Dia tak tahu apa-apa pasal fizik atau AI — dia cuma render apa yang disuruh, 60 kali sesaat.
Jurukamera + pelukis. Physics engine tentukan di mana semua benda berada; Three.js yang buat ia nampak cantik atas skrin.
Renderer kita — dah 10+ sesi kita master dia melalui cospace. Kalau perlu laju lagi (Phase 6), kita boleh "diet"-kan dia: buang bahagian tak guna, custom shader.
Teknologi yang benarkan kod dari bahasa laju (Rust, C++) jalan DALAM browser pada kelajuan hampir-native. JavaScript biasa terlalu perlahan untuk kira fizik 20 sendi × 60 kali sesaat; WASM selesaikan tu.
Browser biasanya cuma faham satu bahasa (JS). WASM macam bagi dia penterjemah segera untuk bahasa-bahasa kuat — sekarang program "kelas desktop" boleh masuk web tanpa install apa-apa.
DUA komponen paling berat kita adalah WASM: physics engine dan AI inference. Sebab WASM lah "Euphoria dalam browser" tak mustahil.
Physics engine moden ditulis dalam Rust, dicompile ke WASM untuk web. Laju, kecil, aktif diselenggara — calon utama enjin fizik browser kita.
Calon #1 (lawan MuJoCo-WASM, keputusan di Gate 0). Kelebihan: kecil + laju + ada PD motor siap. Kelemahan (dari research): motor 1-DOF sahaja, dan tiada siapa pernah buktikan humanoid 20-DOF stabil atas dia — itu risiko engineering #1 kita, diuji di Spike B.
ONNX = format fail universal untuk neural network — macam PDF untuk model AI: train dalam apa-apa framework, save sebagai .onnx, buka di mana-mana. onnxruntime-web = pemain ONNX untuk browser (Microsoft, open-source).
Lagu diproduce dalam studio mahal (PyTorch di GX10), diexport jadi MP3 (ONNX), dimainkan kat mana-mana telefon (onnxruntime-web). Studio tak ikut serta.
Jambatan GX10 → browser. GOTCHA dari research: ProtoMotions TAK sediakan exporter siap — kita bina sendiri di Phase 3, dengan ujian parity supaya otak tak "rosak dalam perjalanan".
Dua jalan untuk buat inference laju dalam browser. WebGPU = guna GPU (standard baru, powerful tapi masih muda). WASM-SIMD = guna CPU dengan arahan vector (matang, serasi luas). Untuk model KECIL macam kita, CPU selalunya menang — overhead nak hantar kerja ke GPU lagi mahal dari kerja tu sendiri.
Nak hantar satu kotak: motosikal (CPU) terus pergi. Lori 10-tan (GPU) hebat untuk 1,000 kotak, tapi untuk satu kotak, masa loading lori tu je dah kalah.
Diukur di Spike A, dua-dua. Jangkaan: WASM-SIMD menang untuk MLP kita — tapi kita ikut nombor, bukan jangkaan.
Web Worker = thread kedua dalam browser, supaya kerja berat tak sekat lukisan skrin. SharedArrayBuffer = blok memori yang dua thread boleh baca/tulis serentak tanpa poskan salinan — cara paling laju untuk mereka berkomunikasi.
Dapur (worker: fizik+AI) berasingan dari ruang makan (main thread: render). SAB = tingkap hatch antara dapur dan ruang makan — pinggan lalu terus, tak payah waiter berjalan keliling (postMessage).
Architecture Phase 4: fizik + inference dalam worker, main thread cuma render. Nota teknikal: SAB perlukan header keselamatan khas (COOP/COEP) kat server — dah masuk checklist.
Teknik kecilkan model: simpan nombor dalam 8-bit (kasar sikit) ganti 32-bit (halus). Model jadi ~4× kecil dan laju, dengan kehilangan ketepatan yang biasanya tak terasa.
JPEG untuk otak — compress, kualiti hampir sama, saiz jauh kecil.
Senjata simpanan kalau phone lambat (jadual failure P4) — bukan keperluan hari pertama.
Istilah yang menerangkan KENAPA plan kita berbentuk macam tu.
Domain gap = perbezaan halus antara dua "dunia" fizik — setiap engine kira geseran/sentuhan sikit berbeza, dan policy yang dilatih dalam satu dunia boleh gagal total dalam dunia lain. Sim2sim = uji policy merentas dua simulator. Sim-to-real = versi paling ekstrem: simulator → robot fizikal sebenar.
Pemain FIFA masuk padang bola sebenar. "Peraturan" nampak sama, tapi setiap detail halus lain — first touch terus lari. Nombor dari research: policy yang perfect dalam Isaac boleh jatuh ke 3.6% success dalam MuJoCo tanpa mitigasi. Ini musuh #1 kita.
Seluruh Phase 3 wujud untuk lawan ni: PD targets + DR + sim2sim gauntlet (uji dalam enjin browser SEBELUM ship) + escape hatch MuJoCo-WASM. Berita baik: robot company dah buktikan resipi ni sampai ke robot sebenar — gap kita lebih kecil dari gap diorang.
Ujian "salinan karbon": bagi input SAMA kepada dua implementasi (Python di GX10 vs JavaScript di browser), pastikan output SAMA hingga titik perpuluhan. Kalau tak sama = ada bug penterjemahan.
Dua kalkulator kena bagi jawapan sama untuk soalan sama. Kalau tak, salah satu rosak — dan lebih baik tahu SEKARANG dari selepas 3 minggu debug benda lain.
Research + pengalaman industri kata: kebanyakan "domain gap" yang orang lawan berminggu-minggu rupanya cuma bug obs/action mismatch. Parity test = insurance murah lawan pembaziran tu. Wajib sebelum salahkan physics.
Istilah software: eksperimen kecil, pantas dan sengaja buang (throwaway) untuk jawab SATU soalan teknikal dengan bukti. Bukan production code — kod comot pun takpe, yang penting jawapan.
Test drive sebelum beli kereta. 20 minit memandu jawab apa yang 20 jam baca review tak boleh jawab.
Phase 0 = 5 spike (A–E), satu untuk setiap unknown yang deep research tak dapat sahkan. Prinsip: keputusan mahal (pilih engine) dibuat dengan nombor sendiri, bukan dengan harapan.
Syarat keluar setiap fasa — senarai kriteria BOLEH-UKUR yang mesti lepas sebelum masuk fasa seterusnya. Contoh Gate 3: "success rate dalam enjin browser ≥80% daripada dalam sim asal".
Exam akhir setiap semester. Tak lepas = ulang, JANGAN naik semester atas harapan — sebab kelemahan semester 3 jadi bencana di semester 5.
Sistem gate = pertahanan kita terhadap risiko R6 (scope creep). R&D memang seronok sampai boleh hanyut — gate paksa setiap fasa keluarkan bukti sebelum bergerak.
Euphoria (NaturalMotion) = teknologi active-ragdoll legendary dalam GTA IV/V dan Red Dead Redemption — watak bertindak balas fizikal secara real-time, bukan main animasi siap. Proprietary, tak pernah dilesenkan keluar, dan TIADA versi open-source. SIMBICON (2007) = kaedah akademik klasik kawalan berjalan TANPA machine learning — resipi tulis-tangan (contoh: "kaki melangkah ke arah jatuh").
Euphoria = tanda aras yang kita kejar. SIMBICON = pelan B kita — kalau laluan ML tersekat teruk, kaedah klasik ni boleh diimplemen terus dalam JS (dah ada contoh: SimbiconJS). Tapi selagi ML jalan, kita tak perlukan dia.
Dua lesen yang menentukan apa kita boleh jual. Apache-2.0 = lesen open-source pemurah: guna, ubah, jual — semua boleh (kod ProtoMotions). CC BY-NC = "Non-Commercial": guna bebas TAPI tak boleh untuk benda berbayar (data LAFAN1; AMASS/SMPL pun sekelas).
Peraturan emas projek: KOD kita bebas, DATA yang menentukan. Policy "diwarisi" lesen data yang dia belajar daripadanya — train atas AMASS = tak boleh jual. Sebab tu ada dua trek data terpisah dalam plan.