React VR(facebook.github.io) |
React VR(facebook.github.io) |
React VR backed by facebook (who controls oculus):
<View>
<Pano source={asset('chess-world.jpg')}/>
<Text
style={{
fontSize: 0.8,
layoutOrigin: [0.5, 0.5],
transform: [{translate: [0, 0, -3]}],
}}>
hello
</Text>
</View>
<a-scene>
<a-box color="#6173F4" opacity="0.8" depth="2"></a-box>
<a-sphere radius="2" src="texture.png" position="1 1 0"></a-sphere>
<a-sky color="#ECECEC"></a-sky>
</a-scene>
<x3d width='500px' height='400px'>
<scene>
<shape>
<appearance>
<material diffuseColor='1 0 0'></material>
</appearance>
<box></box>
</shape>
</scene>
</x3d>It would be like saying that Angular, Vue, and React are causing fragmentation.
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.
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)
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.
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!
Thanks!
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.
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.
And almost nobody is using ReactVR, for the simple reason that almost no browsers support it yet.
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)
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.