webxr with Babylonjs, A-frame/Threejs, and Unity

I've been working quite extensively on a webxr side project. Originally it was built with a-frame / threejs. You can take a look at it here at Immersive Idea. Recently I relized I was "fighting the framework" more than I was "getting things done". Originally, I chose a-frame because it was essentially a "no code" (well just html markup) way to build scenes. Additionally it's ECS framework was very well documented and easy to use. In an effort to broaden my perspective I started looking at alternatives (Unity with OpenXr, Babylonjs) as I was struggling to keep the pieces working together. This is my (slightly long) recap of my observations.

A-Frame

A-frame is wonderful...it is well documented, easy to use, and the community is super friendly and helpful. If I simplly wanted to render scenes in webxr with minimal ability to manipulate the environment, I wouldn't even think twice about using it.... Heck I still use it for quick mock ups. For simple scene manipulations (animations, sound, simple interactions) I also highly recommend it. It does, however suffer from a pretty serious achilles heel and I'm not really sure how they're going to overcome it. If building/manipulating the scene requires real time visualizations of data or physics simulations, it starts to show it's cracks. Generally I found I was digging deeper and deeper into threejs and it's lack of backward compatibility was causing major headaches.

Babylon.js

Babylonjs initially was a bit offputting to me. The fact that you need to drop into js "just to get started" was bothersome. However, when I moved from simply rendering and animating content into a full blown interactive experience, babylonjs became much more palatable. Moreover, after using it for a while, the maintainers insistence on backward compatibility made me super comfortable to simply upgrade the platform at will (they have a pretty aggressive release cadence). So far I've had a couple of hiccups that weren't "exactly" backward compatibility problems, but more "forward compatibility" problems...recent example was an enhancement to hand tracking that sorta...didn't work as I expected. For an example of similar experience as I mentioned above, but implemented with babylonjs, take a peek at Deep Diagram.

Recap

If you're just rendering content (be it gltf, stl, obj, or simple shapes) a-frame is the way to go (IMHO). Additionally, if you're super comfortable with the ECS model and want to "just be productive" A-Frame is still probably a solid choice. If, however, you're a Front End developer who wants to build a super optimized interactive experience with Havok Physics (BTW, totally baked into babylonjs...I maybe forgot to mention this) I'd highly recommend checking out babylon.js.

Comments

Popular posts from this blog

the myth of asynchronous JDBC

The difference between Scalability, Performance, Efficiency, and Concurrency explained

Push versus pull deployment models