Octopus

The standard route: load the GLB with GLTFLoader. The same file works in any glTF pipeline (Babylon.js, <model-viewer>, custom engines).

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';

new GLTFLoader().load('./octopus-1aa810.glb', (gltf) => {
  scene.add(gltf.scene); // real-world scale in meters, origin on the ground
});

Flat-shaded vertex colors on a single material: no textures to wire up, one draw call.

R3F takes any Object3D through <primitive>, and these modules return a ready THREE.Group synchronously. No useGLTF, no loader, no <Suspense>.

import { useMemo } from 'react';
import { Canvas } from '@react-three/fiber';
import { createAsset } from './octopus-1aa810.mjs';

function Octopus(props) {
  const obj = useMemo(() => createAsset(props), [JSON.stringify(props)]);
  return <primitive object={obj} />;
}

<Canvas camera={{ position: [3, 2, 4] }}>
  <hemisphereLight args={[0xffffff, 0x998877, 1.2]} />
  <directionalLight position={[4, 7, 5]} intensity={2} />
  <Octopus colorway="coral-flush" />
</Canvas>

Every knob is a prop. colorway="coral-flush" above is one of this model's own parameters, so the component rebuilds when it changes, exactly like any other React component. More on using these in R3F.

useFrame((state) => obj.userData.tick?.(state.clock.elapsedTime));

1. Buy the asset, then download the .glb from this page.
2. Unity: drag the file into Assets (glTFast or UnityGLTF import it). Godot: drop it into the project, it imports natively. Blender: File → Import → glTF 2.0.
3. Place it as-is: real-world scale in meters, origin at ground level.
4. Materials arrive as vertex colors on one material: no texture files, nothing to relink.

Using Claude Code, Cursor or another coding agent? This site is built for them: agent-readable docs at /llms.txt and a JSON API at /api. Paste this prompt:

Your agent authenticates with an API key: create one under My assets after purchase, and it can fetch everything you own.

I own "Octopus" on polyfork.dev. My API key is in
the POLYFORK_KEY env var. Download it into my project and add it
to my three.js scene:

  metadata: GET https://polyfork.dev/api/assets/octopus-1aa810  files:    GET https://polyfork.dev/dl/octopus-1aa810.glb
            GET https://polyfork.dev/dl/octopus-1aa810.mjs
  (both with header  Authorization: Bearer $POLYFORK_KEY)

Site docs for agents: https://polyfork.dev/llms.txt

Every asset in this catalog shares one identical vertex-colored material, with no textures at all. That means whole scenes collapse into a single draw call: the same result Synty-style packs get from a texture atlas, without the atlas.

import { mergeAssets } from 'https://polyfork.dev/cdn/merge.mjs';

// position your assets first, then:
const { merged, dynamic } = mergeAssets([
  terrain, tree, rock,
  { object: asset, rig },   // 'Arm1' stays animatable
]);
scene.add(merged);                  // ONE draw call, static
dynamic.forEach(d => scene.add(d)); // rigged parts, still movable

Placing many copies of one model? Use THREE.InstancedMesh instead: one draw call and even less memory. The landing page's forest demo ends with exactly this merge.

Rigged parts: Arm1, Arm1Curl, Arm2, Arm2Curl, Arm3, Arm3Curl, Arm4, Arm4Curl, Arm5, Arm5Curl, Arm6, Arm6Curl, Arm7, Arm7Curl, Arm8, Arm8Curl. Each is a named group with its pivot at the hinge or axle, so one line animates it.

const asset = createAsset();
scene.add(asset);

// swing 'Arm1' open (tween this value for smooth motion):
asset.getObjectByName('Arm1').rotation.y = Math.PI / 4;

Loading the GLB instead? The same named nodes are there: gltf.scene.getObjectByName('Arm1').