Pros and cons of three.js

Discussion
1

I have a task in my job to find out about best and worst features in popular 3D JS libraries like three.js. I would be grateful for the opinion of the experts in this topic. What do you like the most in this solution and what would you like to be improved?

2

I’ll give it a try:
:unicorn: Pros:

  • easy to learn
  • plenty of examples
  • large community, lots of third-party plugins
  • good documentation
  • great performance
  • PBR rendering
  • support for most of the popular model formats
  • Has own editor

:poop: Cons:

  • No deferred rendering pipeline, only forward. This makes a lot of modern rendering techniques impossible/infeasible to implement with three.js
  • Not a game engine. If you’re looking for features beyond rendering - you wont find many here. (notably: Physics, Particles, Input, Sound, Asset Management, Scripting etc.)
  • API is geared towards novices, many advanced features are hidden from the programmer.
  • If you use three.js, other kids will get super jealous and stop playing with you
  • You will start developing complex applications with so little effort that you will not be challenging yourself, this will make you bored and you will gradually lose your skills
5 Likes
3

I hope you don’t mind if I add some tiny comments^^:

I always had the impression that deferred rendering without proper MRT support is problematic. We might give this a new try with WebGL 2. A basic implementation of deferred rendering can be found here:

https://threejs.org/examples/webgldeferred_animation.html

three.js does not have the aspiration to be a game engine. So I think it’s not fair to criticize this point. It’s like buying a motor cycle and then complaining that is not a car :wink:

BTW: three.js does provide sound entities like THREE.PositionalAudio for realizing spatial sound.

3 Likes
4

I always had the impression that deferred rendering without proper MRT support is problematic

I absolutely agree – I’m a bit curious about this, though. Is there a reason that the WEBGL_draw_buffers extension wasn’t supported in WebglRenderer? That should have enabled MRT, right? Either way I’m looking forward to WebGL2 MRT and deferred rendering in THREE, as well! The EffectComposer doesn’t quite cut it in a lot of ways.

5

The support of the extensions is not so satisfying. Only 2% of mobile devices support WEBGL_draw_buffers. And not even all desktops.

https://webglstats.com/webgl/extension/WEBGL_draw_buffers

1 Like
6

I agree with Mugen87, i actually love THREE for being “just” a render engine, it perfectly covers all required basics without forcing you into a specific architecture, perfectly suited for a custom engine, perfectly suited as lightweight library for apps.

What i agree on, it isn’t suited for those expecting all out of box at once. But it does provide most, especially with the examples and the code provided by the community.

I’m using a deferred renderer since years, but the support is still very varying asides of it being generally more demanding.

Mobile has generally better support, they all come with a graphicscard and even cheap ones support WebGL2, phones have a shorter lifespan as well, most buy a new phone every 1-2 years. Desktops are rather rarely renewed, some 5-10 years or more asides of office machines often not even providing a graphics card.

7

Ha, I feel like I failed on an epic scale in terms of communication. I have tested out a bunch of other libraries and frameworks out there, and three.js is the most “pure” rendering library, this is a negative to a lot of people who are starting out, I think. For me - I love it.

Back when positional audio was being introduced - I argued against it - I feel that it has no place in three.js, but whatever, enough people like it and it doesn’t have much of an effect on my usage.

Yeah, me too, my rendering pipeline is built on top of three.js, and I guess it’s not really unique, but the point is - that’s a fair amount of custom code which a novice can not be expected to write.

That renderer is really poor performance-wise. I’m glad it’s there, but I would never use it in production, so examples is absolutely the right place for it. Big props to everyone who worked on it.

I thought that my last two negative points would see the most heat :slight_smile:

Anyways, glad to see some discussion!

1 Like
8

I will say that the documentation is incredibly good and clean. THREE was one of the first libraries I learned and I didn’t really appreciate it at the beginning. As time went by, and I picked up new libraries or frameworks, I could really see the difference in quality.

That said, I do wish there was a dark theme, as every time I work at night and have to look something up, my eyes burn a little :sweat_smile:

3 Likes
9

Hey @DolphinIQ

I feel your pain, you can clone the repo and edit the css a bit to make it fit your viewing habbits better. Personally, I prefer dark themes also, same reason - less strain on my precious balls of eye.

3 Likes
12

14 Likes
13

I would like to add to “cons” that there is no built-in support for spatial indexing, making exact raycasting, frustum culling and collision detection hopelessly inefficient in complex scenes.

I even think the complexity/maintenance argument against adding such a feature would be put to shame by all the power users who would gladly spend time ensuring it works for their project.

See e.g. Fast raycasting and other spatial queries and https://github.com/mrdoob/three.js/issues/13909

4 Likes