SimonDev

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

One last little trick: Normal fog blending kinda sucks, it basically just blends towards a colour. Instead, split that into 2 separate calculations, one for extinction and one for in-scattering. • extinction = darker silhouettes • in-scattering = brighter haze

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

The terrain looks decent, but it's lacking a sense of depth. Basic distance fog is easy: blend toward a blurred sample of the sky as the terrain gets farther away. It works, but it doesn't look awesome.

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

Terraces are another cheap shaping trick. Split the height range into steps, but keep a short ramp between each plateau. That gives us broad, flat areas without making every transition a vertical cliff.

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

The same trick works with Voronoi noise. Notice this gives a sort of "pockmarked" effect.

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

There are other types of noise. Voronoi noise scatters a point inside each grid cell, then calculates the distance to the nearest one. Checking the surrounding 3×3 cells gives us a completely different noise function.

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

One layer of noise is smooth, but you need more to get convincing terrain. You can use fBM (fractional brownian motion). Sample the noise repeatedly, at different scales, adding more detail iteratively. Extra: pow() reshapes the height range. I used "3" to flatten valleys and make peaks stand out.

If you wanna make better looking procedural terrain, this thread is full of simple tricks you can use straight away. #threejs #gamedev

Noise is used everywhere in games: terrain, animations, camera shake, and more. But it can still feel like magic. How do you turn greyscale blobs into real effects? Here are a few practical ways to use it. #threejs #shaders

For camera shake, use vector noise: offset = vectorNoise(time); This is just noise that gives you a 2D "random" value back. You can get the same thing by doing: offset.x = noise(time, seed1); offset.y = noise(time, seed2); This gets you smooth but unpredictable movement, with no jarring jumps.

Noise is used everywhere in games: terrain, animations, camera shake, and more. But it can still feel like magic. How do you turn greyscale blobs into real effects? Here are a few practical ways to use it. #threejs #shaders

fBM noise is an amazing starting point for procedural terrain. Treat the noise as a heightmap, where brightness = elevation. Here, we're simply taking a grid and using fBM to choose the height at any given point.

Noise is used everywhere in games: terrain, animations, camera shake, and more. But it can still feel like magic. How do you turn greyscale blobs into real effects? Here are a few practical ways to use it. #threejs #shaders

There are lots of different flavours of "basic" noise. Value, Gradient, Perlin, Simplex. They all look a bit different, but the general idea is: use them as a source of controlled variation.

Noise is used everywhere in games: terrain, animations, camera shake, and more. But it can still feel like magic. How do you turn greyscale blobs into real effects? Here are a few practical ways to use it. #threejs #shaders

Most noise starts with a super simple trick: Give it some input, like a position (x, y), and it returns a repeatable pseudo-random value. The hash function internally does a bunch of math to spit out something that "looks random enough".

Optimization can be tricky. Here’s how to go from drawing a few hundred trees to virtually unlimited in Three.js, step by step. This will be high level, but not so much that you can’t fill in the details. #threejs

Once you've made it through all these steps • Reuse materials • Batch/instance • Optimize data • Cull • LOD/imposters We're hitting 1 million+ trees, for very little CPU/GPU cost.

Optimization can be tricky. Here’s how to go from drawing a few hundred trees to virtually unlimited in Three.js, step by step. This will be high level, but not so much that you can’t fill in the details. #threejs

At this point, the last lever left is reducing quality. LOD (level-of-detail) works by dropping detail with distance. Further away objects, you swap meshes (LOD0 -> LOD1 -> LOD2) and nobody notices (hopefully) With instancing, you'll have to do this manually with an InstancedMesh for each level.

Optimization can be tricky. Here’s how to go from drawing a few hundred trees to virtually unlimited in Three.js, step by step. This will be high level, but not so much that you can’t fill in the details. #threejs

You can quantize way further than most people think. It’s possible to squeeze a ~56B vertex down to ~16B with packing + quantization. TSL makes unpacking clean (override attributes via node API). Source : x.com/SebAaltonen/... This gets us to 50k+ trees.

Optimization can be tricky. Here’s how to go from drawing a few hundred trees to virtually unlimited in Three.js, step by step. This will be high level, but not so much that you can’t fill in the details. #threejs

Instancing allows us to tell the GPU in a single draw call: "hey, draw this thing a zillion times". No need for the CPU to constantly submit draw commands, which alleviates the load on the CPU and shifts the bottleneck to the GPU. We're hitting 30k+ trees now.

Optimization can be tricky. Here’s how to go from drawing a few hundred trees to virtually unlimited in Three.js, step by step. This will be high level, but not so much that you can’t fill in the details. #threejs

Low-hanging fruit: stop duplicating assets. Share geometry & materials across instances and you'll see immediate improvements in the framerate. This change alone gets us to ~700–800 trees at 60fps.

Optimization can be tricky. Here’s how to go from drawing a few hundred trees to virtually unlimited in Three.js, step by step. This will be high level, but not so much that you can’t fill in the details. #threejs

The first step is to make sure you’re measuring the right things. You need both CPU time and GPU time, to understand where the problems lie. I use three-perf or the Three.js Inspector so I can see both numbers easily.