
React VR - angrydev
https://facebookincubator.github.io/react-vr/
======
borisyankov
For anyone wondering: 'Why JavaScript? Why React?', let me remind you, the
goal of ReactVR is not to create the most performant game, but to allow the
people that are creating websites right now, to create VR websites in future.

Using the same technologies is natural.

~~~
javajosh
I would add that there is absolutely no technical reason why an application
expressed in one language need not be as fast as an application expressed in
another. First, compilers improve static analysis, and second, JIT analysis
will also improve. For this sort of thing, _running on the GPU_ matters a lot
more than source language, and WebGL has you covered there.

~~~
Rusky
This is wrong. There absolutely are technical reasons why implementations of
different languages perform differently- no amount of static or runtime
analysis can entirely save you from performance-hostile semantics baked into
the language spec.

WebGL is a huge bonus, but WebAssembly will also be important for a lot of
web-based VR.

~~~
avaer
> no amount of static or runtime analysis can entirely save you from
> performance-hostile semantics baked into the language spec

You can in almost all cases check for these semantics statically, and if not
found, run a super fast path. This is the whole premise behind asm.js.

Heck, even C++ has plenty of features that have performance-hostile semantics.
But the compiler checks for these and you don't pay the penalty if you don't
use them.

Wasm will help, but I disagree that anything in the JS spec makes the
_language itself_ inherently slower than any other language, if we disregard
textual compilation overhead.

~~~
vvanders
I'll give you one: value types.

Until you can specify memory layout you'll never come near a proper gamedev
engine, regardless of GC issues(which are also a problem).

(source: I used to work on professional game engines)

~~~
flohofwoe
asm.js and WebAssembly give you the same control over memory layout as C (in
fact the memory layout is absolutely identical to a little-endian 32-bit host)
and unless you need to call a lot out into HTML5 APIs the garbage collector
will be idle. These two things together are basically the magic sauce why
asm.js/wasm are faster than manually written JS and faster then most 'managed
languages' where most objects are created on the heap and passed around by
reference.

~~~
aanm1988
> asm.js and WebAssembly give you the same control over memory layout as C

That's a bold statement right there.

~~~
flohofwoe
Not at all, both asm.js and wasm give you a flat memory region (in asm.js it's
a single, big JS typed array), the stack and all allocations live in this
'heap', managed by emscripten's malloc wrapper (which is jemalloc I think),
the resulting memory layout is the same as on a native 32-bit platform, with
the same alignment rules. There are no 'managed' Javascript objects in asm.js
or wasm (unless you need to call out into web APIs).

------
rayalez
Jeeeeziz. HTML/JS were designed to display interlinked text documents. Now you
can use them for VR. It's like building a spaceship out of bicycle parts.
That's crazy. Crazy cool maybe, but definitely crazy.

Love React by the way, will definitely check this out.

~~~
avaer
Technically _all_ of our software comes from interlinked text documents. The
magic is in the software that eats the interlinked text and makes it real.
HTML/JS are no different in this regard, VR or not.

I'm constantly amazed and thankful to be living in a world of spaceships built
out of bicycle parts.

~~~
greysphere
I like this sentiment a lot, as it applies to most computer uses. A couple
standout exceptions however are images, videos, 3d models and animations. It's
certainly possible to represent these in text, but most uses and tooling
respect their visual/spatial content. This seems a major criticism of the
'just use existing web tech to make vr'. The former really was about digesting
and emitting text documents, but vr is more about models/layout/animation - is
text really the right foundation for the job?

~~~
meheleventyone
Sort of, binary formats are mostly optimisation for scene data specifically
and working with human readable formats is quite normal for content creation.
If you can put up with the time taken to parse then it's workable.

If you think of declarative vr in those terms it's a lot like a web page where
a portion arrives as text that describes the layout of the bulk of binary data
for rich applications.

Where it gets tricky is for large scenes and/or streaming scene data where
generally you need better performance. But this sort of thing could still be
pre-baked and live within a declarative wrapper.

~~~
greysphere
My point isn't so much text vs binary. It's text==1D vs much of VR content
which is multi-dimensional. And the more multi-dimensional, the more the most
human readable format becomes the non-text version (text -> trees -> images ->
models/videos/animations).

Honestly even html suffers from the translation between linear-text and the
tree-like DOM. Many of the pain points of webdev are dealing with this
boundary. Go even farther to scenarios where you'd want to interact with the
2D rep of a webpage and you're completely off the reservation. Imagine using
javascript/dom to ask the question "what letter is below the 17th character of
this this paragraph", the question almost comes across as absurd! "What about
different fonts? What about phones? What if there's an image below, is that
'null' or should I skip to the text?" The question is meaningless! Then again,
text selection is exactly this question... On the web we've found some very
reasonable boundaries between webpage responsibilities, browser
responsibilities, and accepted a large swath of functionality as impossible.

In VR those boundaries are still in flux. VR scenes are a combination of all
sorts of content, of all sorts of dimensionality, often including temporal
components as well. Certainly for storage and transmission 'linear' is the
only option, but what is the best working representation? Is it a tree with
rich nodes? Well maybe, but that's going to make it that much harder for those
nodes to interact. On the other extreme is it a 4d array of temporal-voxels?
Probably not until we have petabyte DSL. Imo this is why this is a hard
problem, why VRML has never really caught on, why after 25 years of making 3d
games/movies there's still no standard scene description, why Facebook is
taking a stab at this with this project, and why VR is a pretty exciting place
to work :)

~~~
meheleventyone
Scene representations in game engines tend to follow the use case so there
tend to be several generated from the same scene description. Generally
because one representation that is useful for organising a scene isn't great
for spatial queries. Likewise we need a representation that can be fed
efficiently to graphics hardware. Or the use of voxels for simulation. My
rambling description aside my point is that there isn't likely to be one
working representation.

For WebVR hopefully we can steer a good path between that which should be
represented in an HTML/DOM context and that which should be represented
elsewhere. For example glTF looks quite promising both as a runtime format for
models and for scenes.

------
HalcyonicStorm
Suddenly the snippet of code from Westworld makes sense

~~~
stevens32
Apparently hosts are built with React.. good to know.

------
mumphster
Any reason this was built instead of contributing to aframe[0]?

[0] [https://aframe.io/](https://aframe.io/)

~~~
lprubin
I tried out ReactVR for a prototype and I liked that I was able to use my
familiarity with React to set up a simple VR project in a few hours with no
prior VR experience and without having to learn any new syntax, just a few new
classes.

~~~
amadeusw
I tried out A-Frame for a prototype and I liked that I was able to set up a
simple VR project in a few _minutes_ with no prior VR experience and without
having to learn React. I'm sticking to A-Frame

------
jmcdiesel
And thus, VRML was reborn!!!!!

Seriously, anyone remember VRML? It was so cool... it was technically junk and
implemented horribly, but it was awesome still somehow. Like goat simulator.

~~~
dangoldin
That was one of my first forays into coding. I remember doing the basic
examples and then finding some of legitimate worlds and having my mind blown.

The good old days!

------
daviding
I've used this for a couple of hobby projects and it's been fun. One thing I
think it does need soon is a VR Browser for the Oculus Rift and/or Vive HMD's
as well. Currently the use of the 'Carmel' VR browser is Gear VR only, and it
would be nice to try some React VR on something with greater oomph.

~~~
mncharity
During last year's absence of any WebVR or SteamVR support for linux and Vive,
I cobbled together an alternate stack[0], using Valve's low-level OpenVR
device driver, node.js electron as runtime and compositor, and a WebVR 1.0-ish
api. I've used it with React and three.js.

No ReactVR. No A-Frame. No lens correction. Insecure. The device driver api
has moved on, and current device firmware may or may not work. But fyi, fwiw.

[0] [https://github.com/mncharity/node-webvr-alt-
stack](https://github.com/mncharity/node-webvr-alt-stack)

------
iamleppert
Extending VR to the web and to other sets of developers is great!

However, I don't see any useful abstractions here besides a bunch of
declarative boiler-plate.

Creating something that allows more people access to a creative medium
requires real abstraction, not just wrapping a bunch of Three.js API's in
react components.

------
agd
Garbage collection and compilation operations can cause hard to predict,
noticeable slowdowns for large real-time JS apps so I'm skeptical of the use
for ReactVR right now. Perhaps I'm wrong though? Or maybe it will be useful
for static, UI scenes?

Somebody convince me!

~~~
iLoch
The React team has been working on an improved rendering engine called Fiber.
This is an oversimplification but Fiber essentially breaks down per-frame
rendering into several sub rendering tasks, allowing for smarter multi-
threading (in the case of web workers) and even single threading (the renderer
now returns control of the main thread much faster and more frequently,
allowing for more opportunities to do GC and other operations without as much
of a negative effect.)

An example of Fiber in action is here:
[https://www.youtube.com/watch?v=Qu_6ItnlDQg](https://www.youtube.com/watch?v=Qu_6ItnlDQg)

What this amounts to for React developers is the introduction of explicit
priority rendering, which can be very useful in VR environments. So for
example, updates to your UI from external processes (such as an XHR) can be
set to lower priority than updates to the hand model that's controlled by the
controllers.

~~~
fudged71
How does this relate to garbage collection?

~~~
kbenson
I think maybe the basic idea is that by utilizing more cores and getting more
done concurrently, they leave more idle time per frame for the GC to work. If
that's the case, it doesn't necessarily solve the problem, but it may move the
bar enough to be currently usable and useful.

------
komali2
Amber Roy will be giving a talk about this at the Google Downtown San
Francisco office next Friday:
[https://www.meetup.com/sfhtml5/events/237831559/](https://www.meetup.com/sfhtml5/events/237831559/)

------
mullsork
What device would you recommend for playing with VR? I've never tried a
headset but 3D UI interfaces has been something I've day dreamed about for
well over a decade now and it'd be fun to see it happen.

FWIW I'm on Linux & have an iPhone, if that matters.

------
endergen
I'd love to see something like what Expo is doing for regular React Native for
VR. Even them doing it would be great, I assume that might complicate their
branding, but still.

[https://expo.io/](https://expo.io/)

------
Shinchy
This is awesome, however I just spent a month making the exact same thing. Oh
well, I might give this a go and see if this is more in line with what I want
to do.

------
clintonb
Is this the return of VRML?

~~~
lacker
With a vengeance!

------
oelmekki
Obvious question : is it plan at any point to support Unity3D?

------
suyash
This is one project that has changed my mind to finally get going with
facebook's React framework. I would love to see VR development more simplified
and accessible to web developers.

~~~
dmarcos
You're more than welcome to also try [http://aframe.io/](http://aframe.io/)
That's exactly our goal, onboarding Web Developers into the new medium. Let us
know what you think.

------
Hydraulix989
Reminds me of VRML.

------
Animats
Drawing pictures by writing code is pounding a screw.

~~~
borisyankov
There are tools for 'drawing pictures' already. From Google's Tilt Brush, to
Oculus' Medium and Quill. And game engines start supporting scene editing
directly in VR.

This is not about pictures. This is about _interactive websites_ in VR.

------
saosebastiao
oh bloody hell...is this an elaborate troll?

I get it...javascript is the universal language. It's also universally hard to
fully understand, hard to scale to large codebases, has no shared memory
parallelism, has a GC-heavy runtime, and is extremely hard to optimize for
performance (both by humans and by compiler optimizers).

I appreciate what React has done, it's pretty impressive. But I can't help but
think we're getting into parody territory here.

~~~
iLoch
I don't think the other subcomments actually address your concerns, so here's
my take: Javascript is the language known by every web developer. Right there,
they're opening up their developer audience to a much larger group of people
than is possible with C++ or even C#.

"Hard to scale large codebases" isn't really an argument, large code bases are
hard in every language, JS isn't really an exception here.

Low level stuff (GC, perf, memory) has been, and will continue to be a problem
for Javascript. You can mitigate a lot of the problems with well designed
code. React attempts to minimize a lot of those problems with solutions that
work for most general use cases (and now with Fiber, we're getting even more
granular control.)

Until React moves to Web Assembly you're always going to have overhead when
using JS. But let me know when you've got a solution for VR in a web browser
that's not JS and I'll give it a try.

~~~
yarper
> Right there, they're opening up their developer audience to a much larger
> group of people than is possible with C++ or even C#.

Maybe this is true, but I'd hazard a guess that most developers are not web
developers. [1]

Most of us aren't questioning how VR can be done in a browser, but stopping to
ask why.

[1]: [http://githut.info/](http://githut.info/)

~~~
meheleventyone
Perhaps because it's a really accessible platform and by baking in support now
it will be mature when VR hardware is more generally accessible (2018-2019 for
mobile). I'm from a game development background but accessible,
interconnected, multi-user VR for all seems like it's something that will come
from the web rather than bespoke attempts. Perhaps a better platform will come
along with time.

