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

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

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

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
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