React VR
facebookincubator.github.io
facebookincubator.github.io
Using the same technologies is natural.
I'd be in even just for the possibility for reflection/dependency injection.
WebGL is a huge bonus, but WebAssembly will also be important for a lot of web-based VR.
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.
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)
so aside from startup speed you get the same perf
So does every other language, where it matters is with objects. Until I can mark a whole object as a value type and fix it in memory relative to other objects then you'll pay a 10-50x slowdown for cache misses and the like.
But you don't even need to rely on that. JS has TypedArrays[0] which are basically just a chunk of memory you can read and write to.
Aside from some bounds checking, it's about as "low level" as you can get. Sounds like exactly what you are looking for.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
On the Java side I've used ProtoBuf for similar approach(using byte[] which does have memory placement semantics). While it helps, the bounds checking and accessors that you need still have a non-trivial cost both in branching and cache thrashing(len is usually stored for an array at a different location or at the head so data items near the mid/tail will still take a hit).
Realistically you can get within about 1/5th the speed of native using cache aware data structures and techniques. As always it matters if your use case needs that speed but choosing a JS/managed based tech-stack will always limit you from getting that last 5x perf improvement.
I'm deeply suspicious that you'll do better than something purpose built. Things like arena allocators for levels. Knowing how your scene-graph and animation traversal are really hard to get right and without direct control over SoA vs AoS and the like I don't see how you get within a factor of 10 to something written in native.
That's a bold statement right there.
I'm actually a huge fan of WASM, I think it gives you a great escape hatch to break out of these problems(much like JNI/etc in other managed languages).
But then you're no longer using the language. The performance-hostile semantics are still there, you're just not using that part of the language, and thus losing out on all their benefits.
You may be confusing layers here. asm.js as a compilation target is used the same way as LLVM- it is used to implement the source language's features, while simultaneously avoiding some of JS's.
There absolutely is.
If I write a program in a language that's fuzzy enough that a machine (which follows the specifications of the language) cannot definitely tell what I was asking it to do at compile time, there are compiled optimizations it can never rely on.
You make a good chunk of that back with JIT / predictive runtime compiling, but it's never going to be the same. At minimum, you're burning CPU and cache on your miss rate. To say nothing of the additional overhead of running JIT while executing in the first place.
As I understand it, this is the entire purpose of things like Vulkan / Webasm. (I realize they're primitive targets vs high level language, but same principle applies at any level of the stack)
Happy to have someone tell me I'm wrong, but the original quote flies in the face of everything I learned in language / compiler design.
I think however there is some fundamental communication issues talking about "compilers vs language". Optimizing compilers, by definition, rewrite your code into a "better" form. Even if you are writing C/C++ you probably don't really know what's happening at the register level. Heck, with todays CPUs I wonder if even assembly people know what's actually happening in the registers!
There have been comments to the same effect on HN before, but I look at language design as an API between humans and computers. Computers need as strict rules on how to execute a thing as possible: humans need something comprehensible. The ideal language finds ways you can increase the former without decreasing the latter (in ways they notice).
I'd complain the same way if it were a C++ project requiring Boost or something.
As for solid and well-understood... Douglas Crockford wrote a book on how "solid" Javascript is, called "Javascript: The Good Parts". One of his most common refrains about JS was "Javascript is The World's Most Misunderstood Programming Language". [0][1]
ES5 came out in 2009. ES6 was standardized after React came out.
Love React by the way, will definitely check this out.
"…like building a spaceship out of bicycle parts" - HackerNews comment
I'm constantly amazed and thankful to be living in a world of spaceships built out of bicycle parts.
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.
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 :)
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.
This is really just a way to describe a VR world, or VR specification in markup. Which is kind of natural.
I guess if you're already happy with VRML, you're set though ;)
[1] https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80...
Carmel might be another example of this. Chromium/Firefox WebVR support on Linux and Mac has been an unstaffed joke. Even on Windows, it's been moving very slowly. As Facebook pushes to be a dominant player in social vr, it needs platforms it can rapidly advance.
Why?/Technical: Why ReactVR rather than aframe-react? A-Frame makes several architecture bets in a new and unfamiliar domain. It reminds me of early Angular. Angular devs said "revolutionary! it's the future! google!". And what I heard was "This is a new thing, so of course we're making bad architectural choices! This generation is an exploratory throw-away! You should skip it! And we're so inexperienced we don't even realize that's what we're saying!" :) Maybe the bets will all win. Maybe. But ReactVR is much more incremental progress. And if both become popular, and if there's need for A-Frame components in ReactVR, I expect someone will write glue. Or even sooner.
And since it sometimes comes up, why is the comparison ReactVR vs aframe-react (or something like it), and not ReactVR vs A-Frame? While React began life as a dinky virtual-dom library with delusions of grandeur, it has become an ecosystem for managing complex applications. So when A-Frame says "we're HTML and Components, for VR!", it's also saying "we're no more sufficient for creating complex apps than html is!" and "we're yet another attempt to create web components!" (a path littered with corpses, with the survivors tied to particular frameworks). So one could argue for angular-aframe, or ember-aframe, but complex A-Frame apps will need to be aframe plus something.
tl;dr: Perhaps control of development; and it's not clear A-Frame is the right thing.
Seriously, anyone remember VRML? It was so cool... it was technically junk and implemented horribly, but it was awesome still somehow. Like goat simulator.
The good old days!
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.
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.
Somebody convince me!
An example of Fiber in action is here: 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.
IDK how ReactVR does it, but Primrose pools most objects to avoid GC.
It's actually not hard to finish executing your Javascript in 11 milliseconds (90 FPS) if you avoid the well-known, profilable tripping hazards such as not blocking on the DOM. 11ms is an eternity in CPU time if you're not running some big-N synchronous algorithm (which you should be doing in a worker), so most of this time is not even going to be spent in your Javascript: it's going to be in blocking GPU drawcalls and uploads, which can be executed in parallel with the garbage collector.
So although it intuitively _seems_ Javascript VR would be killed by garbage collection, you can actually spend a large proportion of your time in garbage collection for free.
And it works for much more than static scenes. You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery.
> You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery.
No. If you create large scale real-time JS apps, you will soon run into the issues I described.
This advice isn't unique to Javascript and goes back to Carmack hacking on Doom, Wolfenstein 3D, and beyond. It's just that Javascript makes it easy to shoot yourself in the foot here, because this isn't a role that was forseen when JS was designed.
Do you have any links to share? I'd love to learn more about these performance problems you describe.
No, it will be less noticeable in VR, because of asynchronous reprojection.
FWIW I'm on Linux & have an iPhone, if that matters.
This is not about pictures. This is about interactive websites in VR.
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.
I think if programming language designers should have learned anything in the past 50 years, it should be, "It's the distribution!"
Seriously, its a lot better now, and if there's a thing you don't like about it (like static typing maybe?) there's something for you out there (typescript, clojurescript, elm, etc...)
Maybe someday this will be better with WASM, but it's not there today. Javascript runtimes work fine (not perfect, but passable) for page-based and widget-based UIs. There's no way I would touch it for something as computation-intensive as real-time 3D modeling.
"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.
I happen to think though that the web is an obvious use case for the React model, and phone UIs are only slightly less obvious low hanging fruit that has worked out really well.
The scalability of the model, however, depends on how much workload you can offload into the React system, and with VR, there is only so much you can do. Even if React is handling all of the rendering with extremely efficient native code, you still have to have a your own full 3d timespace model with realtime response demands. Maybe it will work for extremely basic use cases, but at some point having a familiar language becomes a relatively tiny benefit when compared to an efficient runtime.
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/