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

Post a Comment

Popular posts from this blog

Push versus pull deployment models

-
There are two deployment models: push and pull. In a "Pull" deployment model, the individual servers contact a master server, download their configuration and software, and configure themselves. In a "Push" model, a master server pushes the configuration and software to the individual servers and runs commands remotely. While neither technique is right or wrong, they both have some specific advantages and disadvantages that you should understand when making a decision. In the ruby hosting world, an example of a "push" deployment is heroku , while Engine Yard is an example of a "pull" type deployment. In the Pull model, each server has information about how to obtain it's configuration, when it boots (or whatever the configuration triggering event happens to be) it can continue to proceed without intervention from the master server. In the Push model, because the master server is orchestrating things, it will typically need to have a c
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

MACH TEN Addendum: for companies wanting to use MACH platforms

-
The MACH Alliance is a consortium of ISVs and SIs that advocate for a particular approach when building/integrating modern platforms. One gap/misunderstanding I keep bumping into is the intent behind MACH. In general, it's a technosophical approach to how PLATFORMS are build, run, deployed, marketed, not really well suited for large organizations who are simply trying to USE these platforms. Therefor I propose a "MACH TEN" Addendum TEN is an acronym that adds some context to adopting MACH platforms to use in your organization. These are high level recommendations I enccourage folks to take into consideration before jumping under the bandwagon. :p Transparent Pricing and contracts are computable, if special terms are negotiated, that's OK, but I shouldn't have to tell you my budget before you tell me how much you cost How I integrate/use your platform is easy to find, I don't need special training, I can just RTFM and begin using your system
Read more