What if you could npm install 3D models? Introducing Vibe3D - the shadcn for threejs Starting with the scifi asset kit, over 180+ models, all free and oss (MIT licensed) and two reference terrain meshes. All models are installed directly into your codebase instead of pre-packaged as code imports... or worse yet, FBX files 🤮 Docs: This means, a simple "bunx vibe3d add Artificial Intelligence Papers-kit/pressure-gauge" will install the fully procedural code Want to change something? just tell your ai to do it It uses some shared helper code to produce the topology and at least per kit all items reuse and share the same materials, so technically performance should be better than letting your ai run wild on its own. Also releasing with it two skills: - Vibe model skill to produce your own models and kits, just "bunx vibe-model --global" and tell your ai to vibe model some 3d assets with a reference photo, you'll see it works - Vibe terrain "bunx vibe-terrain" installs the terrain mesh modeler, yea just try it out, best results with opus 5 ngl Everything is MIT licensed, i was just joking, no hate for unreal or unity Threejs still the best tho 🖕🏻 If you just want to see all 3D models up close: Yea, you can also just vampire it and download all modes as .glb files, good luck fixing some of them then though Big thanks to ThreeJS Assets for contributing 50 assets to the scifi kit! Everyone who spends some tokens on it will be added to the contributor list Oh and before i forget fuck you kenney, we roll our own kits nowshow more

come and join the greatest ai game dev group chat: (NOTE: YOU HAVE TO DM ME OR @majidmanzarpour FIRST TO BE ACCEPTED, NO I AM NOT MAKING EXCEPTIONS, NOT EVEN FOR ELON MUSK, EVEN THE DISCORD FOUNDER WROTE ME BEFORE BEING ACCEPTED THOU SHALL NOT PASS WITHOUT A DM)

gh repo:

vibe changer!

Is your procedural generation for rocks part of this or is that separate?

yes it's in the docs, the two references as well as the codex skill

So if begins. The agentic Fab era for three js. I hope other contributors pitch in. This is great!

@OP__Nico promised me to drop some tokens

Incredibly cool idea! Thanks for your effort!

@Andrew_Blumson another one!

Pretty nice.

thanks man! blew a good amount of tokens on it

I imagine. Which model did you use?

i'd say 90% 5.6 sol high and 10% opus 5

You got the codex sub? Sol perform really poorly on threejseval. But I think I use medium. Opus is really tasteful.

yea a few more days until it runs out

lol

never tell your next move

Just told my agent to poke around with it

npm install for 3D models, cool idea

You are an absolute giga chad. I'd give you a big wet kiss !!!

Goat

💚

hey I watched you invent this 😍😍

I’m contributing. Where do I start? Should I reverse engineer existing objects to see the setup?

Looks pretty good! One suggestion for the model browser screen: add some preview images to the cards, along with an option to select multiple models and a copy button that generates a prompt. The prompt could then be used to import all the selected models into the game.

banger thx

What is this obsession with 3D models as code? There is a very good reason we don’t, haven’t and shouldn’t do it. There’s basically no benefit to storing the models in a PACKAGE registry as code compared to storing actual models in object storage. If anything there are many caveats. The models are nice though and I love the general sentiment! I’m excited to see where it goes and love seeing people contribute. As always I’m happy to be proven wrong!

there are many many benefits of which you don't seem to see any

Genuinely asking, can you please elaborate? The main benefit I see is the instant ability to add it to threejs, open source difs, and maybe.. MAYBE lets agents modify the models easier (specifically without any extra tooling). But there are also many many caveats… of which you don’t seem to see any I believe in your mission, and I assume your intentions are good, so I think it’s beneficial if we all learn together :)

what are the many caveats?

- Size & load performance: Code is far larger and slower to parse than compressed binary (GLB + Draco/meshopt). - Bundle bloat: Models inflate the JS bundle and initial load; real assets load async from CDN independently. - Editing workflow: Hard to iterate visually—requires code changes or regeneration instead of Blender/DCC tools. - Versioning: Updating one model forces a full package release; registries allow independent asset versioning. Which can really screw over people who need one asset that’s been updated but doesn’t want the other new assets. - Tooling & interoperability: Pure code doesn’t work with other engines/tools; GLB/GLTF does. - Compression & optimization: No easy access to industry-standard compression, LOD, or streaming. - Maintainability at scale: Large geometry-as-code becomes brittle and noisy for humans/AI agents. - npm being a mismatch: Package registries are poor for large asset-like data (size limits, install speed, caching). Like I said, I love and understand the idea, but I think a different execution might make it even better for everyone

1. it's not larger across multiple models sharing the same producers 2. tree shaking and async imports 3. editing workflow is surprisingly easy for llms due to the code and headless renderers 4. Versioning is the same problem for object storage or code 5. Tooling idc since i do it all for threejs but decoupling the rendering from authoring is possible 6. i'm not sure thats the case 7. npm is the source to get the models into your own codebase, not to download them at the edge

(Really not trying to make you or anyone read too much but this is a really good learning opportunity and the last I’ll add… for now..) 1. Shared producers help across a kit, sure. Single model or cold load still loses hard to Draco/meshopt GLB. Aggregate win doesn’t erase the per-asset tax. 2. Kind of. Tree shaking and async imports mitigate, they don’t solve. You’re still shipping parseable JS geometry instead of a binary blob that loads independently from a CDN. Bundle tools paper over a bad foundation. 3. LLMs + headless renderers make iteration easier in that specific workflow. It’s still worse for actual visual iteration, artist pipelines, or anyone not living in an agent loop like you or I. Also code changes for geometry edits is a step backward for most people. But fair as long as that works. 4. Versioning pain exists everywhere YES, but putting this in a code package makes it worse. One model update forces a full package bump and potential cascade. Independent binary assets on a proper registry let you pin or update one without touching the rest. Same problem class, higher friction here. 5. “I only care about Three.js” is fine for your project. Pure code still kills interop with every other engine, DCC tool, and pipeline. Decoupling authoring is possible - then just ship the optimized binary as the default and keep the generator optional. Don’t force the code into everyone’s repo. 6. It is the case lol. Industry compression, LOD, and streaming exist and work today for binaries. Rebuilding them on top of geometry-as-code is extra work you don’t need to do, and just adds more time and operations making games slower. 7. npm as install source still means large asset-like data lives in the package registry with all the usual size, install-speed, and caching problems. That’s the wrong distribution layer for this. Models as code pushed to npm is inherently shortsighted. It optimizes for the current LLM vibe loop at the expense of runtime All I’m saying is maybe it would be beneficial to consider different approaches? I don’t want to feel like I’m attacking you, just genuinely want what’s best for folks and advocate for using the right tool at the right time

idk what you're on keegan it's not that deep

@Scobleizer This is the thing I didn’t know I needed. Amazing. Cant wait to try out the skill and build some new assets! In the spirit it was shared I will try and contribute ! Thank you. 🙏

OMG THANK YOU!!

It's wonderful to be alive in the digital age.

@threejs This is awesome!

Great project, def following! On your link, the model shown has flickering on the top - it might be worth doing a rotation pass, to detect small but annoying visual issues like these.

some have z fighting yes

If you can fix z-fighting on 3D models before they go on your site, that would be a huge help.

it's open source and i printed over 100 models in 3 days go open a pr

Thanks for your reply.

Just took it for a spin. Here's the car model that came out, not bad at all 😍

interesting

S tier messaging

forever a true schizo

Installing models as actual code instead of opaque glbs is a big quality-of-life jump. Shared materials across the kit should keep draw calls reasonable too.

Oooooooo!

finally i guess?

ai teams report 40 percent faster scene builds with code based models over glb

shared materials != shared draw calls. three.js still pays per mesh unless the kit emits InstancedMesh or merged geo. Godot has the same fork: MultiMesh vs a pile of MeshInstances. the runtime topology gen is the part i'd actually benchmark.

i did not say draw calls :)

epic !!!

This is really cool. I can't wait to see a 'level' (scene?) made with this.

@threejs Interesting! I’ll help

wait how did you get it to learn to build the model with so much detail! i really love it!

changing the gauge radius in code beats reopening Blender and exporting it again.

Threejs still the best tho = 📠📠📠