Hacker News Reader

Comment by rayalez | Hacker News Reader

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.

View on HN

I love the line "like building a spaceship out of bicycle parts". Maybe we should use that as React VR's slogan ;-)

+1 for making this your frontpage claim

"…like building a spaceship out of bicycle parts" - HackerNews comment

That's a cool idea for a game. Maybe it could be done as a Kerbal mod? Have "etheric traction tires" provide inertialess drives?

I think Scrap Mechanic[1] may basically be this. I haven't played it, but my son had me buy it for him the other day. I'll be trying it out with him in a day or two.

1: http://www.scrapmechanic.com/

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.

This is like saying dog turds are really just stardust and no different than the Pleiades in this regard.

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?

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.

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 :)

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.

That is another fascinating point, that all of our software comes from interlinked text documents. The reactions to React VR are really leading to some great quotes ;-)

The first airplane was built from bicycle parts.

It's not the first time (or the last). VRML worked in 1996 even

To be fair, it's not exactly the same. HTML doesn't have a "Pano" tag.

This is really just a way to describe a VR world, or VR specification in markup. Which is kind of natural.

Natural indeed; VR games made with Unity are also defined as declarative trees of objects in a similar fashion. In fact, if you added a "behaviors" prop to all of the React components in this system you would essentially have a basis for porting Unity-like scenes pretty directly (maybe even automatically).

Reply on news.ycombinator.com