When will three.js v182 be released?

Questions
1

When will three.js v182 be released?

2

The release has been delayed to December 10, 2025.

2 Likes
3

Take your time! I would rather have a release every 2 months rather than every 1 month if that will help you properly solve some of the challenging problems you are facing and to implement new features.

2 Likes
4

agreed, it will be nice if the release takes few months than sooner so we can enjoy not having worry updating every so often.

1 Like
5

I feel that it’s fair to mention, albeit a bit controversial in this community, but what you’re describing is semantic versioning. Most other software is published like that (technically though, even three is).

So it’s not unusual to feel this way :slight_smile:

In my case for example, I would be fine with one version every couple of years. Most of the work I’ve done in my career, could have been done on version 77 or something like that.

The reason for this is that each version of threejs is basically as broken as the last one. You never know what kind of regressions have been introduced. For example, it looks like the WebGPU renderer slowed down, this is now going to be present in multiple versions until it is fixed. The problem is if you are using one feature, it gets fixed in some version X, but some other feature was broken.

Ultimately when you download it from NPM it HAS to have semantic versioning. Three doesn’t have a major version, only minors (and oddly, sometimes patches). There is no guarantee (by using versioning) that it has the same interface as before.

6

I’m curious, why do you update so often? Do you do an update with every release?

7

I also update a series of my programs with every release. I am working with WebGPU, so I want to see what new features/improvements they have added and to assist with bug-spotting.

Doesn’t every program have errors? I play Fortnite STW for fun. This game has been around for decades. However, every time they add an “improvement”, they create an error somewhere.

I have not written any extremely technical programs, but I used to write a lot of technical memos. After writing a very long and detailed memo, I often realized that I could have said the same thing better with a lot fewer pages. I expect that is happening with WebGPU. They tackle a big change, add it to the program and bugs appear and they discover that they could made the changes more efficiently or that they can integrate the changes with other changes. In many ways, a program is like an evolving organism which might go through some ugly variations.

And as I progress in writing my own programs, I often discover a simpler mathematical solution which has already been implemented in three.js. (Airplane rotation is a good example. I spent years in my spare time trying to create confusing subroutines using Napier equations to correctly pitch, bank and yaw the airplane. With three.js, I discovered that I could do the same thing using linked objects and a handful of instructions.)

The creators of three.js understand math and GPUs and things “never dreamt of in my philosophy”. I am happy to have them creating a path for me to follow which is far better than anything I could have done.

8

Well, there are ways to catch regressions. Automated tests for example. Three has a bunch now, didn’t have before, i imagine it helps capture a lot of bugs. I imagine you don’t work in an organization and don’t have to ship software often?

9

Oh no, I don’t update very often, maybe once every 6 months or year, when there is a major changes on my projects.

1 Like
10

You are correct. I do not ship software. My programs are available online on my GitHub repository. So I can make changes as frequently as I like. I generally learn something new with each version that requires me to change my programs.

1 Like
11

So you do ship software just with different constraints. Imagine if someone were using your programs, how would they be using them? Do they have to clone the repo and then link it into their project? Then they have to update manually. If you just change your code their project breaks. In order to avoid all that we use tools like npm and versioning.

12

I don’t normally update often but because of this thread, I thought its about time I must update my major three.js projects.

  1. Wrist watch A.R.
  2. Immersive experience.
  3. Open world experience.

You are right, I should update every release or at least every 3 months. I found some parts have been obsoletes which requires quick fixes, also noticed the 182 release improvements; the rendering seems more realistic with no requirement of postprocessing for both WebGL and WebGPU, and the GLTFLoader seems to be more efficient its loading much quicker even on slow internet conditions. Last year I had a client that said the loading often crashes which made me quit for a while because of loading issues, now it never failed it loads no matter what. And the game-play feels smooth or it feels smooth because I haven’t visited the game for while. Also the A.R. capabilities seems faster that it was before why my projects got rejected because the A.R often freeze or the watch 3d model wasn’t loaded.

13

That’s not me lol :joy:.

My style has been:

  1. Get a job
  2. install threejs
  3. Work with that version for as long as the job lasts

GLSL never changed (until TSL was invented, but I don’t use it), the scene graph never changed. BufferGeometry never changed and these three pretty much constitute the entirety of threejs for me, I don’t use anything else.

From my perspective, the only more or less noticeable thing was when the PBR shader was introduced.

1 Like