DEV Community

Cover image for My Takeaways from Week 1 of Bruno Simon’s Three.js Journey Course
Peter Riding
Peter Riding

Posted on

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

#beginners #learning #webdev #threejs

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:

  1. You place objects into the scene.
  2. The camera views the scene.
  3. 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();
Enter fullscreen mode Exit fullscreen mode

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();
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)