Three-Live: 3D na Isinulat ng AI sa Web at Mobile
Binibigyang-daan ng Three-Live ang mga developer na i-convert ang code ng Three.js na isinulat ng AI sa portable na 3D content, na sumusuporta sa mga web at native mobile application sa pamamagitan ng pag-compile sa mga format tulad ng GLB o USDZ.

Mga Pangunahing Punto at Kasalukuyang Ebidensya
Tinutulungan ng Three-Live ang mga developer na gawing 3D content ang code ng mga eksena ng Three.js na isinulat ng AI, na maaaring ipakita sa web at sa mga native mobile application. Ang sentrong ideya nito ay gamitin ang isang sinusuportahang subset ng Three.js bilang portable na paglalarawan ng eksena, pagkatapos ay i-compile ang nagresultang eksena sa GLB o USDZ. Nagbibigay ito ng compiler, mga renderer, at mga integration; maaaring magsulat ng code ang isang external na modelo.
Pinagmulan ng mga larawan para sa Studio, arkitektura, at mga XR figure: Google Open Source Blog.
Nasa organisasyon ng Google ang repository ngunit malinaw nitong sinasabing hindi ito isang opisyal na produktong sinusuportahan ng Google. Sa kasalukuyan, tinatawag ng README nito na Beta ang proyekto. Ipinapakita ng mga opisyal na halimbawa ang procedural geometry, mga PBR material, animation, at spatial interaction sa WebGL2/WebXR, Android Filament at Jetpack XR, at Apple RealityKit. Ipinapakita ng mga ito ang nilalayong workflow sa halip na garantiya ng performance sa lahat ng device.
Iniuulat ng launch article ang karaniwang compilation time na 2–5 millisecond nang walang kumpletong protocol sa benchmark ng hardware at eksena. Hindi dapat unawain ang bilang na iyon bilang kabuuang image-to-3D latency. Kasama rin sa repository ang isang evaluation suite na may 100 prompt at isang smoke suite na may 10 script na sumasaklaw sa compilation, diagnostics para sa mga hindi sinusuportahang feature, rendering, simulation, at one-turn repair; ang presensya ng mga ito lamang ay hindi ebidensyang gumagana ang bawat nabuong script.

Mula Code Patungo sa Native na Eksena
Bumubuo ang isang author o coding model ng mga mesh, material, transform, at group sa pamamagitan ng sinusuportahang API. Isinasagawa ng host ang script sa isang limitadong environment. Sa mga native platform, ini-embed ng ThreeEngine ang Boa JavaScript engine sa Rust, nire-reset ang scene/global state, isinasagawa ang script, at kinukuha ang isang typed na SceneGraph mula sa mga raw buffer. Ipinapasa ng GLB entry point ang graph na iyon sa write_glb; gumagawa ng USDZ ang magkahiwalay na path. Ang intermediate representation ay isang tahasang scene graph, hindi isang natutunang 3D latent.
Mahalaga ang mga limitasyon sa execution dahil maaaring maglaman ang nabuong code ng runaway loop o labis na geometry. Sa sinuring source, nililimitahan ang production script execution sa 500 millisecond, at sinusuri ang orasan bawat 10,000 VM opcode. Kabilang sa mga ceiling ng eksena ang 100,000 vertex at 1,000 mesh. May hiwalay na packaging deadline para sa transcoding. Ang mga ito ay protective limit na tinukoy ng implementation, hindi mga sukat ng bilis ng rendering o pahayag ng perpektong isolation. Gumagamit ang web path ng worker, na may opsyonal na opaque-origin iframe; nililimitahan ang access sa network at storage.
Pagkatapos ng compilation, nilo-load ng mga platform adapter ang asset sa target renderer. Gumagamit ang Android ng Filament at mga XR integration; gumagamit ang mga Apple platform ng RealityKit; may sarili nitong WebGL2 renderer at suporta sa WebXR ang browser. Inilalarawan ng mga declarative na userData.xr trait ang mga sinusuportahang behavior gaya ng grabbing o spatial anchoring. Nangangailangan ang live runtime behavior ng kaukulang runtime integration: hindi napapanatili ng isang static na model preview ng operating system ang arbitraryong JavaScript interaction.
Nagdagdag ang agent workflow ng verification loop. Maaaring mag-validate ang CLI ng isang script, mag-render ng four-view contact sheet, at mag-convert ng mga asset; inilalantad ng MCP interface nito ang mga operasyong ito sa mga coding agent. Maaaring magbalik ang evaluation harness ng compiler diagnostic at visual critique para sa isang repair turn. Iniuugnay nito ang code generation sa naoobserbahang geometry at framing, habang ang mga hindi sinusuportahan o degraded na API feature ay nananatiling dapat siyasatin sa halip na basta ipagpalagay na nalutas na.
Mga Application at Kalagayan ng Development
May kaugnayan ang Three-Live sa mga procedural product viewer, nae-edit na educational scene, AR prototype, at AI-assisted 3D authoring sa loob ng mga application. Maaari nitong bawasan ang platform-specific na gawain sa scene authoring, ngunit hindi nito ipinapangakong ganap na compatible ito sa arbitraryong Three.js application. Kabilang sa mga opsyon sa package at binary ang npm, Rust tooling, Android library, at Apple Swift Package Manager; gumagamit ang repository ng Apache-2.0.
Ang opisyal na Unreleased changelog ang batayan ng mga direksyon sa development dito. Inililista nito ang runtime image-to-scene generation na may spatial quality check at one-turn repair, pati ang opsyonal na WebGPU scene at Gaussian-splat acceleration. Mga entry ito na naipatupad sa development branch, hindi mga pangakong kasama ang mga ito sa bawat packaged release. Sinusuri ng image path ang minimum na bilang ng mesh, finite bounds, saklaw ng camera, at mga kritikal na overlap; hindi pinatutunayan ng mga pagsusuring ito ang tapat na reconstruction ng input image.
Sinuri ng review na ito ang compiler entry point, mga limitasyon sa execution, representasyon ng eksena, dokumentasyon ng evaluation, at changelog. Hindi nito ini-install ang SDK o sinusukat ang performance sa mga device.
Mga Madalas Itanong
Ang Three-Live ba mismo ang AI model na bumubuo ng 3D?
Hindi. Isinasagawa, bine-validate, kino-compile, at ipinapakita nito ang code ng eksena. Isang hiwalay na coding o multimodal na modelo ang nagbibigay ng mga script na binuo ng AI sa pamamagitan ng napiling integration.
Gagana ba nang walang pagbabago ang bawat aplikasyon ng Three.js sa mobile?
Hindi. Nalalapat ang portability sa mga sinusuportahang scene API at runtime behavior. Nangangailangan ng pagsusuri o pag-aangkop ang mga dependency ng browser, mga hindi sinusuportahang feature, at arbitraryong lohika ng interaksyon.
Napapanatili ba ng pag-export ng GLB o USDZ ang isang kumpletong interactive na app?
Hindi. Ang mga file na iyon ay naglalaman ng sinusuportahang data ng asset; ang live na interaksyon ay nakadepende rin sa runtime bindings at suporta ng platform. Hindi maaaring pumalit ang mga static na preview ng OS sa buong Three-Live runtime.




