Mooring Block

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('./mooring-block-794549-hd.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 './mooring-block-794549.mjs';

function MooringBlock(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} />
  <MooringBlock colorway="wreck-steel" />
</Canvas>

Every knob is a prop. colorway="wreck-steel" 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. The HD .glb downloads from this page with Pro; the low poly one is free.
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 "Mooring Block" 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/mooring-block-794549  files:    GET https://polyfork.dev/dl/mooring-block-794549-hd.glb
            GET https://polyfork.dev/dl/mooring-block-794549-hd.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 },   // 'chain-stub' 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: chain-stub. 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 'chain-stub' open (tween this value for smooth motion):
asset.getObjectByName('chain-stub').rotation.y = Math.PI / 4;

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