What is three.js?

I’m on board with that. I don’t think that needs of games are inherently different from needs of interactive experiences. Games are interactive experiences, in some ways - games have much stricter constraints on responsiveness. When it comes to load times - I think that’s a fair point, but for the most part - this is due to sheer volume of assets. Plenty amazing looking games have shockingly fast load load times, I feel that often it’s a conscious trade-off by the developer, to forgo optimizing load times and spend resources else-where. I feel on the web you have similar trade-offs quite often, my entire game engine was written with the web in mind. Relevant to my earlier point - it features asynchronous asset loading.

I agree that there are plenty of differences, but I feel those differences more quantitative rather than qualitative. Games are just larger, more complex interactive experiences.

I should make a disclaimer that I’m not trying to push for three.js to be a game-oriented 3d library. I’m just making the case for aligned interests.

That may prove to be a path to better support for low-level API as well. Something that a few people, apart from myself, have voiced in the past.

Having seen several attempts at complete re-writes of the renderer from scratch - I feel a bit doubtful though. Let the time prove my doubts unfounded, I’d like that.

I feel that the incremental work that has brought the renderer to the state that it is in currently has been a lot more successful. Renderer used to be 1 single JS file. Perhaps surgical architectural changes to the existing code would yield a more reliable path towards support of WebGL2 and WebGPU.

2 Likes

Yeah - or perhaps a complete refactor of the WebGLRenderer to split it up into small modules would be less work than expected. I’ve done this before with a large codebase and found it satisfying and much easier than expected. Never anything as complex as the WebGLRenderer though.

However, I don’t think there’s any will to do this - as has been clearly pointed out in this thread, @mrdoob and the other major contributors can only handle so much development activity and they are forced to prioritise. A major refactor/rebuild of the renderer would surely lead to more contributors to that code, but it’s so far down the list of priorities it’ll probably never happen.

Sure, and by the way I was not dismissing your use case - the goal of three.js should be flexibility. It should be possible to use as the base of a game engine or for small interactive websites, or anywhere else.

However, if you truly want a say in the way three.js is developed, you probably need to get actively involved on Github on a daily basis.

1 Like

Babylon’s code base, despite being written in TypeScript, is tightly coupled (to me that means a bit more disorganized). Three.js classes are much more loosely coupled making them more flexible and easier to work with, and also easier not to pull in the entire jungle and the gorilla and the banana when all you want is the banana.

Like @pailhead said, you can use just Object3D in Node.js to do some math. But you can not do this with Babylon. Take a look at Babylon’s equivalent of Object3D, and you will see that it imports, like, everything from the entire Babylon jungle:

Take a peek at what Babylon’s Node imports indirectly when it imports from ./scene:

It… imports… everything in the whole entire library.

Now take a look at Three’s super simple Object3D class, and you’ll see that it only depends on math classes:

Three.js is so much more organized! It was a breeze to port the things I needed in Object3D from JavaScript to AssemblyScript.

I wrote about an idea for an automatic-instancing feature on @pailhead’s three-instanced-mesh repo, but in a way that would be 99.99% decoupled from WebGLRenderer (in the sense of not having to modify much, if anything at all, inside WebGLRenderer). Please share if you have any ideas on the InstancedMeshGroup idea there.

It is a high-level idea currently, but I do believe the community could benefit from something like it existing, while at the same time keeping the code maintainable.

6 Likes

Even if this is not something we can add to the repo, it would be great to have a working example of this that we can refer to.

Do you have time to create a live example using codesandbox or glitch and open a new discussion thread here?

3 Likes

When I finally find the time for it (possibly in a matter of months of even years unless I can find a company that will pay me to work on it for the sake of open source :laughing:) I will gladly post it up. :slight_smile:

2 Likes