Hacker News new | past | comments | ask | show | jobs | submit login

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.


Hey, Kevin from the Mozilla VR team here.

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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: