A part of it is that the data models are genuinely different and different orgs want to do things in different ways.
Another part of it is that orgs recognize the value of stamping their brand on what they believe is a candidate for the next generation of the web.
But you don't need any of these frameworks to do WebVR; the API is (going to be) a standard and it's relatively straightforward to roll your own if you understand the browser's render loop and any 3D engine. I'm more worried by the fact that so much of today's WebVR code is just a layer on top of THREE.js. It's actually more of a monoculture than it appears on the surface.
Because they're toy technologies. People working in VR predominantly do not use any of these. They work with engine scale platforms or frameworks designed in-house.
Hmmm... no support for skinned character models (and looks like a lot of design and implementation work required on many fronts before this could support them). As cool as this is that makes it feel like a toy rather than a real product (even 3D that doesn't require humanoid characters tends to require deforming meshes to meet the visual quality bar customers expect).
I wish instead of trying to make their own renderer they had used their considerable react and coding skills and time to create a React UI for Unity3d and/or Unreal, which are what most serious app developers are using to create VR experiences (and which have pretty terrible/minimal/antiquated UI coding frameworks compared to what React offers)
Looking deeper into the docs, their scene graph/hierarchy design practically screams "I was designed by someone with zero experience designing 3D scene graphs" (I'm approaching this conversation as someone who has done that sort of thing for Disney, for Microsoft's 343 Halo studio, for startups and major effects houses, and as part of the original design process for the Collada open source format used by google earth and others.
Let's start with the <scene> tag, whose docs start out by saying the scene tag represents the camera location. You're not even at V1 and your docs already start out by saying "we picked a name for this but everyone else in the world thinks of it as having a different name." Worse, "scene" is an incredibly important keyword to be able to use in your 3D scene schema, and you've now tied it up representing something that isn't a scene in a way that prevents you from using the keyword to represent obvious future schema concepts (like multiple scenes you want to be able to switch between quickly).
On a more subtle or mathematical front, the handling of transform stacks is designed in a way that provides a small amount of needless advanced functionality for sophisticated/experienced 3d developers (who are not the target of this tech) while offering huge opportunities for needless confusion and errors in the hands of the novice 3D developers who are the target market for the tech. I'm looking specifically at the way in which individual transformation matrices are represented by an order-dependent javascript array of translate, rotate, and scale component "matrices" (putting matrices in quotes because they don't look like individual 4x4 matrices in the code but they act, combine, and commute (or don't commute) like 4x4 matrices). It's hard enough to help a novice programmer/3D developer to wrap their head around local and world space coordinate systems and the impact of non-uniform scaling on child objects. Expecting that novice tech customer to also need to learn about commutative rules for 4x4 matrix multiplication before they can understand why their slightly tweaked sample app is or isn't working is a terrible, needless complexity wrench to throw into the system.
I could go on for pages and pages here, but this isn't the format for that (and the tiny text box on iOS isn't helping), so I'll just say that I absolutely LOVE React and very much wanted to like this, but this looks like it was developed by people who don't even understand what's hard about designing a good 3D schema, much less how to address those challenges.
On this topic... this is something I've wondered a bit about before (logical representations of 3d scenes -- interested as someone who comes from the robotics world, and curious how the people who did video games, VR, graphics tools, etc. thought about this stuff).
Obviously not the same use case, but I've tried looking before for good information on how scene graphs are structured and used, and haven't found much out there that was useful for a beginner who was interested in learning the details. If you have any resources or stuff you would be willing to share, or a well designed library that does it right (any language), I'd love to know about it!
There are surprisingly few good representations for either 3d assets or 3d scenes.
Lots of people are pretty excited about the Universal Scene Description format that Pixar published and open sourced. It's great if you're a big film animation studio looking to manage huge scenes for offline rendering but it's explicitly not optimized for any of the kinds of speed/memory trade offs required for realtime rendering applications.
There are a couple efforts underway at the Khronos group that have lots of key folks from the Collada effort involved and there's a chance they'll come up with something good but this sort of schema design is such a subtle and forward-looking task that I personally am not optimistic about an open source effort being the first to get it right (you're trying to design a data format people will want to use two decades from now without getting trapped in a vicious cycle of analysis paralysis that can prevent you from being able to ship something usable today quickly, it's much like a language design problem where eventually you want to open source it but even then you need a Guido or an Anders or similar to guide the effort onto a good long term arc)
The more I try to do Web VR stuff though, I get frustrated because there isn't yet a good way to design it "responsively" so that it will look right on normal flat screens, but become an environment in VR.
I also wonder about what the right UX for linking pages in VR is. I don't want to have to fist-bump some floating blue text. Maybe there should be a "link shape" or halo that draws the eye to certain features.
Yeah, but those are all still like, super 3D on a flat screen. Which makes sense - they're demonstrating exactly how 3D and immersive VR can be, even without a headset.
I'm just curious what the future would look like for, say, a startup's splash page in VR, where environment could be used to subtly enhance the experience if you are in VR, but otherwise be a normal web page.
Now I'm picturing something like the Super Game Boy, where you have the original screen and then a graphical wrapper around it.
Being able to easily add a spherical or cylindrical "wallpaper" that would project around you while looking at a 2d rectangle projection of the site could be a simple way to give an "easter egg" to VR users without having to comprehensively redesign everything for it.