6 ms·

While I love Three.js, its editor has been around for almost as long as the project itself and is sort of neglected by comparison. WebGL Studio[0] has a far mor

by rl3 10y ago

While I love Three.js, its editor has been around for almost as long as the project itself and is sort of neglected by comparison. WebGL Studio[0] has a far more impressive editor, but its underlying engine is custom, so in most cases it isn't anywhere near as useful as Three.js due to the latter's ecosystem. One thing I don't like about either editor is that they're web-based. While it makes a ton of sense on paper, I hate doing any serious 3D work in a browser window. Something like Microsoft's Language Server Protocol[1] but for graphical editors would be amazing. Run the project in a browser window while having bidirectional flow of data between a native desktop editor and the browser window. Unfortunately if you want to run something like Three.js inside of a native desktop editor, you'd have to embed a web runtime. That really balloons project complexity, so I can see why so many people prefer web-based editors when making web-based projects. One alternative, at least for 3D applications, is multi-platform frameworks that also work on the web. Oryol[2] in particular comes to mind. Hypothetically you could build a native editor around it, with no need to embed a runtime. The native editor's viewport would just use native graphics APIs for rendering. Then when you like what you see, just compile the same thing for the web. While some edge cases may not make it that easy, overall it seems to be a far superior workflow than having to deal with web-based editors or embedded web within native applications. Unity 5 and Unreal Engine 4 both have incredible, native desktop editors that support exporting to the web. Unfortunately, they both have massive runtimes that make their web footprints a joke, among other problems. [0] https://webglstudio.org/ https://webglstudio.org/ [1] https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol [2] https://github.com/floooh/oryol https://github.com/floooh/oryol

zurn 10y ago
What makes you say it's been neglected? I scrolled back until i got tired (~3 years) of github's history page for the editor/ directory and it looks like a steady and active stream of development: https://github.com/mrdoob/three.js/commits/dev/editor/js https://github.com/mrdoob/three.js/commits/dev/editor/js
- rl3 10y ago
  Its commit history represents a small fraction of overall commits on the project. While the editor can surely be considered under active development by normal standards, a Mr. Doob project raises the bar on that. It's not uncommon to see him average over a dozen commits a day on a regular basis for the entire three.js repo, in addition to managing and merging a ton of pull requests at the same time. That said, I agree saying it's neglected is a bit unfair, so I've reworded my original statement qualifying it as sort of neglected (far more diplomatic). Moreover, it isn't really fair for me to hold it to the same standards as production-grade editors, since I'm pretty sure its primary purpose is to simply give people a sandbox environment to play around in. You'll be happy to know GitHub rate limited me around January 2015 of the commit history you linked, since there was so much of it. :)
badsectoracula 10y ago
Considering that Three.js seems to have several backends for rendering, it should be possible to make a desktop based Three.js editor using Qt (which has its own JavaScript implementation) and a Qt-specific backend.
- rl3 10y ago
  I believe Qt Canvas3D[0] is what you're suggesting. If I recall, one of the default project template(s) for this used three.js right out of the box. Does anyone have any real-world Canvas3D stories? I've no experience with it. Things like potential idiosyncrasies its implementation relative to major browsers seems worrisome. Feature lag also might be a concern, especially with bleeding-edge features found behind flags. Not to mention the horror story that is Web Workers. Granted, there's usually pain whenever you insist on having your cake and eating it too, it's just a matter of where. [0] https://blog.qt.io/blog/2015/05/27/introducing-qt-canvas3d/ https://blog.qt.io/blog/2015/05/27/introducing-qt-canvas3d/
moron4hire 10y ago
>> ...that support exporting to the web. I think, if you've ever actually tried to use this feature in these frameworks, you'd know this support is in name only. It's really not a usable solution.
- rl3 10y ago
  I have actually, and it was terrible. Even floated crazy ideas like packaging the ~50MB engine runtime into a browser extension. My main beef though was the fact that UE4's web rendering path is based on and artificially limited by the performance considerations of its mobile path (last I checked anyways).

by rl3 10y ago

zurn 10y ago

What makes you say it's been neglected? I scrolled back until i got tired (~3 years) of github's history page for the editor/ directory and it looks like a steady and active stream of development: https://github.com/mrdoob/three.js/commits/dev/editor/js https://github.com/mrdoob/three.js/commits/dev/editor/js

rl3 10y ago
Its commit history represents a small fraction of overall commits on the project. While the editor can surely be considered under active development by normal standards, a Mr. Doob project raises the bar on that. It's not uncommon to see him average over a dozen commits a day on a regular basis for the entire three.js repo, in addition to managing and merging a ton of pull requests at the same time. That said, I agree saying it's neglected is a bit unfair, so I've reworded my original statement qualifying it as sort of neglected (far more diplomatic). Moreover, it isn't really fair for me to hold it to the same standards as production-grade editors, since I'm pretty sure its primary purpose is to simply give people a sandbox environment to play around in. You'll be happy to know GitHub rate limited me around January 2015 of the commit history you linked, since there was so much of it. :)

badsectoracula 10y ago

Considering that Three.js seems to have several backends for rendering, it should be possible to make a desktop based Three.js editor using Qt (which has its own JavaScript implementation) and a Qt-specific backend.

rl3 10y ago
I believe Qt Canvas3D[0] is what you're suggesting. If I recall, one of the default project template(s) for this used three.js right out of the box. Does anyone have any real-world Canvas3D stories? I've no experience with it. Things like potential idiosyncrasies its implementation relative to major browsers seems worrisome. Feature lag also might be a concern, especially with bleeding-edge features found behind flags. Not to mention the horror story that is Web Workers. Granted, there's usually pain whenever you insist on having your cake and eating it too, it's just a matter of where. [0] https://blog.qt.io/blog/2015/05/27/introducing-qt-canvas3d/ https://blog.qt.io/blog/2015/05/27/introducing-qt-canvas3d/

moron4hire 10y ago

>> ...that support exporting to the web. I think, if you've ever actually tried to use this feature in these frameworks, you'd know this support is in name only. It's really not a usable solution.

rl3 10y ago
I have actually, and it was terrible. Even floated crazy ideas like packaging the ~50MB engine runtime into a browser extension. My main beef though was the fact that UE4's web rendering path is based on and artificially limited by the performance considerations of its mobile path (last I checked anyways).