4 ms·

Threepp: A C++17 Port of Three.js

146 points by 10000truths 5y ago

the_why_of_y 5y ago
See also: Gthree is a GObject/Gtk+ port of three.js https://github.com/alexlarsson/gthree https://github.com/alexlarsson/gthree
Ziggy_Zaggy 5y ago
Upvoted bc Three.js is amazing. Hopefully this project is amazing, too.
- sufficer 5y ago
  Uhhh okay....
Ginden 5y ago
Can we compile it to WebAssembly and benchmark...?
- monpetit 5y ago
  I wonder it too.
- pjmlp 5y ago
  Given that only JavaScript has direct access to WebGL APIs (for the time being), every single WebGL call will go through the marshaling API across runtimes. It won't be the performance boost you will be expecting.
  - flohofwoe 5y ago
    Three.js does a lot more though than just being a WebGL API wrapper (the WASM => JS calling overhead is negligable these days compared to the time spent inside WebGL). Scenes with many Three.js Javascript objects might benefit because those cause GC overhead which simply wouldn't exist on the WASM side (where those objects would be regular C++ objects on the WASM heap - of course, if "C++17" means that memory management is mostly done with C++ (shared or unique) smart pointers, then the GC overhead may creep in again via reference counting and/or cache misses on the WASM side). (you're right of course that most of the time there won't be much of a difference, but not because of the WASM => JS marshalling but because of the time spent inside WebGL calls, which can be shockingly high). PS: Yeah, looking at he C++ headers, it's shared_ptr<> all the way down :( This might actually add more refcounting overhead when natively compiled than what typical Three.js code spends in JS garbage collection.
pjmlp 5y ago
Nice for porting purposes, other than that it is constrained to a GL ES 3.0 subset given what is available in WebGL 2.0.
onion2k 5y ago
I really like three.js, I use it, and I like that people are doing good things like this with it. But... I wonder if someone was building a 3D library for the web today if they'd do things the same way as three.js does things. Under the bonnet three.js is effectively a bunch of string concatenations that build up GLSL shaders for things like materials. It works well, but if you look through the code it really is a massive series of if statements (and loops? :) ) like "if a lambert material else if phong else if standard else if physical, and if lights > 0, and if env maps.." Hundreds of them, all smooshed together. The external API that you use to access everything is quite clear and easy, but doing things extending a material is much harder than it needs to be (you essentially use a regex to modify the big concatenated GLSL shader string..). I can understand wanting to use the API in another language, but I'm less sure about wanting to use the internals.
- OskarS 5y ago
  This is a reasonably common technique in game engines, actually, usually referred to as an “uber shader”. The idea is to have one massive shader with a bunch of if’s that does everything, and then you don’t have to pay the cost of shader state changes. There are lots of arguments for/against the uber shader technique, but I’m guessing it was probably intentional for performance reasons, not just an accident of development.
- pjmlp 5y ago
  In regards to WebGL APIs I rather use BabylonJS or PlayCanvas for the tooling.
  - dagw 5y ago
    Could you elaborate? I've done a fair bit of Threejs and would love to hear about better tools/libraries.
    - pjmlp 5y ago
      PlayCanvas is like using an Unity like tooling that was developed for WebGL as only target. BabylonJS is more high level, you can use it from either JavaScript or TypeScript, it has a playground which is more IDE like than the threejs editor, and it follows a scenegraph approach, with additional tooling for working with meshes, GUIs (early steps), animations, ... Since it is also used by the Office team, effort is being taken to make it work on top of React Native as well. Microsoft has a YouTube channel with BabylonJS tutorials.
riskneutral 5y ago
This is great. The C++ ecosystem is becoming truly awesome.
stuaxo 5y ago
Another one :) These come along periodically and I am all for them, but what is tricky is that ThreeJS carries on evolving and most die in the end. Without some sort of ThreeJS test set it's not possible to for these implementations to keep up.

146 points by 10000truths 5y ago

See also: Gthree is a GObject/Gtk+ port of three.js https://github.com/alexlarsson/gthree https://github.com/alexlarsson/gthree

Ziggy_Zaggy 5y ago

Upvoted bc Three.js is amazing. Hopefully this project is amazing, too.

sufficer 5y ago
Uhhh okay....

Ginden 5y ago

Can we compile it to WebAssembly and benchmark...?

monpetit 5y ago
I wonder it too.
pjmlp 5y ago
Given that only JavaScript has direct access to WebGL APIs (for the time being), every single WebGL call will go through the marshaling API across runtimes. It won't be the performance boost you will be expecting.
- flohofwoe 5y ago
  Three.js does a lot more though than just being a WebGL API wrapper (the WASM => JS calling overhead is negligable these days compared to the time spent inside WebGL). Scenes with many Three.js Javascript objects might benefit because those cause GC overhead which simply wouldn't exist on the WASM side (where those objects would be regular C++ objects on the WASM heap - of course, if "C++17" means that memory management is mostly done with C++ (shared or unique) smart pointers, then the GC overhead may creep in again via reference counting and/or cache misses on the WASM side). (you're right of course that most of the time there won't be much of a difference, but not because of the WASM => JS marshalling but because of the time spent inside WebGL calls, which can be shockingly high). PS: Yeah, looking at he C++ headers, it's shared_ptr<> all the way down :( This might actually add more refcounting overhead when natively compiled than what typical Three.js code spends in JS garbage collection.

pjmlp 5y ago

Nice for porting purposes, other than that it is constrained to a GL ES 3.0 subset given what is available in WebGL 2.0.

onion2k 5y ago

I really like three.js, I use it, and I like that people are doing good things like this with it. But... I wonder if someone was building a 3D library for the web today if they'd do things the same way as three.js does things. Under the bonnet three.js is effectively a bunch of string concatenations that build up GLSL shaders for things like materials. It works well, but if you look through the code it really is a massive series of if statements (and loops? :) ) like "if a lambert material else if phong else if standard else if physical, and if lights > 0, and if env maps.." Hundreds of them, all smooshed together. The external API that you use to access everything is quite clear and easy, but doing things extending a material is much harder than it needs to be (you essentially use a regex to modify the big concatenated GLSL shader string..). I can understand wanting to use the API in another language, but I'm less sure about wanting to use the internals.

OskarS 5y ago
This is a reasonably common technique in game engines, actually, usually referred to as an “uber shader”. The idea is to have one massive shader with a bunch of if’s that does everything, and then you don’t have to pay the cost of shader state changes. There are lots of arguments for/against the uber shader technique, but I’m guessing it was probably intentional for performance reasons, not just an accident of development.
pjmlp 5y ago
In regards to WebGL APIs I rather use BabylonJS or PlayCanvas for the tooling.
- dagw 5y ago
  Could you elaborate? I've done a fair bit of Threejs and would love to hear about better tools/libraries.
  - pjmlp 5y ago
    PlayCanvas is like using an Unity like tooling that was developed for WebGL as only target. BabylonJS is more high level, you can use it from either JavaScript or TypeScript, it has a playground which is more IDE like than the threejs editor, and it follows a scenegraph approach, with additional tooling for working with meshes, GUIs (early steps), animations, ... Since it is also used by the Office team, effort is being taken to make it work on top of React Native as well. Microsoft has a YouTube channel with BabylonJS tutorials.

riskneutral 5y ago

This is great. The C++ ecosystem is becoming truly awesome.

stuaxo 5y ago

Another one :) These come along periodically and I am all for them, but what is tricky is that ThreeJS carries on evolving and most die in the end. Without some sort of ThreeJS test set it's not possible to for these implementations to keep up.