DEV Community: Peter Riding

Confused by Mouse Coordinates in Three.js? Here’s the 2-Minute Explanation

Peter Riding — Thu, 19 Mar 2026 15:43:28 +0000

Ever clicked a 3D object in Three.js and the raycaster hits somewhere completely wrong?

You're not alone. The fix is just a few lines of code — but the why is what confuses most people.

Here’s the simple explanation.

The raycaster doesn't use pixels

It works in the camera’s coordinate system using Normalized Device Coordinates (NDC) — values from -1 to +1.

X: -1 = left, +1 = right
Y: +1 = top, -1 = bottom

So instead of pixels, it uses a normalized coordinate system based on the screen (you can think of it like percentages).

The conversion (this is the important part)

const mouse = new THREE.Vector2();

mouse.x = (event.clientX / window.innerWidth) * 2 - 1;
mouse.y = -(event.clientY / window.innerHeight) * 2 + 1;

raycaster.setFromCamera(mouse, camera);

What’s happening here:

event.clientX / width → gives a value from 0 → 1 across the screen
We remap that to -1 → +1
Same for Y, but flipped because browser coordinates start at the top

In other words, you're converting from pixel space → camera space.

A quick visual

(-1, +1)       (+1, +1)
     ┌─────────────┐
     │             │
     │    (0,0)    │
     │             │
     └─────────────┘
(-1, -1)       (+1, -1)

Why this exists

This system makes everything consistent:

Works on any screen size or resolution
Doesn’t depend on pixel values
Lets setFromCamera() generate a correct 3D ray every time

Minimal click example

window.addEventListener('click', (event) => {
  const mouse = new THREE.Vector2(
    (event.clientX / window.innerWidth) * 2 - 1,
    -(event.clientY / window.innerHeight) * 2 + 1
  );

  raycaster.setFromCamera(mouse, camera);
  const intersects = raycaster.intersectObjects(scene.children);

  if (intersects.length > 0) {
    console.log("Clicked on:", intersects[0].object.name);
  }
});

That’s it. No complex math, no magic — just a coordinate conversion.

If this cleared things up for you as much as it did for me.

Converting Three.js Journey Classic Techniques Module to TypeScript

Peter Riding — Thu, 12 Mar 2026 16:24:50 +0000

Why Add TypeScript to the Classic Techniques Module?

Bruno’s Classic Techniques module teaches the core building blocks every Three.js project needs. The plain JavaScript style works great for learning, but it’s easy to introduce silent bugs (wrong light properties, shadow typos, mismatched particle attributes, etc.).

With just a few targeted types you instantly get:

Errors caught in your editor before runtime
Full autocomplete
Self-documenting code
Safe refactoring and proper memory cleanup

Everything below is a direct port — the logic, math, and final visuals are 100% identical to the course lessons.

Quick Setup (for new readers)

Three.js (latest version) — official types are included
TypeScript 5+ with "strict": true in tsconfig.json
Recommended: Vite + @vitejs/plugin-react (or plain TS setup)

npm install three
npm install --save-dev typescript vite

Part 1: Lights – Type Inference in Action

Original JS (course style):

const light = new THREE.AmbientLight(0xffffff, 0.4);
light.intensityyyy = 0.5; // silent failure

Typed:

const light = new THREE.AmbientLight(0xffffff, 0.4);
light.intensityyyy = 0.5; // ❌ Property does not exist on type 'AmbientLight'

TypeScript respects each light’s unique API:

const ambient = new THREE.AmbientLight();
ambient.castShadow = true; // ❌ Error

const directional = new THREE.DirectionalLight();
directional.target = mesh;     // ✅
directional.castShadow = true; // ✅

Grouped lights (most useful pattern):

interface LightingSetup {
  ambient: THREE.AmbientLight;
  directional: THREE.DirectionalLight;
  accent?: THREE.PointLight;
}

function setupLighting(): LightingSetup { ... } // exact course logic

Key takeaway: One interface = autocomplete everywhere.

Part 2: Shadows – Typed Config Objects

Shadow settings are nested and typo-prone. Interfaces fix that.

interface ShadowQuality {
  mapSize: number;
  cameraTop: number;
  cameraBottom: number;
  radius?: number;
  cameraLeft?: number;
  cameraRight?: number;
  cameraNear?: number;
  cameraFar?: number;
}

function configureShadows(light: THREE.DirectionalLight, quality: ShadowQuality) {
  light.shadow.mapSize.width = quality.mapSize;
  // ... rest of the course settings
}

The classic 3-step setup (renderer → meshes → light) stays exactly the same.

Part 3: Particles & Galaxy Generator

The famous galaxy lesson, now typed and safe to regenerate.

interface GalaxyParameters {
  count: number;
  size: number;
  radius: number;
  branches: number;
  spin: number;
  randomness: number;
  randomnessPower: number;
}

interface GeneratedGalaxy {
  particles: THREE.Points;
  geometry: THREE.BufferGeometry;
  material: THREE.PointsMaterial;
  dispose(): void;
}

function generateGalaxy(params: GalaxyParameters): GeneratedGalaxy {
  // exact position + color gradient logic from the course
  const geometry = new THREE.BufferGeometry();
  const positions = new Float32Array(params.count * 3);
  const colors = new Float32Array(params.count * 3);

  // ... course math (radius, branchAngle, randomness, lerp)

  // material + Points setup (identical to lesson)
  return { particles, geometry, material, dispose() { ... } };
}

Regeneration (course challenge) becomes trivial and safe:

let currentGalaxy = generateGalaxy(defaultParams);
// later
currentGalaxy.dispose();
scene.remove(currentGalaxy.particles);
currentGalaxy = generateGalaxy(newParams);

Key takeaway: Typed parameters + explicit dispose() = no memory leaks when tweaking values live.

Part 4: Scroll State & Mouse Parallax

Simple state objects become self-documenting:

interface ScrollState {
  scrollY: number;
  lastScrollY: number;
  velocity: number;
}

const scrollState: ScrollState = { scrollY: 0, lastScrollY: 0, velocity: 0 };

Mouse cursor object from the parallax lesson uses the exact same pattern.

Part 5: Procedural Scene Composition (House, Graves, Ghosts)

interface HouseStructure {
  group: THREE.Group;
  walls: THREE.Mesh;
  roof: THREE.Mesh;
  door: THREE.Mesh;
}

function createHouse(...) : HouseStructure { ... }

Same clean interface pattern for graves (array of meshes) and the ghost system (with update() method).

Part 6: Asset Management & Cleanup

interface LoadedAssets {
  textures: Map<string, THREE.Texture>;
  geometries: Map<string, THREE.BufferGeometry>;
  materials: Map<string, THREE.Material>;
  dispose(): void;
}

function createAssetManager(): LoadedAssets { ... }

Summary

Concept	Used in the Course	What TypeScript Adds
Type Inference	Lights, BufferAttributes	Instant errors + autocomplete
Interfaces	Shadows, galaxy params, structures	Clear contracts for every system
Typed Configs	Shadow settings, particles	No silent typos
Dispose Methods	Galaxy, assets	Reliable memory management

These small type additions turn the entire Classic Techniques module into production-ready code while preserving Bruno’s original teaching style and logic.

Have you converted any Three.js Journey lessons to TypeScript yet? Drop your experience (or questions) in the comments — happy to help!

Three.js + TypeScript: Keeping It Functional (No Classes Needed)

Peter Riding — Thu, 05 Mar 2026 17:09:17 +0000

If you're following the Three.js Journey or learning Three.js with plain JavaScript, you might wonder how TypeScript fits in without rewriting everything.

You are already learning Three.js the fun way — just functions, variables at the top of the file, and zero classes. The good news? Adding TypeScript doesn’t force you to change any of that. It just quietly adds safety so you catch bugs before they ruin your day.

Why TypeScript actually helps with Three.js

Three.js is amazing, but 3D code is picky. Pass the wrong vector? Your mesh disappears. Mix up a camera and a scene? Nothing renders. TypeScript spots those mistakes the second you type them.

It’s especially handy for:

All the vector and matrix math that has to be exactly right
WebXR sessions and input sources (those APIs are a nightmare without types — just note that WebXR support and types evolve quickly in browsers)
Your animation loops, event handlers, and object tracking

The best part? Your code stays exactly the same structure you’re used to.

From plain JavaScript to TypeScript (seriously, tiny changes)

Here’s what your setup probably looks like right now:

const canvas = document.querySelector('canvas.webgl');
const scene = new THREE.Scene();
const sizes = { width: window.innerWidth, height: window.innerHeight };
const camera = new THREE.PerspectiveCamera(75, sizes.width / sizes.height, 0.1, 100);
camera.position.z = 3;
const renderer = new THREE.WebGLRenderer({ canvas });
renderer.setSize(sizes.width, sizes.height);

const clock = new THREE.Clock();
const mesh = new THREE.Mesh(/* ... */);

function animate() {
  const elapsedTime = clock.getElapsedTime();
  mesh.rotation.y = elapsedTime * 0.5;
  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

And here’s the exact same thing with TypeScript sprinkled in:

import * as THREE from 'three';

const canvas = document.querySelector<HTMLCanvasElement>('canvas.webgl');
if (!canvas) throw new Error('Canvas element not found');

let sizes = {
  width: window.innerWidth,
  height: window.innerHeight
};

const camera = new THREE.PerspectiveCamera(75, sizes.width / sizes.height, 0.1, 100);
camera.position.z = 3;

const renderer = new THREE.WebGLRenderer({ canvas });
renderer.setSize(sizes.width, sizes.height);

const clock = new THREE.Clock();
const mesh = new THREE.Mesh(/* ... */);

function animate(): void {
  const elapsedTime = clock.getElapsedTime();
  mesh.rotation.y = elapsedTime * 0.5;
  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

That’s literally it.

The only four things you’ll actually type most of the time

1. The canvas

const canvas = document.querySelector<HTMLCanvasElement>('canvas.webgl');
if (!canvas) throw new Error('Canvas element not found');

2. Simple objects (like sizes)

Use let because we mutate it on resize:

let sizes = { width: window.innerWidth, height: window.innerHeight };

3. Your functions

function animate(): void { ... }

4. Event listeners

window.addEventListener('mousemove', (event: MouseEvent): void => { ... });

Full working example (copy-paste ready)

import * as THREE from 'three';

let sizes = {
  width: window.innerWidth,
  height: window.innerHeight
};

const canvas = document.querySelector<HTMLCanvasElement>('canvas.webgl');
if (!canvas) throw new Error('Canvas element not found');

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(75, sizes.width / sizes.height, 0.1, 100);
camera.position.z = 3;
scene.add(camera);

const renderer = new THREE.WebGLRenderer({ canvas, antialias: true });
renderer.setSize(sizes.width, sizes.height);
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));

// geometry + material + mesh
const geometry = new THREE.BoxGeometry(1, 1, 1, 2, 2, 2);
const material = new THREE.MeshStandardMaterial({ color: 0xa778d8, roughness: 0.4 });
const mesh = new THREE.Mesh(geometry, material);
scene.add(mesh);

// lights
scene.add(new THREE.AmbientLight(0xffffff, 0.5));
const dirLight = new THREE.DirectionalLight(0xffffff, 1);
dirLight.position.set(5, 5, 5);
scene.add(dirLight);

const clock = new THREE.Clock();

function animate(): void {
  const elapsedTime = clock.getElapsedTime();
  mesh.rotation.x = elapsedTime * 0.1;
  mesh.rotation.y = elapsedTime * 0.15;

  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

// events
window.addEventListener('mousemove', (event: MouseEvent): void => {
  // add cursor logic here if you need mouse interaction
});

window.addEventListener('resize', (): void => {
  sizes.width = window.innerWidth;
  sizes.height = window.innerHeight;
  camera.aspect = sizes.width / sizes.height;
  camera.updateProjectionMatrix();
  renderer.setSize(sizes.width, sizes.height);
  renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
});

animate();

Going further (still functional)

Loading textures (cleanest way):

const textureLoader = new THREE.TextureLoader();
const colorTex = await textureLoader.loadAsync('/textures/color.jpg');
colorTex.colorSpace = THREE.SRGBColorSpace;
material.map = colorTex;

Good practices for bigger projects

Call geometry.dispose(), material.dispose() and texture.dispose() when you’re done with them. Remove event listeners in a cleanup function. TypeScript makes these teardown functions much safer.

Quick setup (Vite + TypeScript)

package.json (latest as of March 2026):

"dependencies": { "three": "^r183" },
"devDependencies": {
  "typescript": "^5.3",
  "vite": "^5"
}

Important note on types: Three.js has shipped its own TypeScript definitions for years. Try without @types/three first — many people no longer need the extra package.

Run npm run type-check whenever you want to see what TypeScript thinks.

Wrapping up

Your code stays functional. No classes, no big refactor. Just a few types that make everything feel more solid (and safer at runtime).

Drop your current Three.js Journey chapter 1 code into TypeScript and see what happens — I bet you’ll fix three things in the first minute and you will feel like a wizard Harry.

Three.js + TypeScript: Keeping It Functional (No Classes Needed)

Peter Riding — Thu, 05 Mar 2026 17:09:17 +0000

If you're following the Three.js Journey or learning Three.js with plain JavaScript, you might wonder how TypeScript fits in without rewriting everything.

Why TypeScript actually helps with Three.js

Three.js is amazing, but 3D code is picky. Pass the wrong vector? Your mesh disappears. Mix up a camera and a scene? Nothing renders. TypeScript spots those mistakes the second you type them.

It’s especially handy for:

All the vector and matrix math that has to be exactly right
WebXR sessions and input sources (those APIs are a nightmare without types — just note that WebXR support and types evolve quickly in browsers)
Your animation loops, event handlers, and object tracking

The best part? Your code stays exactly the same structure you’re used to.

From plain JavaScript to TypeScript (seriously, tiny changes)

Here’s what your setup probably looks like right now:

const canvas = document.querySelector('canvas.webgl');
const scene = new THREE.Scene();
const sizes = { width: window.innerWidth, height: window.innerHeight };
const camera = new THREE.PerspectiveCamera(75, sizes.width / sizes.height, 0.1, 100);
camera.position.z = 3;
const renderer = new THREE.WebGLRenderer({ canvas });
renderer.setSize(sizes.width, sizes.height);

const clock = new THREE.Clock();
const mesh = new THREE.Mesh(/* ... */);

function animate() {
  const elapsedTime = clock.getElapsedTime();
  mesh.rotation.y = elapsedTime * 0.5;
  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

And here’s the exact same thing with TypeScript sprinkled in:

import * as THREE from 'three';

const canvas = document.querySelector<HTMLCanvasElement>('canvas.webgl');
if (!canvas) throw new Error('Canvas element not found');

let sizes = {
  width: window.innerWidth,
  height: window.innerHeight
};

const camera = new THREE.PerspectiveCamera(75, sizes.width / sizes.height, 0.1, 100);
camera.position.z = 3;

const renderer = new THREE.WebGLRenderer({ canvas });
renderer.setSize(sizes.width, sizes.height);

const clock = new THREE.Clock();
const mesh = new THREE.Mesh(/* ... */);

function animate(): void {
  const elapsedTime = clock.getElapsedTime();
  mesh.rotation.y = elapsedTime * 0.5;
  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

That’s literally it.

The only four things you’ll actually type most of the time

1. The canvas

const canvas = document.querySelector<HTMLCanvasElement>('canvas.webgl');
if (!canvas) throw new Error('Canvas element not found');

2. Simple objects (like sizes)

Use let because we mutate it on resize:

let sizes = { width: window.innerWidth, height: window.innerHeight };

3. Your functions

function animate(): void { ... }

4. Event listeners

window.addEventListener('mousemove', (event: MouseEvent): void => { ... });

Full working example (copy-paste ready)

import * as THREE from 'three';

let sizes = {
  width: window.innerWidth,
  height: window.innerHeight
};

const canvas = document.querySelector<HTMLCanvasElement>('canvas.webgl');
if (!canvas) throw new Error('Canvas element not found');

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(75, sizes.width / sizes.height, 0.1, 100);
camera.position.z = 3;
scene.add(camera);

const renderer = new THREE.WebGLRenderer({ canvas, antialias: true });
renderer.setSize(sizes.width, sizes.height);
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));

// geometry + material + mesh
const geometry = new THREE.BoxGeometry(1, 1, 1, 2, 2, 2);
const material = new THREE.MeshStandardMaterial({ color: 0xa778d8, roughness: 0.4 });
const mesh = new THREE.Mesh(geometry, material);
scene.add(mesh);

// lights
scene.add(new THREE.AmbientLight(0xffffff, 0.5));
const dirLight = new THREE.DirectionalLight(0xffffff, 1);
dirLight.position.set(5, 5, 5);
scene.add(dirLight);

const clock = new THREE.Clock();

function animate(): void {
  const elapsedTime = clock.getElapsedTime();
  mesh.rotation.x = elapsedTime * 0.1;
  mesh.rotation.y = elapsedTime * 0.15;

  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

// events
window.addEventListener('mousemove', (event: MouseEvent): void => {
  // add cursor logic here if you need mouse interaction
});

window.addEventListener('resize', (): void => {
  sizes.width = window.innerWidth;
  sizes.height = window.innerHeight;
  camera.aspect = sizes.width / sizes.height;
  camera.updateProjectionMatrix();
  renderer.setSize(sizes.width, sizes.height);
  renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
});

animate();

Going further (still functional)

Loading textures (cleanest way):

const textureLoader = new THREE.TextureLoader();
const colorTex = await textureLoader.loadAsync('/textures/color.jpg');
colorTex.colorSpace = THREE.SRGBColorSpace;
material.map = colorTex;

Quick setup (Vite + TypeScript)

package.json (latest as of March 2026):

"dependencies": { "three": "^r183" },
"devDependencies": {
  "typescript": "^5.3",
  "vite": "^5"
}

Important note on types: Three.js has shipped its own TypeScript definitions for years. Try without @types/three first — many people no longer need the extra package.

Run npm run type-check whenever you want to see what TypeScript thinks.

Wrapping up

Your code stays functional. No classes, no big refactor. Just a few types that make everything feel more solid (and safer at runtime).

Drop your current Three.js Journey chapter 1 code into TypeScript and see what happens — I bet you’ll fix three things in the first minute and you will feel like a wizard Harry.

Real-Time Dynamic Environment Maps in Three.js: The Holy Donut Technique Explained

Peter Riding — Thu, 26 Feb 2026 17:31:59 +0000

Real-Time Dynamic Environment Maps in Three.js: The Holy Donut Technique Explained

One of the most beautiful techniques in Bruno Simon’s Three.js Journey — a glowing donut that lights and reflects on everything around it in real time.

This lesson blew my mind. Here’s a complete, clear breakdown with code, why each part matters, and pro tips you won’t find everywhere.

What Is a Real-Time Environment Map?

Normal environment maps are static (one fixed HDRI).

A real-time one updates every frame: you render your scene into a texture that then becomes the lighting + reflections for the whole scene.

Result? Moving objects instantly change how everything else looks. Pure magic.

The Analogy That Makes It Click

Imagine a room with a spinning glowing Holy Donut (Bruno’s name for it).

Without real-time map → You take one photo of the room and paste it on the walls. Donut spins → walls stay frozen.
With real-time map → The walls are smart mirrors refreshing 60× per second. Every shiny surface instantly sees the donut’s new position.

The Complete Code Breakdown

1. Background (Visuals Only)

const environmentMap = textureLoader.load('/textures/environmentMaps/cozy-wood-cabin.jpg');
environmentMap.mapping = THREE.EquirectangularReflectionMapping;
environmentMap.colorSpace = THREE.SRGBColorSpace;

scene.background = environmentMap;   // Only background, not lighting

2. The Holy Donut (Your Dynamic Light)

const holyDonut = new THREE.Mesh(
  new THREE.TorusGeometry(8, 0.5, 32, 64),
  new THREE.MeshBasicMaterial({ 
    color: new THREE.Color(10, 4, 2)   // Super bright!
  })
);

holyDonut.position.y = 3.5;
holyDonut.layers.enable(1);   // Crucial
scene.add(holyDonut);

3. Cube Render Target (The Storage)

const cubeRenderTarget = new THREE.WebGLCubeRenderTarget(256, {
  type: THREE.FloatType   // Allows colors brighter than 1.0
});

scene.environment = cubeRenderTarget.texture;

4. CubeCamera (The 6 Smart Mirrors)

const cubeCamera = new THREE.CubeCamera(0.1, 100, cubeRenderTarget);
cubeCamera.layers.set(1);   // Only sees the donut

5. Animation Loop – The Magic Line

const tick = () => {
  const elapsedTime = clock.getElapsedTime();

  holyDonut.rotation.x = Math.sin(elapsedTime) * 2;

  cubeCamera.update(renderer, scene);   // ← This makes it real-time

  renderer.render(scene, camera);
  window.requestAnimationFrame(tick);
};

How It Works (Every Single Frame)

Step	What Happens
1	Holy Donut rotates
2	CubeCamera renders 6 faces (only layer 1)
3	Textures saved into cubeRenderTarget
4	`scene.environment` updates
5	All PBR materials instantly reflect/lit by new donut position

Key Technical Details Explained

Why FloatType?

Normal textures clamp colors at 1.0 → your bright donut (10, 4, 2) becomes boring white. FloatType keeps the glow.

Why Layers?

Main camera sees everything. CubeCamera only sees layer 1 → clean reflections without the helmet baking into itself.

Pro Tips & Gotchas (Added Value)

Performance: 256px is the sweet spot. Try 128 for mobile. You can update the camera every 2–3 frames instead of every frame.
Common mistake: Forgetting layers.set(1) → your whole scene reflects itself (ugly).
When to use this: Hero objects, fire, moving cars, disco balls.
Alternative: THREE.ReflectionProbe for simpler cases or PMREMGenerator + HDRIs for mostly static scenes.

Another dynamic glowing example from the Three.js community

The Final Result

Your scene now feels alive:

Dynamic lighting from moving objects
Real-time reflections on every shiny surface
Clean & performant

This is the kind of effect that makes people stop scrolling.

Huge thanks to Bruno Simon for the brilliant “Holy Donut” example and his incredible teaching in Three.js Journey. If you haven’t bought the course yet — do it. It’s worth every penny.

What normalize() does (and why Three.js raycasting needs it)

Peter Riding — Thu, 12 Feb 2026 16:26:55 +0000

If you’ve seen this line in raycasting examples:

rayDirection.normalize();

and thought “yeah yeah, makes it normal… whatever that means” — here’s what it actually does and why it matters.

The short version

normalize() makes a vector exactly 1 unit long while keeping it pointing in the same direction.

That’s it.

If you start with this:

const rayDirection = new THREE.Vector3(10, 0, 0);

You have a vector pointing along the positive X axis, but its length is 10.

After this:

rayDirection.normalize();

It becomes:

(1, 0, 0)

Same direction. Length is now exactly 1.

What normalization really means

Mathematically, normalization just divides a vector by its length:

normalized = v / |v|

So if the length is 10, every component gets divided by 10.

You can see it directly:

const v = new THREE.Vector3(10, 0, 0);

console.log(v.length()); // 10

v.normalize();

console.log(v.length()); // 1

The direction didn’t change. Only the magnitude did.

Here's a handy diagram to visualize it:

(credit: from a Medium article on text analysis, but it fits perfectly here)

Why Three.js raycasting needs this

The important part: Raycaster expects the direction to be normalized.

There are two main reasons.

Distance calculations assume unit length

When a ray hits something, Three.js calculates how far along the ray the intersection happened.

Those distance values only make sense if the direction vector has length 1.

If your direction vector had length 10, the internal math would scale everything incorrectly. Distances would no longer match world units properly.

A normalized vector makes 1 unit of direction = 1 unit in the scene.
The math assumes it

Many ray–geometry intersection formulas assume the direction vector is a unit vector. The docs explicitly state that the direction must be normalized.

So even if things seem to work without it, you're relying on undefined behavior.

What your ray code is actually doing

const rayOrigin = new THREE.Vector3(-3, 0, 0);
const rayDirection = new THREE.Vector3(10, 0, 0);

rayDirection.normalize();

const raycaster = new THREE.Raycaster(rayOrigin, rayDirection);

This creates:

A ray starting at x = -3
Shooting straight right along the X axis
With a properly normalized direction

Now when you call:

raycaster.intersectObjects(scene.children);

The intersection distances will be correct and consistent.

Important detail: normalize() mutates

One thing people miss:

vector.normalize();

This changes the original vector.

If you need the original untouched:

const direction = original.clone().normalize();

How to control ray length (don’t scale the direction)

If you want to limit how far the ray checks for intersections, don’t multiply the direction.

Do this instead:

raycaster.far = 100;
raycaster.near = 0;

Keep the direction normalized. Let the raycaster handle range.

Quick mental model

Think of a direction vector like a compass needle.

Before normalization, it might be a 10-meter long arrow.

After normalization, it’s a 1-meter arrow pointing the same way.

Raycasting wants the 1-meter version so all distance math stays clean and predictable.

One sentence explanation

normalize() makes your direction vector exactly 1 unit long while keeping it pointing the same way — and Three.js raycasting depends on that.

Mastering Shadows in Three.js: Setup, Configuration, and Optimization

Peter Riding — Thu, 29 Jan 2026 17:28:22 +0000

Shadows are essential for adding depth and realism to Three.js scenes. They help ground objects and enhance visual interest, but configuring them effectively usually involves a bit of trial and error the first time around. I’ve lost count of how often a scene looked “broken” simply because one mesh wasn’t set to receive shadows. This guide builds on fundamental lighting concepts, focusing on practical implementation for various light types. We'll cover enabling shadows, tuning for quality, and integrating them cleanly with the rest of your scene.

Enabling Shadows: The Basics

To incorporate shadows, start by activating shadow mapping in the renderer. This prepares the system to calculate and render shadows for compatible lights and objects.

renderer.shadowMap.enabled = true;
renderer.shadowMap.type = THREE.PCFSoftShadowMap;

The type property determines shadow appearance and performance:

BasicShadowMap: Fastest option, but results in hard, blocky edges. Suitable for quick tests.
PCFShadowMap: Provides softer edges with moderate performance.
PCFSoftShadowMap: Offers smoother, more realistic shadows; a balanced choice for most applications.
VSMShadowMap: Produces very soft shadows, but can introduce light bleeding or blur without careful tuning.

Additionally, configure individual elements:

For lights: light.castShadow = true;
For meshes that cast shadows: mesh.castShadow = true;
For meshes that receive shadows: mesh.receiveShadow = true;

If nothing shows up, double-check these three flags first — it’s almost always the culprit in fresh setups, especially for floors and large background meshes.

Configuring Shadows for Directional Lights

Directional lights, often used for simulating sunlight or moonlight, require specific shadow camera adjustments. The shadow map resolution and frustum define quality and coverage.

mapSize: Controls texture resolution. Lower values (e.g., 256) improve performance at the cost of sharpness; higher values yield crisper shadows but increase GPU load.
Frustum bounds (top, right, bottom, left): Limit the shadow-casting area. Tighter bounds dramatically improve detail in the focused region.
near and far: Set the depth range. Objects outside this won't cast shadows; a narrower range also reduces common precision artifacts.

Example configuration for a contained scene:

directionalLight.shadow.camera.top = 8;
directionalLight.shadow.camera.right = 8;
directionalLight.shadow.camera.bottom = -8;
directionalLight.shadow.camera.left = -8;
directionalLight.shadow.camera.near = 1;
directionalLight.shadow.camera.far = 20;

In practice, settings like a 256 mapSize and ±8 bounds work well for balanced results, and tightening the frustum usually gives a bigger quality boost than simply cranking the resolution.

Setting	Purpose	Example	Trade-off
mapSize	Shadow resolution	256 (low) or 1024 (high)	Performance vs. sharpness
top/right/bottom/left	Frustum bounds	±8	Coverage vs. quality
near/far	Depth range	1 / 20	Precision vs. artifacts

When tuning directional lights, helpers are invaluable:

scene.add(new THREE.CameraHelper(directionalLight.shadow.camera));

Seeing the shadow frustum in the scene often explains blurry edges or missing shadows instantly.

Shadows Across Light Types

Shadow implementation varies by light type, each using a different camera projection. Common properties like shadow.mapSize and shadow.camera.far apply universally, but additional settings differ.

PointLight: Employs a cubemap for omnidirectional shadows. Adjust shadow.mapSize per face and shadow.camera.far for range. These are resource-intensive, so I usually reserve them for small, focused light sources.
DirectionalLight: Uses an orthographic camera for parallel projection. Configure frustum bounds and clipping planes carefully, as described above.
SpotLight: Relies on a perspective camera. Set shadow.mapSize, shadow.camera.fov, near, and far to match the light's cone.

Reference table for quick setup:

Light Type	Shadow Camera	Key Settings
PointLight	Cubemap	mapSize (per face), camera.far
DirectionalLight	Orthographic	mapSize, top/right/bottom/left, near/far
SpotLight	Perspective	mapSize, fov/near/far

I recommend testing shadow setups in a stripped-down scene with a cube and a plane before layering in complex geometry — it saves a lot of guessing later.

Integration and Fine-Tuning

To avoid overly dark shadowed areas, combine shadows with a low-intensity AmbientLight for subtle fill:

const ambientLight = new THREE.AmbientLight(0xffffff, 0.4);
scene.add(ambientLight);

For iterative adjustments, a debugging tool like dat.GUI is extremely helpful:

gui.add(light.shadow, 'mapSize.width')
  .min(128).max(2048).step(128)
  .name('Shadow Resolution');

gui.add(light.shadow.camera, 'near')
  .min(0.1).max(10).step(0.1);

When shadows look glitchy, speckled, or slightly detached from objects, small tweaks to:

light.shadow.bias
light.shadow.normalBias

often fix acne or floating edges without needing to push the shadow resolution higher.

Shadows also interact heavily with materials; incorporating ARM textures (ambient occlusion, roughness, metalness) can dramatically improve how light and shadow behave across surfaces.

Conclusion

Proper shadow setup transforms flat Three.js scenes into immersive environments. Start by enabling shadows everywhere they’re needed, tighten each light’s shadow camera before increasing resolution, and only push map sizes once the basics are dialed in. In my experience, those three steps alone account for most real-world shadow improvements.

Experiment with these techniques in your own projects, and don’t be afraid to temporarily drop quality while tuning — it’s much easier to debug shadows when everything runs fast.

Understanding Three.js Lighting — A Concise Reference

Peter Riding — Thu, 18 Dec 2025 18:35:23 +0000

Understanding Three.js Lighting — A Concise Reference

TL;DR: Start with an Ambient/Hemisphere fill, add a Directional for sun, use Point/Spot sparingly for local effects, and RectArea for studio soft light.
Read time: ~3–4 minutes

Lighting transforms a flat scene into something believable. This short reference explains the six core Three.js lights (plus a note on LightProbe), when to use them, and practical performance tips.

The lights at a glance

Light	Real-world	What it does	Use / performance	Notes
AmbientLight	Overcast / studio fill	Uniform light, no shadows	✅ Very cheap — always add a little	Use low intensity (0.1–0.5) to avoid flatness
DirectionalLight	Sun / flood	Parallel rays, good shadows	🟡 Moderate — efficient for large scenes	No distance falloff; tune `shadow.camera` for quality
HemisphereLight	Sky above / ground below	Sky color on up-facing, ground color on down-facing	✅ Cheap — natural outdoor tint	Params: `skyColor`, `groundColor`, `intensity`
PointLight	Bulb / candle	Radiates in all directions, attenuates	🔴 Expensive if many + shadows	Use `distance` and `decay` (constructor: `color, intensity, distance, decay`)
RectAreaLight	Softbox	Soft directional illumination	🔴 Expensive — studio-quality	Works only with `MeshStandardMaterial` / `MeshPhysicalMaterial`; requires examples lib init
SpotLight	Flashlight / headlight	Cone-shaped beam; adjustable angle & penumbra	🔴 Most expensive if casting shadows	Needs a `target` added to the scene; tune `angle`, `penumbra`, `decay`

Note — LightProbe: Useful for image-based PBR lighting (cheap ambient for materials). Pairs with environment maps and PMREMGenerator.

Quick, practical setups

Assumes scene and THREE are available.

1) Outdoor / daylight (realistic, moderate cost)

scene.add(new THREE.AmbientLight(0xffffff, 0.3));

const sun = new THREE.DirectionalLight(0xffffff, 0.9);
sun.position.set(10, 15, 5);
sun.castShadow = true;
sun.shadow.mapSize.set(1024, 1024);
sun.shadow.camera.left = -20;
sun.shadow.camera.right = 20;
sun.shadow.bias = -0.0005;
scene.add(sun);

Good for landscapes and day/night cycles. Ambient prevents pitch-black shadows.

2) Interior / dynamic (medium cost)

scene.add(new THREE.AmbientLight(0xffffff, 0.5));

const lamp = new THREE.PointLight(0xffeecc, 1, 15, 2); // color, intensity, distance, decay
lamp.position.set(0, 3, 0);
lamp.castShadow = true;
scene.add(lamp);

const accent = new THREE.SpotLight(0xff9000, 0.8, 30, Math.PI / 6, 0.2, 2);
accent.position.set(5, 4, 3);
scene.add(accent);
scene.add(accent.target); // remember to add the target to the scene

Limit shadow-casting lights to a few; prefer baked lighting for fixed interiors.

3) Studio / product (higher cost — high quality)

import { RectAreaLightUniformsLib } from 'three/examples/jsm/lights/RectAreaLightUniformsLib.js';
RectAreaLightUniformsLib.init();

scene.add(new THREE.AmbientLight(0xffffff, 0.4));

const key = new THREE.RectAreaLight(0xffffff, 2, 4, 4);
key.position.set(-5, 4, 3);
key.lookAt(0, 0, 0);
scene.add(key);

const back = new THREE.DirectionalLight(0xff9900, 0.6);
back.position.set(0, 3, -8);
scene.add(back);

Note: RectAreaLight only lights MeshStandardMaterial / MeshPhysicalMaterial and requires RectAreaLightUniformsLib.init() (examples helper).

Performance rules of thumb

Start with Ambient (0.2–0.3). Cheap and prevents black areas.
Use 1 Directional for sun/moon effects; tune shadow.camera bounds for shadow quality.
Cap Point/Spot lights to ~3–5 in real-time; each shadowed light is costly.
Disable shadows on lights that don’t need them: light.castShadow = false.
Decay = 2 is standard for realistic attenuation with PointLight/SpotLight; modern Three.js uses physical units by default.
Shadow tuning: reduce shadow.mapSize, constrain shadow.camera, and use shadow.bias to fight acne.

Key takeaways

2–4 lights is usually enough — more lights ≠ better visuals, just more cost.
AmbientLight is your safety net. Use a low intensity to soften contrast.
Reserve Point/Spot/RectArea for visual impact where they matter.
Profile your scene (Three.js DevTools / Chrome DevTools) to find bottlenecks.

Normal Maps vs Displacement Maps in Three.js: What Beginners Get Wrong

Peter Riding — Thu, 11 Dec 2025 18:53:43 +0000

Normal Maps vs. Displacement Maps in Three.js: What They Do and When to Use Them

So today I decided to write about another sticky bit in my Three.js journey (if you're also following Bruno Simon's course, no pun intended). Normal maps and displacement maps get mixed up constantly. They sound similar, they're both "maps," and many people assume they're interchangeable. They aren't. This guide explains clearly what each does, when to use it, and how to implement both correctly in Three.js.

Normal map → fakes bumps via lighting. Geometry doesn’t move. Cheap. Use for fine detail.
Displacement map → actually moves the mesh’s surface. Shadows, edges, and collisions follow the bumps. Heavier on performance. Best for big shapes or when the outline of the object should change.

Pro tip: Displacement for big shapes, normal maps for micro detail. Combine both for the best results.

This is what I wish someone had explained when I started learning textures in Bruno Simon's Three.js Journey course.

What Each Map Does

Normal map → fakes bumps by changing how light hits the surface. The shape doesn’t actually move, so edges and outline stay flat.
Displacement map → moves the actual surface of the mesh based on brightness (white = raised, black = flat). Shadows, edges, and intersections update naturally.

Why This Matters in Practice

Normal maps: Cheap, mobile-friendly, no extra vertices required. Great for fine detail like scratches, pores, fabric texture.
Displacement maps: Real depth, shadows, and occlusion, but require enough vertices to look good. Low-poly meshes will appear blocky. More vertices = higher GPU cost.

Quick Three.js Implementation

// Load textures
const loader = new THREE.TextureLoader();
const colorMap = loader.load('albedo.jpg');
const normalMap = loader.load('normal.jpg');
const displacementMap = loader.load('displacement.jpg');
const aoMap = loader.load('ao.jpg');

// Ensure all maps tile the same way
[colorMap, normalMap, displacementMap, aoMap].forEach(t => {
  t.wrapS = THREE.RepeatWrapping;
  t.wrapT = THREE.RepeatWrapping;
  t.repeat.set(1, 1);
  t.flipY = false; // required for glTF textures
});

// Set color map to sRGB; others stay linear
colorMap.colorSpace = THREE.sRGBColorSpace;

Now create your geometry with enough vertices for displacement:

// Geometry — displacement needs vertices
const geometry = new THREE.PlaneGeometry(5, 5, 200, 200);

// AO maps require uv2
geometry.setAttribute('uv2', new THREE.Float32BufferAttribute(geometry.attributes.uv.array, 2));

Then apply the material:

// Material
const mat = new THREE.MeshStandardMaterial({
  map: colorMap,
  normalMap: normalMap,
  displacementMap: displacementMap,
  displacementScale: 0.3,
  displacementBias: -0.15,
  aoMap: aoMap,
  aoMapIntensity: 1.0,
});

const mesh = new THREE.Mesh(geometry, mat);
scene.add(mesh);

Key Controls: displacementScale & displacementBias

displacementScale

Think of this as how tall or deep the bumps are.
Small value → tiny bumps, almost flat.
Large value → big bumps, very pronounced.

displacementBias

Think of this as moving the whole mesh up or down.
Negative → lowers the mesh.
Positive → raises the mesh.
Useful so the mesh doesn’t “sink” below the floor when using a displacement map.

Tip: Use a GUI (e.g., lil-gui) to tweak these interactively while watching shadows.

Common Mistakes & Fixes

Displacement looks blocky: Increase segments or use LOD.
Normal map looks inverted: Check normalScale and orientation.
Mesh shifts after displacement: Remember vertices actually move; anything parented or baked will follow.

When to Use What

Mobile / low-power: Normal map only.
Close-ups with silhouette changes: Displacement + normal.
Large terrain / world: Displacement is fine but use LOD or multiple mesh resolutions to reduce GPU load.

My Takeaways from Week 1 of Bruno Simon’s Three.js Journey Course

Peter Riding — Thu, 04 Dec 2025 18:39:09 +0000

So this week I finished Week 1 of Bruno Simon’s Three.js Journey course, and I just wanted to jot down some of the more complicated parts in the hope it will help would-be learners or anyone else who decides to tackle the course.

What is Three.js?

Three.js — or as I like to call it, “The Magic Triangle Library” — is a JavaScript library that makes working with 3D graphics on the web much easier. Instead of writing low-level WebGL code yourself, Three.js gives you simple tools to create 3D scenes, objects, animations, lighting, and more, all directly in the browser.

How Do We Use It?

There are three core components that work together in Three.js: the Scene, the Camera, and the Renderer.

The scene is like a movie set where all your objects live.
The camera is the viewpoint looking at that set.
The renderer is the engine that takes the scene and camera and draws the final image onto the canvas (the screen the user sees).

Here’s the flow:

You place objects into the scene.
The camera views the scene.
The renderer takes that view and draws it onto the canvas.

Sticky Point 1: Animations

And in particular, delta time and how it allows animations to run at the same speed on different monitors. This took a few moments (plus maybe a few more to really sink in), but in the end it is quite simple.

The Problem

Different monitors can have different FPS (frames per second) — the average is 60, but some can be much higher. This means the window.requestAnimationFrame() function will be called at different speeds depending on the monitor’s FPS.

window.requestAnimationFrame();

So we need a way to speed up or slow down the animation to make sure it runs at the same speed across monitors.

The Solution

This is where delta time comes in. If we know how much time has elapsed since the window.requestAnimationFrame() function was last called (the delta time), we can multiply a fixed value by it, such as 0.001.

If the frame rendered fast (small deltaTime), the movement is small.
If the frame rendered slow (large deltaTime), the movement is bigger.

Over 1 second, you always move the same total amount.

let time = Date.now();

const tick = () => {
    const currentTime = Date.now();
    const deltaTime = currentTime - time;
    time = currentTime;

    // Update with deltaTime
    mesh.rotation.y += 0.001 * deltaTime; // Adjust multiplier for speed

    renderer.render(scene, camera);
    window.requestAnimationFrame(tick);
};
tick();

Sticky Point 2: UV Coordinates & Texture Mapping

When you add a texture (image) to a 3D object, Three.js needs to know which part of the image goes where on the mesh. That’s where UVs come in.

UVs are coordinates (0 → 1) that tell the texture which part of the image to use:

(0, 0) = bottom-left corner of the texture
(1, 1) = top-right corner
(0.5, 0.5) = center

Think of it like this: every vertex on your mesh has a UV coordinate that says “use this part of the texture image.”

UVs aren’t pixels — they’re normalized coordinates between 0 and 1, representing percentages:

0.0 = 0% (start)
0.5 = 50% (middle)
1.0 = 100% (end)

When you tile a texture (repeat it), UVs go outside the 0–1 range. That’s where wrapS and wrapT come in:

wrapS (horizontal) and wrapT (vertical) control what happens when UVs exceed 0–1
RepeatWrapping → texture repeats/tiles
ClampToEdgeWrapping → texture stretches

Example:

const texture = new THREE.TextureLoader().load('texture.jpg');
texture.wrapS = THREE.RepeatWrapping;
texture.wrapT = THREE.RepeatWrapping;
texture.repeat.set(4, 4); // Tile 4×4 times

One key rule:

Only color textures (albedo) should use THREE.sRGBColorSpace.

Normal maps, roughness maps, displacement maps, etc. should not, because they store data, not color.

Overall I really enjoyed my first week and I found Bruno to be a great teacher and very funny, I also like his consistent hints about the "scary" shaders (I'm excited already). Stay tuned for next week I will cover sticky point number 3 and dive deeper into custom geometries.

Why I’m Betting My Career on VR Marketing (And Learning Three.js)

Peter Riding — Thu, 27 Nov 2025 18:13:31 +0000

I've been fascinated by marketing since university—specifically the psychology behind human behavior.

Why do people make the decisions they do?
What triggers action?
How do you persuade without being manipulative?

Back in 2017, I had an insight that completely changed my direction:
VR and immersive experiences are the future of marketing because they tap into human psychology on a deeper level than flat ads ever could.

I shared the idea with people around me. Most didn’t get it.
But I couldn’t unsee it.

The Pivot to Code

Eventually I realized something important:

If I wanted to build these immersive experiences, I had to learn how to code.

So I did the only thing that made sense: I moved from my desk job in Australia, then traveled across Asia. I taught English online to support myself while studying programming in every spare moment.

Like many beginners, I got trapped by the “Learn JavaScript in 1 Month” YouTube videos.
Spoiler: that wasn’t happening.

So I reset. I took Harvard’s CS50 and followed Eloquent JS, learned the fundamentals properly, and eventually got comfortable building sites with React and Next.js.

I enjoyed it—but something still felt missing.

The "Aha!" Moment: WebXR

Then it clicked:

VR marketing.

The old idea returned, but this time I had real programming skills.
So I asked the obvious question:

Can I actually build these experiences now?

A short deep dive later, the answer was clear:

Yes.

With tools like Three.js, React Three Fiber, WebXR, and modern browsers, immersive experiences are becoming native to the web.
And JavaScript is at the center of it.

Why I'm All In

I realized I’m positioned perfectly at this intersection:

Psychology: I understand what makes experiences engaging, emotional, and memorable.

Engineering: My React/Next.js background gives me the technical foundation.

Creativity: VR lets me build worlds that people actually explore, not skip.

My goal:
To help move marketing from boring, interruptive ads → to immersive, interactive worlds people enjoy.

What's Next?

I’m dedicating the next 6 months to mastering Three.js and WebXR.

I’m not an expert. I’m a learner.
And I’m documenting the entire messy, challenging, exciting journey right here on dev.to.

I’ll be sharing:

Weekly devlogs of my VR/3D projects

Technical hurdles (and how I solve them)

My transition from 2D React dev → 3D creative developer

If you want to follow along, I post daily updates on Twitter: @peterridingdev

Let’s build the future of the web. 🚀