We tried threejs (and babylonjs as well) for a WebVR project targeting mobile devices a few months ago. Suffice to say both are extremely unoptimized and crippled from the ground up with architectures easily wasting at least half the CPU every single frame.
They can both be made orders of magnitude faster simply by focusing on cache misses, branch predictions and data packing. But I don't see it happening without full rewrites in both cases.
We ended up writing a simple proprietary WebGL/WebVR renderer from the ground up - our scenes dropped from 18-20ms of CPU time to a very stable 0ms (and we made them much bigger as well.) Even the GPU time saw a big performance boost because we were using normalized integers instead of floats to reduce the vertex stream's bandwidth.
They're both good libraries to learn 3D and toy around with, but they're clearly aimed at beginner programmers with no or next to no experience in 3D graphics programming. Such a requirement goes directly against raw performance which requires loads of non-beginner friendly techniques.
Please contact me at ben@exocortex.com so we can chat please. I am a large contributor to three.js and use it extensively. I would appreciate understanding what you feel are needs for a rewrite. You seek like you know what you are taking about.
Just checked out exocortex.com, have you taken any look at the Hololens? For instance, Vuforia is working on selling catalog items using 3d models built in Unity [0], but perhaps you could use HolographicJS as another target once it matures [1].
I'm working in AR in a different space but as a longtime JS developer I would love to see this all come together.
I don't know. There are lots of really great things being made with Three.js. If you couldn't get it to work, it says more about your lack of experience with Three.js than it does about the unsuitability of Three.js.
I could get both threejs and babylonjs to work without a single issue; anyone with even the slightest of experience on game engines can do so effortlessly in minutes. Yet no amount of experience with either library will make their performance issues go away.
Have you profiled any of them? They take at least an order of magnitude more CPU than required in the best of cases, not even counting wasted GPU bandwidth/cycles. Heck, babylon.js sets its active texture unit by string concatenation - I can't think of a less efficient way to do it.
Have you seen any other graphics engines to add weight to what you're saying? I spent a full week in both project's codebases to try and optimize them before giving up; like I said, both architectures cripple performance from the ground up. They're very naive implementations of very old ideas that haven't been used in game engines for at least a decade.
Don't be so quick to imply a lack of experience; it very well might just be the Dunning-Kruger effect at work.
Perhaps targeting mobile is a different story, mobile browsers are constrained. We built A-Frame on top of three.js, and we're able to build compelling 90 FPS room scale VR experiences running with the Vive in the browser. Perhaps it could be optimized, but it's worked wonderfully for our use cases. https://blog.mozvr.com/a-painter/
That matches our experience as well; desktop computers have no problems running VR in the browser. We couldn't get above 50FPS for the mobile devices we targeted (the servicing contract we had was for a mobile experience only.)
This is when we decided to write a custom engine tailored specifically for our needs based on my experience working with AAA game engines (I even shipped a title on the PSVita so had intimate knowledge of PowerVR and ARM architectures). And as I said in my original post, it is definitely not beginner friendly - while three and babylon both are.
It took about two weeks to write the core tech and it can only do what this specific project required. If not for performance issues on last-gen mobiles we'd never have rolled our own.
Desktop computers are incredibly fast - they can easily waste 90% of their CPU and still yield a lighting fast VR experience (for small scenes at least - less than a hundred draw calls). Mobile not so much.
